TK.

LiFo: you are mixing decimal with hexadecimal numbers. According to the documentation: http://www.ucapps.de/mios_fun.html#MIOS_LCD_YAddressSet, a 4x20 display needs following offsets: MIOS_LCD_YAddressSet(0x00, 0x40, 0x14, 0x54); this function call can be inserted into the Init() hook. Thereafter you can access the display lines with: MIOS_LCD_CursorSet(0x00 + <column>); // for the first line MIOS_LCD_CursorSet(0x40 + <column>); // for the second line MIOS_LCD_CursorSet(0x80 + <column>); // for the third line MIOS_LCD_CursorSet(0xc0 + <column>); // for the fourth line Best Regards, Thorsten.

You wrote, that the old PIC sends an upload request during startup. This means, that you should be able to upload MIOS and the application again, right? Maybe the upload was errornous during the first try, MIOS Studio normaly reports this, did you notice any special message? Best Regards, Thorsten.

Hi Jeffry, you will find my answers here: http://www.midibox.org/dokuwiki/doku.php?id=midibox_sid&rev=1143304777&do=diff Best Regards, Thorsten.

It could be, that you've connected the pot in the wrong way - this can cause a short, which resets the PIC, and normaly also damages the pot. Could you please explain, which pot you are using exactly, and how it is connected? Best Regards, Thorsten.

Hallo Pico, nein, der Bug existiert nach wie vor, er tritt jedoch nur unter bestimmten Umstaenden auf. Der Code, den ich im Microchip Forum gepostet habe, provoziert den Fehlerfall indem kuenstliche Delays zwischen Empfangen und Senden eines Bytes eingefuegt werden. Wenn Du das Interface nur in einer Richtung testest, wird der Fehler niemals auftreten. Mach mal einen Hardware-Loopback (MIDI Out->MIDI In) und sende einen laengeren Sysex Stream (bspw. aus 1500 Bytes), der keine 00-en enthaelt. Wenn Du diesen String nun 20..30 mal sendest, kann es passieren, dass 1 oder 2 zusaetzliche Bytes gesendet werden, und zwar 00en (die ja eigentlich nicht im SysEx Dump enthalten sind). Wenn Du Glueck hast, wird der Fehler auch nicht auftreten - es haengt von der USB Firmware ab. Wenn Du dann an irgendeiner sensiblen Stelle (bspw. im Interrupt Handler) ein paar zusaetzliche Befehle einfuegst, wird er wieder auftauchen. Oder wenn Du mit einem anderen MIDI Interface, einen anderen Computer oder ae. Daten austauschst, koennte der Fehler ebenfalls auftauchen Was mich interessieren wuerde (es geht hier um ein anderes undokumentiertes Problem mit "blocked pipes"): ist es mit Deiner USB Firmware moeglich, groessere SysEx Dumps mit Bloecken >10000 Bytes (zwischen F0 und F7) ueber den oben beschrieben Hardware-Loopback ohne Datenverlust zu uebertragen? Gruss, Thorsten (aus einem Internetcafe in Mailand ;-)

I've started a page which lists the forum highlights, it might be a good "information center" for people who are new to the forum. http://www.midibox.org/dokuwiki/doku.php?id=forum_highlights feel free to add your favourite links (*) Best Regards, Thorsten. (*) I don't want to say, that the first entries are my only favourites! I wasn't able to find them all again within the short time ;-)

Could somebody please send me a non-working 74LS165 for evaluation? Best Regards, Thorsten.

Hi, with the MB64E application this seems to be feasible. The USB keyboard option is a nice idea! It would be very nice, if you would document your design in the Wiki later, because many people have introduced their dedicated live controller in the past, but the build process was never written down, and is therefore lost as source of information for others, who are planning to do something similar. Best Regards, Thorsten.

Hi, you will find my answer here: http://www.midibox.org/dokuwiki/doku.php?id=midibox64_e_patchmode Best Regards, Thorsten.

Hallo Jack, die ueberarbeitete (assembler basierte) USB Firmware fuer den PIC18F4550 ist bereits fertig und laeuft stabil. Jemand aus dem Forum entwickelt gerade einen neuen Windows Treiber, der wesentlich performanter als der Legacy M$ Treiber sein wird. Linux und Mac User koennen wie bei MBHP_USB den normalen USB MIDI Treiber verwenden. Gruss, Thorsten.

yes, no idea... the 74LS165 should be ok, but I could also be wrong. With the srio_interconnection_test you could at least ensure, that the connections to the module are ok Best Regards, Thorsten.

From your posting it's not clear to me, if you've already checked it without connecting the MIDI In or not... Some possible reasons: bad soldering joint, broken MIDI cable (which sometimes works, sometimes not), problem with your PC MIDI driver, problem with your PC software. When you read this troubleshooting section, you will find a lot of strange reasons for failures... maybe this helps! Best Regards, Thorsten.

