TK.

Ah - thanks, now I also remember this effect. It should be documented at the MBHP pages Best Regards, Thorsten.

Hallo, nein, den Takt kann man nicht erhoehen, es gibt in der Slave Firmware einen kritischen Pfad, der eingehalten werden muss (Delay zwischen zwei empfangenen Bytes) - wenn der Master also zwei Bytes schneller sendet, als der Slave sie weiterverarbeiten kann, kommt es zu einem Not-Acknowledge, und somit zu einem Retry. Die Performance wuerde darunter leiden. kannst Du doch machen... ;-) Gruss, Thorsten.

I think, that this is not an electrical, but a conceptional issue. Computer keyboards are usually polled with a rate of 50 times per second (-> 20 mS), this is not fast enough for your project. With the sm_example2 project you could do the same at a rate of 12500 times per second (-> 80 uS) Best Regards, Thorsten.

the reason for this issue would be really interesting, because I also have no explanation, why another adapter should lead to higher voltages behind the 7805. There could be a short at the bottom of the PCB, therefore it would be helpful if you could post a photo of the front- and bottom side of your board (you can send me the pictures, I will put them on the server) Best Regards, Thorsten.

just compare the C code above with the assembly version within the MIDIbox SEQ package (midi_evnt.inc, MIDI_EVNT_PrintNote) There are two versions, one iterative, one table based (which is disabled). The iterative version works fast enough. The loop which determines the octave takes ca. 13 uS in worst case (highest octave), thats appr. the same time it takes to print a character on LCD, and this is the point: The LCD always needs some time to print a character. MIOS polls for the busy flag before (and not after) a new character is transfered to the display. This has the advantage, that the CPU can do something else during the busy state without loosing performance. Best Regards, Thorsten.

this picture shows, how to measure the voltages:

Hi Todd, both - I'm planning to port even more applications to C in order to simplify the customization. One thing what I want to realize sooner or later is a generic "MIDI controller template" for all kind of control elements (and LCD output formats), which can be easily adapted to the host application - it's the "MIDIbox NG" idea, just in a different form - no graphical GUI or sysex dump for configuration, but C code which can be modified and enhanced easily. I'm happy that more people are now starting to program apps by themself, so this seems to be the right path. My long term strategy is to have some apps ready in a (more or less) processor independent language, so that the migration to another microcontroller will be easier. But this is a plan for the next 3 years, in short time the PIC18F4620 will do the job for "next generation MIDIboxes" (MBSID V2, MBSEQ V3). And if Microchip should release another pin compatible uC in the next years, it will be the successor for the MBHP as well. I would propose to start the sequencer in C. On performance issues, you can replace parts of the core functions by assembly code. If you run into greater performance (or code size) problems, then you need to write the whole app in ASM, but this will be easier, since you've propably already tried out the "general concepts" in C (rapid prototyping is faster) For MBSEQ/MBSID/MBFM I will stay on ASM Best Regards, Thorsten.

The function overview of MIOS has been overworked - there is an alternative page now which shows declarations and examples in C style: http://www.ucapps.de/cmios_fun.html Best Regards, Thorsten.

Hi Geert, very good that you are measuring the voltages before stuffing the chips - otherwise you would have a dead PIC and SID now! the 104 is a 100nF as well. no, only wrongly mounted the voltage regulators could be the reason Best Regards, Thorsten.

Hi Sam, the serial connections from the DIN/DOUT module to the board should be as short as possible. If the two boxes are very close together (ca. 30 cm maximum), you could build the modules into the second box. Use a shielded cable to protect the signals against influences from other gear! The cable must have 6 wires (Vs/Vd/SI/SO/SC/RC) and the shield to ground If you decide to build the modules into the first box, the cables to the button/LEDs can be very long (> 1 m or more), and EMC isn't a big issue here Best Regards, Thorsten.

