TK.

Hi, FreeRTOS controls the timesplices, it performs preemptive multitasking (see also this tutorial. However, using a timer is a better idea in this case, so you are already on the right route. Just for interest: why are you not using J16 with HW based SPI? another task could interrupt the task which generates the bitstream for J19, FreeRTOS guarantees that each task will be serviced in 1 mS On the other hand this means, that the bitstream generation will be slowed down... Again: using a timer is a good idea if HW based SPI at J16 can't be used. First idea: which SPI parameters are required for the slave? Clock Phase, clock polarity? There are four possibilities, and if you chose the wrong one, data transfer will be corrupted. In your current code, data is set with the falling clock edge, and data is read with the rising clock edge - does this comply with the datasheet of your SPI device? Best Regards, Thorsten.

The MBHP_CORE_LPC17 board will require this standard development board called LPCXPRESSO. So, in distance to MBHP_CORE_STM32 the chip + additional circuitry (like Ethernet PHY, small I2C EEPROM, crystals) won't be part of the board anymore. The kids would call it "shield" ;) This means also, that it will be possible to provide different variants for different purposes, or that somebody solders the additional components on a vero board like I did, e.g. to customize the interfaces/plugs for his case. Best Regards, Thorsten.

For those who prefer pictures: The LPCXPRESSO board is worldwide available for ca. 20 EUR + taxes: http://www.embeddedartists.com/products/lpcxpresso/lpc1769_xpr.php It's completely presoldered and tested. It will be put on top of the MBHP_CORE_LPC17 module which will provide the PSU and interfaces to the MIDIbox Hardware Platform. -> back to DIY friendly design! :) Best Regards, Thorsten.

Great that we sorted this out! :) of course, no problem ;) Best Regards, Thorsten.

Hi, yes, this can be achieved with following setup: ... [MIDI_IN] 1 = 90 30 2 = 91 30 3 = 92 30 4 = 93 30 ... [/code] This passes C-2 on Channel 1/2/3/4 to DOUT pin 1/2/3/4 Best Regards, Thorsten.

FPGA? Best Regards, Thorsten.

Hi, using DIN/DOUT modules for this purpose doesn't make sense! Scans wouldn't be fast enough anyhow ;) Direct routing of MIDI signals can be achieved with simple multiplexers, such as 74HC151. This chip routes one of 8 inputs to an output. 3 select lines allow to select the input Circuit for a 8x8 matrix (without support for input merging): - 8 MIDI INs with dedicated optocouplers - the circuit looks similar to the known MIDI IN stage of the core module - 8 74HC151, route the outputs of the MIDI IN stages to the inputs of these chips (each MIDI IN connected to each chip) - the 74HC151 outputs can be directly used for MIDI OUT, just add 220 Ohm resistors as known from the core module - the 8x3 select lines of the 74HC151 could be controlled from a MBHP_DOUTX4 module Best Regards, Thorsten.

Sounds like a pull-up isn't soldered correctly. Could you please doublecheck that R2 and especially R12 of the core module are properly soldered? Note that R12 is located under the PIC, and a bridge has to be added between J4 and this resistor (red cable in this snapshot: http://www.ucapps.de/mbhp/mbhp_core_v3.gif) Best Regards, Thorsten.

Yes, the network is correct, 221 means 22*10^1 = 220 Ohm Hm.... another possibility: could it be that the LED is connected to the wrong DOUT pin? How many LEDs are already connected? Only one? Do you know that DOUT Pin #0 is assigned to the leftmost output pin of the MBHP_DOUT_DINX4 module (J4:D7), and not to J4:D0? Best Regards, Thorsten.

The termination is (normaly) only required if multiple DIN/DOUT SRs are chained in mixed order like I did for MBSEQ (today I wouldn't do it this way anymore) It shouldn't be required if DIN and DOUT modules are connected in separate chains. Important: the cables should be as short as possible, between Core and the first DIN/DOUT module not longer than 30 cm! If this doesn't help, it's definitely related to the pull-up resistors. The 220 Ohm array has to be used! (neither 1k nor 10k) Best Regards, Thorsten.

Yes, alcohol (like isopropanol) will be fine for cleaning up the flux. Best Regards, Thorsten.

The ribbon cable shouldn't cause a problem, my own modules are connected this way as well. Could you please try the IIC MIDI Software Loopback test? -> http://www.ucapps.de/mios/iic_midi_sw_loopback_v1c.zip See this README.txt for details: http://svnmios.midibox.org/filedetails.php?repname=svn.mios&path=%2Ftrunk%2Fapps%2Ftroubleshooting%2Fiic_midi_sw_loopback%2FREADME.txt Maybe it gives us some additional hints. Best Regards, Thorsten.

Update: how many MBHP_IIC_MIDI modules are connected to your router? It's very important that IIC_MIDI_MAX_NUMBER (defined in iic_midi_tick.asm) matches with the number of connected modules. This is especially important for the experiment I described above (some PIC16F88 pulled out) If less than 4 modules are connected, and IIC_MIDI_MAX_NUMBER isn't matching, the firmware will retry MIDI transfers multiple times - this can result into delays. Best Regards, Thorsten.

Did you connect the 4 RI lines to J5 of the core module in the right order? http://www.ucapps.de/midi_router/midi_router_interconnections.pdf And what happens if only a single IIC_MIDI module is running? (just pull out the PIC16F88 ICs of the remaining modules) Best Regards, Thorsten.

Hi Koert, sorry for the late reply, the simple reason is that I'm a bit puzzled about this case (but I don't want to say that I don't find this puzzle interesting! ;)) My own MIDIbox Router is running with latest MIOS, and latest released application and MBHP_IIC_MIDI firmware. Forwarding the MIDI input of an IIC input to a MIDI output of an IIC output is a very common case at my side, e.g. if MBSEQ sends MIDI events to my MBSID and MBFM. I'm still thinking about a test strategy which could help to find the root cause - I'm very interested in this case to improve robustness. Btw.: the delay of 1.5 seconds probably means that the MIDI protocol is violated (a "MIDI timeout" should happen in this case) Could you please describe, which devices you are using to test the router? Best Regards, Thorsten.

Martin: I second this! And I saw Hawkeye live in my room! Just enter a certain sequence and he starts to improvise lovely tunes immediately! :) This video triggered me to find a solution for detecting bad encoders, and to filter out unwanted jumps. Noise leads to high increment values, they should be limited. Best Regards, Thorsten.