Mittlerweile hat das Projekt den Status erreicht, in dem ich es mal praxisnah testen kann. So sieht mein momentanes Routing aus: Manche Browser schneiden das Bild an der rechten Seite ab - hier die komplette version: http://www.ucapps.de/midi_router/midi_router_default.gif Und so der Code in router.c (meiner Meinung nach ist es noch einigermassen ueberschaubar :) ///////////////////////////////////////////////////////////////////////////// // These functions are called from the MIDI parser when a new package has been // received. They can be modified to customize the routing // // evnt0, evnt1, evnt2: the bytes of the MIDI event which has been received // // ptype: package type // - 0x02 two-byte system common message like MTC, Song Select, etc. // - 0x03 three-byte system common message like SSP, etc. // - 0x04 SysEx starts or continues // - 0x05 SysEx ends with following single byte // - 0x06 SysEx ends with following two bytes // - 0x07 SysEx ends with following three bytes // - 0x08 Note Off // - 0x09 Note On // - 0x0a Poly-Key Pressure // - 0x0b Control Change // - 0x0c Program Change // - 0x0d Channel Pressure // - 0x0e Pitch Bend // - 0x0f single byte like MIDI Clock/Start/Stop/Continue ///////////////////////////////////////////////////////////////////////////// void ROUTER_Rx_INT0(unsigned char ptype, unsigned char evnt0, unsigned char evnt1, unsigned char evnt2) __wparam { // Core MIDI IN, connected to my PC // lock/release this routing path on SysEx streams ROUTER_LockPathOnSysEx(PORT_INT0, ptype); // forward data to the MIDI OUTs of all IIC slaves ROUTER_Tx_IIC0(ptype, evnt0, evnt1, evnt2); ROUTER_Tx_IIC1(ptype, evnt0, evnt1, evnt2); ROUTER_Tx_IIC2(ptype, evnt0, evnt1, evnt2); ROUTER_Tx_IIC3(ptype, evnt0, evnt1, evnt2); } void ROUTER_Rx_IIC0(unsigned char ptype, unsigned char evnt0, unsigned char evnt1, unsigned char evnt2) __wparam { // IIC0: connected to my MIDIbox SID // lock/release this routing path on SysEx streams ROUTER_LockPathOnSysEx(PORT_IIC0, ptype); // forward data to the Core MIDI OUT ROUTER_Tx_INT0(ptype, evnt0, evnt1, evnt2); } void ROUTER_Rx_IIC1(unsigned char ptype, unsigned char evnt0, unsigned char evnt1, unsigned char evnt2) __wparam { // IIC1: connected to my MIDIbox FM // lock/release this routing path on SysEx streams ROUTER_LockPathOnSysEx(PORT_IIC1, ptype); // forward data to the Core MIDI OUT ROUTER_Tx_INT0(ptype, evnt0, evnt1, evnt2); } void ROUTER_Rx_IIC2(unsigned char ptype, unsigned char evnt0, unsigned char evnt1, unsigned char evnt2) __wparam { // IIC2: connected to my MIDIbox SEQ // lock/release this routing path on SysEx streams ROUTER_LockPathOnSysEx(PORT_IIC2, ptype); // forward MIDI clock/start/stop/continue to all IIC modules if( evnt0 >= 0xf8 && evnt0 <= 0xfc ) { ROUTER_Tx_IIC0(ptype, evnt0, evnt1, evnt2); ROUTER_Tx_IIC1(ptype, evnt0, evnt1, evnt2); ROUTER_Tx_IIC2(ptype, evnt0, evnt1, evnt2); ROUTER_Tx_IIC3(ptype, evnt0, evnt1, evnt2); } if( (ptype >= 0x08 && ptype <= 0x0e) && ((evnt0 & 0x0f) >= MIDI_CHN9) ) { // directly forward MIDI channel #9..#16 messages to MIDIbox SID and MIDIbox FM only ROUTER_Tx_IIC0(ptype, evnt0, evnt1, evnt2); ROUTER_Tx_IIC1(ptype, evnt0, evnt1, evnt2); } else { // forward all other events to the Core MIDI OUT ROUTER_Tx_INT0(ptype, evnt0, evnt1, evnt2); } } void ROUTER_Rx_IIC3(unsigned char ptype, unsigned char evnt0, unsigned char evnt1, unsigned char evnt2) __wparam { unsigned char transposed_note; // IIC3: connected to my Yamaha AN1x // lock/release this routing path on SysEx streams ROUTER_LockPathOnSysEx(PORT_IIC3, ptype); // if note on/off at channel #16 has been received, change it in the // following way: // - send notes < C-4 to MIDIbox SID (IIC0), Channel #9 // - send notes < C-4 to MIDIbox SEQ (IIC2), Channel #1, transposed by 2 octaves // - send notes >= C-4 to MIDIbox FM (IIC1), Channel #13 if( (ptype >= 0x08 && ptype <= 0x09) && ((evnt0 & 0x0f) == MIDI_CHN16) ) { if( evnt1 < 0x3c ) { // evnt1 contains note number, 0x3c is C-4 ROUTER_Tx_IIC0(ptype, (evnt0 & 0xf0) | MIDI_CHN9, evnt1, evnt2); transposed_note = evnt1 + 2*12; while( transposed_note > 127 ) // avoid invalid notes, transposed_note -= 12; // transpose back until note number <= 127 ROUTER_Tx_IIC2(ptype, (evnt0 & 0xf0) | MIDI_CHN1, transposed_note, evnt2); } else { ROUTER_Tx_IIC1(ptype, (evnt0 & 0xf0) | MIDI_CHN13, evnt1, evnt2); } } // forward data (also) to the Core MIDI OUT ROUTER_Tx_INT0(ptype, evnt0, evnt1, evnt2); } [/code] Die USB Option kommt hier nicht zum Einsatz, dies wird ein separates Projekt (da MIOS auf dem PIC18F4550 aufgrund diverser Silicon Bugs nicht sauber laeuft) Bei USB gibt es dann 8 zusaetzliche Rx/Tx Kanaele, die man ebenfalls beliebig "verdrahten" kann. Gruss, Thorsten.