die Anzahl der Buffer, sowie die Puffergroesse habe ich flexibel gehalten. Ich habe verschiedene Konfigurationen ausprobiert, momentan verwende ich folgende Einstellungen (in usbcls.asm) o 4 IN Buffer je 64 Bytes, Transferlaenge 64 Bytes o 2 OUT Buffer je 64 Bytes, Transferlaenge jedoch nur 8 Bytes Die Buffer koennen noch waehrend eines laufenden Transfers vorbereitet/abgearbeitet werden - das steigert vor allem auf der IN Seite die Performance. Die Pufferadresse wird von der Software gesteuert (kein Ping Pong Modus) Die Transferlaenge (welche im Endpoint Descriptor definiert ist -> usbdsc.c) habe ich reduziert, da hiermit der besagte Effekt im Loopback seltener auftritt (ich habe es einfach mal ausprobiert) Die Zahl habe ich nicht mehr im Kopf, doch ich kann sie bei gelegenheit ermitteln. USB MIDI unterstuetzt nur Bulk Transfers Denke schon, Windows ist nicht so mein Thema. ;-) das klingt interessant! Gibt es unter Windows so etwas wie /var/log/messages unter Unix, also ein systemweites Logfile, in dem solche Ereignisse hinterlegt werden? Das wuerde mich wundern, denn mit dem EZ-USB funktioniert diese Konfiguration problemlos. Steht das irgendwo in der USB Spec? Vor ein paar Tagen hatte ich mal temporaer die Konfiguration "IN auf EP1, OUT auf EP2" ausprobiert, der IN Buffer wurde weiterhin sporadisch (ohne erkennbares Schema) blockiert. Ich habe mal einen aktuellen Snapshot nach http://www.ucapps.de/tmp/mbhp_usb_pic_snapshot.zip gelegt. Der interessante Code steht unter usbcls.asm und usbdsc.c Ich sehe die UOWN Bits als Semaphore fuer den RAM Bereich: wenn beim OUT Buffer UOWN geloescht ist, weiss man, dass ein neues Packet angekommen ist. Man holt es sich ab, und setzt das Flag wieder (+ DTS Handshake). Beim IN Buffer geht man davon aus, dass er beschrieben werden darf, solange UOWN geloescht ist. Die SIE wird solange nicht darauf zugreifen, bis man UOWN wieder setzt. Solange man also die Regeln einhaelt, auf den Memory Bereich niemals zu schreiben, wenn UOWN gesetzt ist, und UOWN niemals via Software zu loeschen, kann nichts schieflaufen. Scheinbar, ansonsten wuerde die Uebertragung ueber einen anderen EP funktionieren. Es ist immer gut, wenn man mal darueber spricht :) Gruss, Thorsten.

Today AVR should be the first choice, it has a modern architecture, and is easier to program. Unrelated to your question I would like to mention, why I still stick to the PICs: it wouldn't take much time to port MIOS and most of the applications to AVR, but the support effort would be much higher (supporting two different architectures is a mess), and benefit wouldn't be that high. The only candidate which could be used for the MBHP is ATMEGA644 (64k flash, 40 pin DIP), but it's hard to get (as Wise mentioned), and the datasheet says "not recommended for new designs". All newer devices with more than 32k flash are only available in a TQFP package - if I ever take the risk to provide a core module with SMD devices, I would prefer a much more advanced 16bit or 32bit microcontroller. Especially an option for fast accesses to external flash/SRAMs would be very appreciated for a more flexible graphical LCD handling. Best Regards, Thorsten.

The biggest problem is, that I get new layouts without prewarning ca. all 2-3 months, and people don't see the effort on my side (the latest DOUX2 bug shows, what can happen when I don't pay enough attention for such layout changes). The funniest thing was last year, where somebody replaced all ICs by SMD parts, changed the routings, changed the copyright notice, and told me that the layout is "much better now" and expected that I have to check the new layouts and replace my old ones. He used an cracked version of eagle so that I was not able to open the .brd files... it took some emails to explain him, what is wrong with these layouts - and all this at a time where I wanted to do something else than discussing about PCBs... However, I've created a new Wiki page which allows everybody to share improved layouts: http://www.midibox.org/dokuwiki/doku.php?id=layout_improvements Best Regards, Thorsten.