Nils: the pure software approach isn't optimal, as it will introduce some jitter, especially when this routine is interrupted. The better approach would be the usage of an integrated timer + capture/compare unit which outputs the waveform directly on an output pin. Than faster it is running, and than higher the resolution, than better (see also the comments on the frequency accuracy of Juno DCOs at Tom Wiltshire's website) E.g. on a PIC you could use MIOS_TIMER_Init to initialize the frequency (assigned to TIMER3), and use the CCP1 unit to output 0 or 1 on pin #17 based on the compare value. More details about these units can be found in the PIC18F452 datasheet (and in the user manuals) The signal will be available at pin 17 (J7:SO of the core module). There will be a 0->1 transition when the compare value is reached, and it will go back to 0 when the timer period is reached. This means in other words: you are not only able to output a pulse waveform, but also to generate PWM with a few register writes. I remember that somebody implemented a very simple synthesizer based on this approach, the code is buried somewhere in this forum. Best Regards, Thorsten.

:ike: MIDIboxSEQ V4.0beta39 ~~~~~~~~~~~~~~~~~~~~~ o BUTTON_PAR_LAYER_A working again (was overwritten by BUTTON_DIRECT_TRACK16) [/code] next bug, please! ;) Best Regards, Thorsten.

Since some months we consider to change to the TAPR Noncommercial Hardware License, which would allow everybody to build and sell up to 10 units in any 12 month period on a non-profit basis w/o need for a special permission from our side. Without going too much into details (please open a new thread if you feel that this needs more discussion, but there will be a topic soon anyhow): this license would explicitly allow a professional or hobbyists to build and sell a MIDIbox to another user if he is only paid for his expenses (w/o profit) It would also make it less complicated to resell a used MIDIbox, no special permission required from our side as long as the NCL isn't violated. TBS violated the old license (no commercial use without my permission), and they would also violate the new license (e.g. by renaming the project and not mentioning the copyright holders - also the announced price of 1500 EUR somehow doesn't match with the "non-profit" term). Btw: for the case that you are interested on a MB6582, check this fleamarket sale by Lucem: Best Regards, Thorsten.

The owner of Mode Machines replies in facebook: These statements are simply not true! Some months ago we found a MIDIbox SID on the TBS product page. Nils contacted the company, explained the legal status (during a long phone call) and got the answer that they are not planning to sell the MIDIbox anymore. But it can still be found on their page, and now we saw it at Musikmesse as well. false, they never contacted me. false, they are currently not talking to us (in distance: Nils had to pro-actively contact them some weeks ago and thought that this topic is clarified). And I must say that I'm not interested to talk with profiteers with such attitude. Especially since it seems that they have no experience with the MBSID hardware/software - who should support the customers? Best Regards, Thorsten.

Btw.: Could it be that you moved your posting into the trashcan by yourself? ;-)

Sorry, I don't know who moved it into the trashcan, and I don't know how to undo this. I must admit that I'm very unfamiliar with all the options provided by this forum system... For the records: Param1 wrote at 18:01 (and I'm sure that this doesn't need to be censored): Best Regards, Thorsten.

yes, for those who are planning to build a new case. You can be sure that there will be an inexpensive and simple upgrade path! :) Best Regards, Thorsten.

I'm not amused about this - they haven't asked me for permission! :-/ Best Regards, Thorsten.

Because with a STM32F103RE it isn't possible to run USB and CAN in parallel, and the alternative STM32F105 derivative has only 256k flash maximum, which isn't sufficient for the software. I was waiting more than 2 years for a real alternative... but no suitable soluation from STM. So I tried a NXP LPC17 derivative instead and it's much better for the intended usecase. Not only that USB, CAN can run in parallel, and that an ethernet controller is integrated (unfortunately w/o PHY)... the performance is almost twice as good, giving me more headroom for more features (and/or extremely high update rates) The price is the same - so no real need to stick on a STM32 anymore. Best Regards, Thorsten.