TK.

MIOS_Bankstick_WritePage is a blocking function, you can be sure that the programming process has finished when the function is exit. See also this programming example. You have to ensure, that no IRQ routine accesses the BankStick while it is accessed from the "main" program, of course... regardless if the content is read or written. "Verify" just reads and compares the written content. I used it in the early days to doublecheck if BankStick writes are reliable. They are - therefore I mostly disable it in my own application meanwhile. Best Regards, Thorsten.

There are 4 possible ways to handle the shifting (SR bit orientation, SR chain orientation), ca. 8 years ago I selected one which matches best with my own MIDIbox HW, meanwhile 1000s of MIDIboxes exist which are using correct DOUT wiring. Now you request a software flag for more flexibility as a workaround for incorrect wiring at your side. The software flag would affect the performance of all existing MIDIboxes. And it would lead to a higher memory consumption of MIOS, so that other features would have to be removed (as MIOS already allocates most of the "system" area in flash). Instead, I would propose one of following solutions: fix your DOUT wiring and help to improve documentation modify the bit order in mios_srio.inc and build your private MIOS version, so that no HW change is required add the flexibility inside your application - it's the most simple solution for both - programmers and users - and it doesn't waste memory at MIOS side (which is very very limited - I can't repeat this often enough. Fortunately it has been relaxed dramatically with the MIOS32 approach (-> modular kernel) - but please don't mix the new possibilities with the old PIC MIOS approach (-> static kernel)!) Best Regards, Thorsten. P.S.: the disadvantage of your idea: DOUT SR assignments have to be adapted whenever the number of SRs in the chain is changed via MIOS_SRIO_NumberSet() - this doesn't really make sense.

fine! :) You should consider to use read-modify-write instructions (sbi/cbi on Atmel AVR) to control the pins, otherwise you will have to disable all interrupts which access the same port while reading/changing/writing the port output value. Another advantage: this results into a step wise approach, which is required anyhow to avoid race conditions (like setting the serial output and SCLK at the same moment) And it's faster (a single instruction to set/clear a pin) :) 8 MHz is quite slow, so that no "nops" (delays) are required. By unrolling the loop, you should be able to write a single SID register in ca. 11..12 uS Best Regards, Thorsten.

Thats fine. I assume that one of the following issues leads to instable register writes: setup or hold violations while loading the serial registers. I don't know, if you are using the SPI peripheral, or if you are using a SW based bitbanging method. For testing purposes, just reduce the frequency (bitbanging: insert some NOPs between shifts) - especially ensure, that there is a delay between setting the serial input of 74HC595, and setting SCLK=1 CS# active (=0) while updating the address/data values - ensure, that CS# is 1 there should be a delay between the rising RCLK edge (74HC595 take over address/data values) and the falling CS# edge to ensure, that the data/addresses are stable during CS#=0 Could it be, that mega8535 is clocked at a higher frequency? Then such IO timing issues would be obvious. If this doesn't help, just show your code - it says more than 1000 words ;) Best Regards, Thorsten.

Yes - and it's an intented "effect" to simplify the handling at application side. Simple example: MIOS_DOUT_SRSet(0, MIOS_DIN_SRGet(0)); works without reversing the pin positions. Please give me a phrasing which is good enough, so that nobody who creates an own PCB overlooks the reversed DOUT pin mapping. I will insert it into the schematics. Best Regards, Thorsten.

I accessed the SID totally asynchronously many years w/o such problems. It works, so long it is ensured that address/data is stable before CS# (and WE#) has been activated. The pulse width of the CS# line should be at least 1.2 uS at 1 MHz SID clock rate. There is only one issue which could happen on asynchronous control: the gate could be triggered twice. But you will notice this effect only on very sophisticated drum sounds - I guess, that you are far away from such a step ;) Recently I rewrote the SID access routines in C. For the case it helps: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fmodules%2Fsid%2Fsid.c Best Regards, Thorsten.

Are you using only one, or all 3 oscillators with the same pitch? Do you notice effects similar to this example? http://www.ucapps.de/mp3/midibox_sid/mbsidv2_osc_phaseoffset.mp3 Best Regards, Thorsten.

There is a DIN/DOUT table in the wiki - I would propose to improve it Best Regards, Thorsten.

There is no reason why the bootloader should affect the program execution. I'm also not aware about a compatibility issue with MIOS itself. Best Regards, Thorsten.

It already has been answered here: http://www.midibox.org/forum/index.php/topic,12379.msg103109.html#msg103109 For your own comfort: don't start double posts! Best Regards, Thorsten.

