TK.

Super! :) Ja, das IIC_MIDI Modul laesst sich auf der Event Seite (MENU->Evnt) als alternativen MIDI Ausgang selektieren. Bis zu 4 IIC_MIDI Module koennen auf diese Weise addressiert werden. Gruss, Thorsten.

Oh, the answer to this question was too obvious: of course, all AOUT modules will be supported. It will even be possible to chain the modules in order to enhance the number of channels. Best Regards, Thorsten.

These are timing constraints which usually have to be measured with a scope, because there are too many parameters which affect the slew rate (e.g. cable length, input impedance of the target device), not only the one specified in the PIC datasheet... Best Regards, Thorsten.

"hex´n" ist eine lustige Wortschoepfung, leider funktioniert sie nur im Deutschen, ansonsten wuerde ich glatt das Wording auf den ucapps Seiten aendern ;) Zu Deinem Problem: wahrscheinlich wurde der PIC mit der ID "0000000000000000" gehext, so dass MIOS defaultmaessig ueber den MIDI Out des Core Moduls sendet. Die ID laesst sich nachtraeglich aendern, doch die Prozedur muss ich glaube ich gar nicht erst erklaeren, weil sie bei neueren PIC18F4620 obsolet ist (*) - der EUSART Bug wurde mittlerweile gefixed. Somit wuerde ich vorschlagen, dass Du einfach den MIDI Out Port des Core Moduls zum hexn verwendest. Gruss, Thorsten. (*) change_id Applikation, iic_midi_10.hex aufladen