Alex, I just came from holidays, was busy with sorting the forum postings, and haven't found the time yet to go through my emails. There are so many people who are asking me "important questions", so please let me some days to find some time for your email! I especially don't like it, when people assume, that I'm ignoring their emails when I have replied some other postings in the meantime. I cannot reply to everbody in zero-time! Best Regards, Thorsten.

FAQMARKER

Hallo Claudio, "pipes" sind die logischen Datenpfade zwischen USB host und slave, jeder "Endpoint" bietet zwei Pipes, eine fuer eingehende, eine andere fuer ausgehende Daten. es koennte sich hier um den gleichen Effekt handeln, er hat jedoch nichts mit Interrupts zu tun - ich habe die USB Firmware ja mittlerweile komplett in Assembler programmiert, nicht zuletzt, um vom C18 loszukommen (dessen Demo-Lizenz nach 3 Monaten ausgelaufen war), und natuerlich um die Performance zu verbessern. Nach wie vor koennen jedoch Daten verloren gehen, wenn die OUT pipe nicht sofort bedient wird, und etwas durch die IN pipe geschickt werden soll. Die IN pipe ist manchmal (schlecht reproduzierbar) fuer > 40 mS blockiert, dies fuehrt dann zu einem Buffer Overrun auf der Empfangsseite der MIDI Schnittstelle. Das alles laesst sich sehr einfach mit einem Oszilloskop debuggen, wenn man die EP*B*.UOWN flags auf IO pins legt, und sich eine Triggerbedingung schafft (Buffer Full) - dadurch kann ich auch einen Softwarefehler ausschliessen. Leider tritt der Effekt auch dann auf, wenn OUT und IN pipe auf verschiedene Endpoints liegen. Ob es mit dem Ping Pong Modus besser funktioniert, weiss ich nicht (ist mir zu umstaendlich, und hilft wahrscheinlich nicht weiter). Der einzige Workaround, der mir bisher eingefallen ist, waere die Programmierung eines neuen USB MIDI Drivers fuer Windows, der dieses Szenario vermeidet, und hierum kuemmert sich gerade Synapsys. Ich bin mir nicht 100% sicher (da ich auch nicht unnoetig viel Aufwand ins Debuggen stecken moechte), aber es koennte sich hierbei entweder um ein undokumentiertes Performance Problem handeln, oder gar um einen weiteren Silicon Bug im USB Peripheral. Mit der EZ-USB basierenden MBHP_USB Firmware tritt dieses Problem naemlich nicht auf, selbst wenn die Buffer fuer die seriellen Schnittstellen nur 8 byte gross sind! Hast Du die SysEx Transfers nun mal mit Deiner Firmware ausprobiert? Gruss, Thorsten.

Hallo, ja, es gibt einen Blackboxtest, doch der ist IMHO aufwaendiger zu realisieren, als den Core zu debuggen: http://www.midibox.org/users/willy/frattest.png Alternativ kannst Du die Verbindungen zu den DOUT/DIN Modulen mit dem srio_interconnection_test ueberpruefen (Anleitung steht in main.asm) Gruss, Thorsten.

Es ist gar nicht so abwegig, diese Applikation unter MIOS aufzubauen, doch ich wuerde Dir empfehlen, sie in C zu programmieren, das geht normalerweise schneller, und ist besser wartbar. Die zeitkritischen Dinge wie LCD Ausgabe und Timer getriggerte AD Konvertierung sind ja bereits Teil von MIOS und assembleroptimiert, der Rest ist eigentlich nur noch data processing und User Interaktion. Ein C Template fuer die von der MB64/64E/MF/CV/SEQ bekannten Menuesteuerung steht bereits auf meiner ToDo Liste - es sollte nicht so aufwaendig sein. Die Assembler basierte Version besteht im wesentlichen aus einer Tabelle (cs_menu_tables.inc), und einigen Routinen in cs_menu.inc, die diese Tabelleneintraege je nach gewaehlter Menueposition verarbeiten. Gruss, Thorsten.

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.