Thats normal - while DINs are scanned in backward direction (last bit received last), DOUTs are scanned in forward direction (last bit sent first). Therefore the bit correlation is swapped on DOUTs. If you would follow the programmers section, you would know, that I was close to decide to change the order in MIOS32: http://www.midibox.org/forum/index.php/topic,12141.msg100435.html#msg100435 But finally decided to keep it compatible with PIC based MIOS, as most application would have to reverse the pins anyhow - e.g. to transfer DIN register values to DOUT register values: http://www.midibox.org/forum/index.php/topic,12141.msg101954.html#msg101954 Best Regards, Thorsten.

I'm not able to reproduce this (as I don't have access to your hardware) - I did a quick check on a matrix keyboard, but without seeing the failure symptoms you described. Is anybody beside of jb using the "sm_fast" variant? However, one thing you could try is to insert some waitcycles after the SCLK 0->1 edge search for the SM_BUTTON_HANDLER_SHIFT_Cont label, and change the code below this label the following way: ;; toggle shift clock to 1 bsf SM_SRIO_LAT_SCLK, SM_SRIO_PIN_SCLK nop nop nop [/code] If this doesn't help, I'm out of ideas... Best Regards, Thorsten.

Hi Phil, I'm planning to update the IIC_MIDI firmware soon to provide a "raw IO" mode. So long it isn't available, you could also use the MBHP_IIC_SPEAKJET firmware which already matches with your requirements. Best Regards, Thorsten.

From the Manual Best Regards, Thorsten.

MIOS32 is already ported to C for STM32F10x derivatives, which contain an ARM Cortex-M3 CPU :) http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2F&sc=0 Best Regards, Thorsten.

The upcoming STM32 based core module will provide an USB interface for MIDI and/or COM (-> e.g. for OSC) by default. In addition, you will get 2 MIDI IOs, CAN, IIC and several ports & drivers to external devices like SD Card, I2S (-> Audio Output), Ethernet, etc... and to all existing MBHP modules of course ;) Best Regards, Thorsten.

How about sending "dummy realtime messages" like 0xfe to add a defined delay between the SysEx commands. The DX7 shouldn't react one these events, and it doesn't hurt if one or more bytes get lost. This would be the most simple solution. All others are more complicated. The problem: since the MPROC parser and AIN/ENC/DIN handler are running with the same priority, it isn't possible to wait for an acknowledge message parsed from MPROC_NotifyReceivedByte() hook while waiting in DIN_NotifyToggle(), ENC_NotifyChange() or AIN_NotifyChange() for this message before continuing sending new SysEx messages (Sidenote: only MIOS32 will allow an elegant interaction between these tasks by using methods provided by a RTOS) Possible solutions for PIC based MIOS: a) program a "mailbox" system where the AIN/ENC/DIN handler puts new SysEx commands (in compressed format to save RAM) into a queue. In addition, program a SysEx parser which checks for acknowledge messages and notifies this to a queue handler. The queue handler has to be added to the Tick() hook. It checks for new messages, and sends them if the previous message has been acknowledged by the SysEx parser. Disadvantage: high RAM consumption b) there is a hidden hook in MIOS which allows you to parse incoming MIDI bytes interrupt driven. It has to be executed so fast as possible, therefore there is no (official) link to the C wrapper. In other words: this hook has to be programmed in assembly language. The parser which matches with your requirements is very simple, maybe it would already be sufficient to check for 0xf7? Using this method simplifies the programming model dramatically: - clear "F7" notifier (a volatile, global variable) - send SysEx message to DX7 - wait until "F7" notifier has been set to 1 by the interrupt driven MIDI receiver - done Disadvantage: you have to learn a bit assembly language, and I don't have the time to support you that much ;) Programming example for including the interrupt driven hook into a C application: http://svnmios.midibox.org/listing.php?repname=svn.mios&path=%2Ftrunk%2Fmodules%2Fmidi_rxtx_leds%2F Programming example for a tiny SysEx parser which resists in this hook: http://svnmios.midibox.org/filedetails.php?repname=svn.mios&path=%2Ftrunk%2Fapps%2Fexamples%2Fasm%2Fled_digits_mtc%2Fmtc.inc Best Regards, Thorsten.