Yes, it should be removed from the skeleton. I remember again, why I didn't removed it by myself: the .asm file is a wrapper, which shouldn't touch the original definitions in .inc to ensure, that I'm able to use the module in assembly only applications with the same behaviour. It was the only way to ensure, that the original default value defined in .inc still will be taken w/o overruling in .asm It's like an advanced consistency check. If somebody changes the default value directly in the .inc code (for whatever reason, normaly the source code shouldn't be touched), the compiler will fail due to the missing _blm_button_debounce_delay variable So, he needs to search for the error, and will find out, that the same definition is used in .asm as well. no, it isn't, since you cannot include the file before variables are declared However, no need to discuss the sense and nonsense about this trick here. I found it useful for a particular issue, but if you don't see the need - don't use it! Best Regards, Thorsten.

I guess that you mean the "trick" in the blm module, which I used for BLM_NO_DEBOUNCING in blm.asm It isn't really required, and as you can see in blm.inc, a common "#ifndef/#define" combination works as well. I was only so annoyed by this GPASM limitation, that I documented a possible workaround for the case I ever need it ;) Best Regards, Thorsten.

You could use a PIC based MIDIbox CV, connected to a MIDI port (e.g. GM5 based) However, keep in mind that the user interface of the emulated MBSEQ is not designed for computers. You can move encoders with the mousewheel, and click on the buttons with your mouse or with the keyboard - but the usage of a real MBSEQ will always be more intuitive and faster. The purpose of the MacOS based emulation is mainly to provide a virtual prototype, which allows people to get a better understanding about the possibilities of a certain application before building a MIDIbox, to plan a customized frontpanel, and for programmers to debug an application w/o the need for ARM debugging tools. I consider to provide a special MIDI remote function, which will allow a PIC based MBSEQ to control an emulated MBSEQ V4 for those who don't want to replace their core module by a MBHP_CORE_STM32 yet. The remote connection could also allow to control AOUTs and triggers. LCD output should be feasible as well. Even running it on a Windows or Linux PC should be possible this way w/o much effort at my side. But for myself it's a minor feature, therefore: low priority Best Regards, Thorsten.

In order to enable this feature, you have to apply svn propset -R svn:keywords "Id" <filename(s)> to your files Thereafter, add "$Id: $" to the header (or wherever). It will be automatically updated on each commit Advantage: release packages will contain a reference to the svn revision you were using Best Regards, Thorsten.

Today I reached an important milestone in my "feasability study" (see initial posting) Most of the MBSEQ V3 features are now implemented on C, they are running on STM32 and they are accurately emulated under MacOS. The code size is currently 80kb, compared to 64kb PIC code of MBSEQ V3 this means, that the code density of the ARM Cortex M3 processor is almost equal for a real world application. 432kb flash memory is unusued yet - a lot of room for future enhancements! It's possible to use 16 tracks with 256 steps, 4 parameter layers, 8 trigger layers. Paritioning is customizable, which means, we could also use 16 parameter layers with 64 steps (-> 4 measures) for polyphony in a single track. But this doesn't really load the STM32 chip, nothing speaks against the usage of 32 or 48 tracks (e.g. 32 additional tracks for percussions, which consume much less RAM than fullly featured tracks) The most important thing - and this was the point which really scared me, as it required a lot of pre-work: loading a complete pattern from SD Card takes only 7 mS in worst case. And even if multiple patterns are loaded for different track groups in song mode, it won't affect the sequencer timings, as MBSEQ is now working with a MIDI event scheduler in a separate high priority task which ensures super stable timings while patterns are loaded or stored. The sequencer is clocked at 384ppqn in master and slave mode, which is 16 times the normal 24ppqn MIDI clock resolution. I haven't noticed any robustness issues yet, but I must also say, that I haven't made songs with MBSEQV4 yet - programming this beast is too much fun! ;) A MIDI file player is already implemented as well. It will be possible to import/export patterns via .mid files, as there is more than enough flash memory free for such features. Due to the dramatically increased pattern size, BankSticks won't be supported anymore. Instead a SD Card is required, which is much faster and more comfortable to use anyhow (e.g. for exchanging files, or to create backups) The bank format is flexible enough to cover different track partitionings and future enhancements. A bank consists of 64 patterns, and takes 368674 bytes. The number of available banks isn't really limited, so you can take different banks for different purposes (e.g. different banks for different MIDI devices and/or music styles), and sort your setup this way. All banks/patterns/tracks can be named with 20 characters. Thanks to the new "freedom" in memory size/CPU speed and C language, certain features which seemed to be impossible for MBSEQ V3 were a really no-brainer for MBSEQ V4. Like the "Echo Fx", which was completely programmed in two hours, and worked almost immediately w/o much debugging effort... ... which brings me to the conclusion, that it cannot take so long until MBSEQ V4 is ready for an alpha release - for those who own a Mac: you will be able to try it out immediately. ;) Status MBHP_CORE_STM32 module: I will get a second batch of 25 prototypes in ca. 2 weeks, they are already assigned to forum users with programmer status. It will be released if there are no errors anymore. Upload via MIDI is already possible, so that there is no need for a JTAG programmer, considered that somebody (like Smash) pre-programmed the chip. But there are also inexpensive solutions to program the bootloader with a common RS232 interface. Once this has been done, code can be uploaded via USB (which works btw. even faster than JTAG). More about this topic sooner or later in another article. Best Regards, Thorsten.

No, it isn't - can you confirm that this only happens for G4? Then it's a strange bug Any hint on which line I can try to fix it? ;) Best Regards, Thorsten.

No, this cannot be "fixed". Displaying realtime informations from the slaves would produce too much CAN bus traffic. Best Regards, Thorsten.

Congrats! Great Achievement! :) Best Regards, Thorsten.

This will result into the problem, that the IIC specs will be violated for all other IIC slaves connected to the bus. Not only that it wouldn't be possible to access them anymore if the switch is enabled, it could also result into corrupted data transfers if your device is accessed faster than 400 kHz while other slaves should be in passive state (e.g., because they cannot read their address fast enough, and could unintentionally assume, that they have to drive the bus) Accordingly, I strongly recomment you to provide separate functions at module basis, and to use the IIC pins only optionally. In your specific case it could make sense, for other applications it's a killer, as other IIC slaves (especially MBHP_IIC_MIDI) cannot be used in parallel. Best Regards, Thorsten.

Hi, you are trying to upload a MBSID V1 bank - this won't work. The same patches (with stereo support and some additional bassline/drum patches) are part of the MBSID V2 release package. You will find it under presets/v2_vintage_bank.syx Best Regards, Thorsten.

A new MIOS Studio version is available which got a lot of improvements to improve the robustness. -> http://www.ucapps.de/mios_download.html E.g., there was an error in the retry handling which corrupted the flash content under special circumstances. Accordingly, everybody is strongly recommented to use this new version to avoid, that MIOS or even the 1st level bootloader has to be installed again after a failing application upload. Best Regards, Thorsten.

