TK.

I'm in contact with www.heidenreich.de for manufacturing nice looking aluminum desktop cases based on their "Multiformis" system which can be used for 17"/3U frontpanels like Wilba's MBSEQ frontpanel, but also for other purposes/MIDIboxes. After some alignment discussions I got a prototype and I must say that I'm really happy with the results! :) Note that this is only a "quick prototype" with untreated aluminum for checking the dimensions with existing components (frontpanel, MBSEQ_CORE_STM32 and other modules). The final option could be anodized black! /update: picture of the black case: More pictures and additional comments: see this album Estimated price: ca. 50..60 EUR if we order at least 10 pieces We will get better prices if we order higher quantities. Note that the price doesn't include the front- and backpanel, they have to be ordered separately (e.g. at Schaeffer or from More informations about the backpanel soon. If you are interested in this desktop case, please add your username to this list: http://www.midibox.org/dokuwiki/doku.php?do=show&id=tk_mb_seq_case_bulk_order Update: here are the exact measures: http://www.ucapps.de/midibox_seq/mbseq_case_measures.pdf FPD File for Backpanel: http://www.ucapps.de/midibox_seq/tk_mbseq_backpanel_v1_1.zip NOTE: not compatible with new MBHP_CORE_LPC17 module, since the Ethernet socket is now part of the Core PCB! Best Regards, Thorsten.

Following orders have been shipped today: orgelman dcer10 (via Nils) phunk skennedy Following orders will be shipped next weekend (once I got the money...) ssp runinit potain Best Regards, Thorsten.

Mouser berechnet auf dem Gesamtpreis eine VAT. Wie die sich genau zusammenstellt ist nicht ganz transparent. Doch sie liegt i.d.R bei ca. 21..22% - insofern stimmt das mit Seppos Erfahrungen ueberein (19% + X) Auch den schnellen Versand kann ich bestaetigen - nach 2 Tagen steht der Fedex-Mann vor der Tuer (und i.d.R. am naechsten Tag schon wieder, da Fedex zu unmoeglichen Zeiten liefert) Leider ist mein Bedarf momentan ebenfalls gedeckt - vielleicht im Winter wieder :) Gruss, Thorsten.

wegen des Pull-Up Widerstands solltest Du am RX Pin auch ohne den PIC ca. 5V messen - wenn das nicht der Fall ist (ich bin bei meinen vorigen Aussagen davon ausgegangen...), dann liegt das Problem woanders. Verfolge mal mit dem Messgeraet saemtliche Leiterbahnen die 5V und Masse fuehren. Irgendwo hast Du eine Loetstelle vergessen, oder die Leiterbahn ist beschaedigt. Wenn der TX Pin auf 5V geht, laeuft der PIC. Ohne Programmiergeraet gibt es keine andere Moeglichkeit. Um eine Vss (Masse)-Verbindung zu ueberpruefen, schliesst Du den Plus-Pol Deines Messgeraets an einen 5V Pin (bspw. J2:Vs), und greifst mit dem Minus-Pol die Spannung an der Vss Leiterbahn (bzw. an dem Pin) ab. Gruss, Thorsten.

fixed Best Regards, Thorsten.

Nein, an TX solltest Du keine Spannung messen, wenn der PIC nicht eingesetzt ist. An RX misst Du in diesem Fall wegen des Pull-Up Widerstands R6 ca. 5V Wenn die Spannungen an den Vdd/Vss pins passen, kann es eigentlich nur noch an der Oszillatorschaltung (C1/C2/Q1) liegen - oder der PIC wurde nicht sauber geflasht (-> der MIOS Bootloader laeuft nicht an) Gruss, Thorsten.

W/o the risk for drifting too much into an off-topic discussion: two years sounds realistic - not to complete all of your vague ideas, but at least to find something which works at your side. And I'm sure that you will gain a lot of experience by starting from scratch. :) Have fun and don't hesitate to ask for details if something is unclear or not working, and/or to share your code (write permission to the subversion server is available for all programmers) Best Regards, Thorsten.

Thanks for the introduction, now I understand why you asked this question. Welcome to the wikipedia generation! ;) It will be hard for you to find an explicit answer in the internet, since a DMA peripheral is used for multiple purposes. There are differences between chip families and there are different usecases. You probably know from your AVR history, that as long as the CPU handles a data transfer with the polling method, it would get frequently interrupted by interrupt service routines. As a result this reduces the bandwidth. Even interrupt based transfers can block each other, they lead to unwanted dependencies (-> complex, inflexible, intransparent, timing critical, hard to maintain code) and they reduce the performance of the main thread(s). In the MIOS32 specific context you have to consider that functions are running in FreeRTOS based threads that are timespliced. By using a DMA (which you probably don't known from AVR controllers) data transfers will be handled in background >>immediately<< w/o using the CPU. A CPU thread typically waits until the complete transfer (with a definable number of bytes) has been finished. While doing this it can be interrupted by other threads/ISRs - but the bandwidth won't be affected. Nils is still our No#1 layout slave and deserves my full trust! :) Your idea doesn't sound so unusual to me. If you would know my applications better, you would know that the concepts are already available (e.g. search for MBNET and the appr. source codes - it exists for "low-cost" PICs and STM32), resp. that complete applications already exist. The reason why I don't "sell" this as a "workstation concept" is just that I know that people would expect a bit more than just some programming experiments, but a complete "plug&play" infrastructure for cheap money, similar to Yamaha MLAN. What I can already tell you: such a infrastructure will cost a lot of money (since multiple chips are involved), a lot of programming effort and at the end also chip resources (more flash/RAM memory for higher flexibility during runtime) The art (and you will see this point in 10..20 years) is to create a simplified infrastructure which doesn't support everything, but which makes most people and especially yourself happy, for as less money as possible with as less effort as possible. But I don't really want to reduce youthful enthusiasm - maybe you will find a clever solution which hasn't been found by somebody else before by working on a high-level approach based on existing concepts, and/or just by ignoring any objections! :) Best Regards, Thorsten.

Hi, Not yet, but soon. Only the USB driver has to be overworked due to the new peripheral version. It's hard for me to explain you the details if I don't know your background knowledge. Could you please introduce yourself first, tell something about your skills and what you already realized before so that it's easier for me to give you individual help? A chip select line can be located at any free IO pin. There are so many different applications that I'm sure that you won't find any free pin which is not allocated by any of them ;) Therefore pins (and SPI ports) are usually mapped via #define statements that can be overruled in a mios32_config.h file The next MBHP_CORE_STM32 module (planned for next year) will use at least a 100 pin device. More details about such topics can be found in the programmers lounge. I already gave you access to this hidden forum section. Best Regards, Thorsten.