Big news: Wilba got the package today! And this was really unexpected at least from my side, especially because I sent a claim form to the german post for tracking back the delivery, and only got the answer that it arrived Australia. Wilba checked the delivery in an Australian post office and got no helpful answer at all. This was one month ago... However, Wilba will forward the parts this week. :) Now I have a new issue: I got a lot of donations to compensate a financial loss which doesn't exist anymore. I just refunded the money, because I would feel guilty to use it for a different purpose, and it's free (no money loss for both sides) - if you want to support future development (e.g. for the new MBHP_CORE_STM32 module), just donate again :) Donated PCBs: how about the possibility to get some free 5x5 boards instead? I would re-sell the PCBs, and send the money to Kartoshka/Nils instead. Ok from your side? Best Regards, Thorsten.

You've access to the programmers Lounge - so, why not reading the articles about the upcoming 32bit approach? ;) Best Regards, Thorsten.

Btw.: the MIOS32 based version already supports RGB LEDs - as you can see: writing the app completely in C improves the expandability ;) Best Regards, Thorsten.

Looks simple - added to the Wishlist :) Best Regards, Thorsten.

Newsflash: see http://www.midibox.org/forum/index.php/topic,11387.msg102356.html#msg102356 Donations have been refunded - thank you anyhow!!! You guys are so great! :) A big thanks to all donators: Bugfight, Screaming Rabbit, Levon, Narwhal, amp1ron, SLP, kokiPsiho, StrydOne, /tilted/, Jack, Kartoshka, Enth, Doug Wellington, Flemming, Lief, Jan Forsmark I counted 22 PCB donations + ca. 200 EUR, which means that the loss is almost covered! :) Please send the PCBs back to me - this should be easier to handle, and it also gives me the possibility to mix new with old ones (why? details see below) Ok, I just have ordered 250 chips + 200 PCBs (I will hold some PCBs in stock for the next run) Final price: GM5 = 4.50 EUR, PCB = 3 EUR You have to pay within 3 weeks once I got the goods from Ploytec (I will inform you later about the expected delivery date) You will get a PM about all the paying/shipping options once this happens - don't ask now Updates on GM5: the new firmware allows full access over the EEPROM, so that up to 5 IOs can be defined with an own VID/PID and Device name - nothing else (yet). The EEPROM option itself is only a minor feature. It helps to separate the modules in the device list if more than 2 devices are connected to a PC, so that they don't appear under the same name. Instead of midibox.org or ploytec.com you could give it the name of your wife/girlfriend or whoever ;) Updates on PCB V1.2 (see MBHP_USB_GM5 page): - USB socket now grounded (but it will also work w/o this connection - it's just better) - two additional holes for shield of MIDI sockets (there are two different types, both are compatible now) - new jumper J8 which allows to select between midibox.org and ploytec.com configuration Note that the firmware of the previous GM5 run already featured the midibox.org configuration, but it wasn't communicated to me. Means: you can already select the midibox.org configuration by grounding IO4 with a small wire. The australians will partly get the new and donated PCB - only noticeable difference: some will appear as "ploytec.com", some others as "midibox.org" device by default. Best Regards, Thorsten.

I asked Ploytec: it's no problem to order 250 chips + PCBs now, and the next batch some weeks/months later. :) So, I will order them very soon. Please check the number of PCBs: http://www.midibox.org/dokuwiki/tk_gm5_bulkorder if you ordered an extension board as well: http://www.midibox.org/dokuwiki/gm5_expansion_5x5_board the small PCBs are not required - just remove the requested quantity from the tk_gm5_bulkorder list. Another - very sad - note: it seems that the package I sent to Wilba is lost. Therefore the australians haven't got their order yet. The package contained 46 GM5 chips and 34 PCBs and wasn't insured (damned!), accordingly I lost ca. 300 EUR! :( I sold the chips/PCBs for non-profit, which means that I have no margin to compensate the loss. But all affected people can be sure, that they will get their ordered parts soon w/o paying again (I just added them to the beginning of the list), and this time I will send it directly for fast and more secure shipping. This opens the question, which possibilities I have to get back the lost money: paying it from my own pocket since I was so naive to send the package uninsured and w/o tracking - in this case, I'm not sure if I'm willing to handle the next orders anymore due to the high risk of money loss or asking you for donations or increasing the price of GM5 from 4.17 EUR to 5 EUR, so that I'm able to get a margin to cover the costs Opinions? Newsflash: see http://www.midibox.org/forum/index.php/topic,11387.msg102356.html#msg102356 Donations have been refunded - thank you anyhow!!! Best Regards, Thorsten.

TEASER!

No, you would have to write "udata_acs" instead of "udata" However, there is no reason why not using BANKED memory range. It won't really have an impact on the performance of your function. Best Regards, Thorsten.