No, in this case there is no loopback - did you check this? Best Regards, Thorsten.

yes this heavily depends on the memory consumption of the data structure which stores the "virtual" states/positions The example is really simple (it should help to get a general understanding of the approach) and doesn't provide mapping. Please note that this example exists twice, one assembly based version, and a C based version Best Regards, Thorsten.

Hi, this could be a loopback problem, maybe you've enabled a forwarding option (MIDI In -> MIDI Out) in your software. If the merger of the MIDIbox is enabled as well, the data will be loopbacked endless Best Regards, Thorsten.

Stryd One: In order to avoid name conflicts, I've added a "stryd_one_..." prefix before your links. Example: [[stryd_one_MBSeq|MBSeq]] (the text behind the | is the description which will be displayed) I've also removed user_gallery and usergalley, since they are redundant. Currently I propose to add your names to the mainpage Best Regards, Thorsten.

It's very simple, you only need to insert an internal link into a page in order to create a new page. Example: after login click on the "edit this page" button. Insert [[blogs]] somewhere in the mainpage (where it makes sense). After this change has been saved, you can click on the Blogs link in order to view and edit this page... Best Regards, Thorsten.

Yes - and if the remaining 6 pins of second DOUT are not used, you could take the MIOS_DOUT_SRSet function as well (but this is your decition - it doesn't save that much cycles) Best Regards, Thorsten.

Short question: did you also create the DOUTX2 module? Is it already connected to the core? Because somebody just reported, that this PCB has two bugs, they lead to a short circuit Best Regards, Thorsten.

Currently I can only say, that this needs to be evaluated. This is a long process, just consider, that I've to upgrade my own MIDIboxes by PIC18F4620 + I2C slaves, I've to modify the applications, and I've to make some music in order to say: yes, it works ok for daily work This is a process which can take some months The MBHP_IIC_MIDI module is just the first step... Best Regards, Thorsten. P.S.: I decided to use a PIC16F derivative, because most PIC18F* have an anoying IIC bug! (-> BF flag erratum)

No, they "prepare" the incoming data in form of packages, the master has to poll for updates. This is a complex topic which cannot be explained in a few number of lines (therefore: please wait for the documentation). There is a I2C specification available on the Philips website which helps to understand the common approach Best Regards, Thorsten.

Short answer: an even more powerful method is the use of the I2C protocol. In the last days I've worked out just another demonstrator, which shows, that this protocol is not only useful for accessing EEPROMs and LCDs from a MIOS core, but also to exchance data with other microcontrollers (see http://www.ucapps.de/mbhp/mbhp_iic_midi.pdf and http://www.ucapps.de/mbhp/mbhp_iic_midi_preview.jpg - this is a II<->MIDI bridge which allows to control multiple MIDI interfaces from a "master" core via I2C I will write some documentation and especially programming examples to this project after my holidays. In the meantime you could work on the I2C slave routines for Atmel (for PIC I can provide a tested template) - MIOS already provides MIOS_IIC_* functions for I2C master accesses (an OS change is not required) Another hint: Duggle has worked out a PIC based application for PS/2->MIDI some time ago, you could contact him in order to prevent double-effort. I think that a modification for PS/2<->I2C isn't that difficult Best Regards, Thorsten.

Wenn ich bis morgen (Samstag) das DOUTX2 Layout nicht gefixed habe, bitte nochmal melden. Zur 909: hierfuer gibt es eine Loesung, die in diesem Artikel gepostet wurde (wichtig: Hallucinogen's Hinweis auf den Schreibfehler beachten!) http://www.midibox.org/forum/index.php?topic=2701.0 Fuer diesen Tip verpflichte ich ich nun, die Erweiterung im Wiki zu dokumentieren! (zur not auch auf Deutsch, jemand anderes kann es immer noch uebersetzen) Gruss, Thorsten.

The SRSet function is just the fastest way to change 8 bits at once. This is useful when setting patterns (-> time multiplexed circuits, like LED digits or LED rings), and it's useful if the state of digital outputs is mirrored somewhere in the application (useful if you want to switch between two or more "layers") Best Regards, Thorsten.