Dito - hope your MP3 player isn't affected by the Z2k bug ;) http://forums.zune.net/403986/ShowPost.aspx Best Regards, Thorsten.

the linker will locate udata sections into BANKED area, and udata_acs sections into ACCESS area Btw.: this seems to be a bug in the mod_skel example, as it locates variables into the udata section w/o taken care of the BSR Short answer: In earlier derivatives like PIC16xx and PIC18F452, RA4 was only available as open drain pin due to compatibilty reasons. All other pins are working in Push Pull Mode Please ask Microchip support for the reasons ;) But this isn't an issue in your particular case (therefore just ignore the comment in the BankStick driver...) You don't use RA4, and if you would need open drain capabilities, you could control this via SW by setting LATx.y to 0 and toggling TRISx.y instead of LATx.y Best Regards, Thorsten.

The mod_skel example is provided by StrydOne, so I can only speak for my SD card driver: In order to allow highest flexibility, I used "movff" here, so that it doesn't matter if _sdcard_address is located in the ACCESS bank or not. I could also set the BSR before doing an "movwf", but prefered movff here (balancing question, mostly subjective and decided within 2 seconds, so please don't ask which method is better ;) In general, using the ACCESS bank speeds up the code, but it also reduces available directly accessible memory (e.g. for temporal variables) - therefore it's expensive and should only be used if it really makes sense. no, but if you would have to set the BSR before transfering the the value into the register, it would result into 2*16 bit/2 cycles as well. In addition, it would destroy the current content of BSR, and it would lead to two code lines instead of one. If destroying the BSR is no issue, I usually decide to use either SET_BSR/movwf ...BANKED or movff depending on the lunar calendar ;) If you are asking for the best solution: allow to locate your variables into the BANKED area so long the functions are taking more than 10 uS execution time (so that one or more additional cycles don't really matter). If more than one BANKED register is accessed and BSR doesn't need to be restored, change the BSR instead of using movff Best Regards, Thorsten.

Hi Braintu, the original schematic is located here: http://svnmios.midibox.org/listing.php?repname=svn.mios&path=%2Ftrunk%2Fschematics%2Fclockbox%2F It has to be edited with xcircuit Best Regards, Thorsten.

Sorry - wrong movie ;) MBCV uses it's own initialisation routine for J5, I still haven't changed it to j5_io.inc Means: for proper initialisation, it's required to change ;; disable the ADC which allocates the analog pins movlw 0x07 movwf ADCON1 [/code] to [code] movlw 0x0f ; all newer PIC18F derivatives (like PIC18F4685) movwf ADCON1 in j5_dout.inc (this change won't be required anymore once I'm using j5_io module in MBCV) Best Regards, Thorsten.

There was an incompatibility to PIC18F4685, caused by direct accesses to the GATES variable, which is located in a range which is reserved for CAN on this special derivative. I fixed this in cv_map.inc Best Regards, Thorsten.

According to my records, I sent you the small parcel on 21th november, more than one month ago. If you don't get it in the next 3 weeks, please write me a PM and we will try to solve this Best Regards, Thorsten.

Drivers are called "modules" PIC based MIOS: (see this directory) it doesn't matter if you program them in C or assembly. I prefer assembly to achieve best performance on the PIC MIOS32: (see this directory) only C to improve portability Best Regards, Thorsten.

You are using MIOS Studio to upload MIOS and the MIDIO128 application (both provided as .hex file) This is like you are installing Windows and any other program, which gets use of Windows functions After installation you will already be able to control DIN and DOUT pins with predefined Note and CC events, they are matching with the MIDI events predefined under tools/mk_midio128_syx/midio128.ini If you want to change predefined events *after installation* of MIDIO128, just follow the instructions under tools/mk_midio128_syx/README.txt The described approach allows you to customize the events w/o creating a new .hex file and installing the MIDIO128 application again. If you prefer to modify the program directly, edit src/midio_presets.inc, build a new .hex file (your own MIDIO128 variant) and upload it with MIOS Studio Sorry for all the confusion, but I tried to provide a simple and more flexible approach - it seems that this only leads to unnecessary complexity Best Regards, Thorsten.

If you find the location and calculate a new checksum for the appr. line, it could work - but it's error prone. For details, how to build a new .hex file, see http://www.midibox.org/dokuwiki/application_development However, I re-uploaded the .zip package with changed version number. Best Regards, Thorsten.