TK.

You've me full respect for this work - not without reasons it took 5 years until somebody successfully completed the entire project! Best Regards, Thorsten.

Your configuration is outdated, please find valid information in the hwcfg/wilba_tpd/MBSEQ_HW.V4 file which is part of the release package. There you will find a new parameter which allows to enable more SRIOs: # maximum number of connected shift registers in a DIN or DOUT chain (1..23) SRIO_NUM_SR 23and you will find an update in the comments which refer to valid SR ranges Best Regards, Thorsten.

Here some amphetamine for those who haven't built their case yet! :-) Note that I added some enhancements & fixes to the MBSEQ firmware while working on this demo (demos are always a good possibility for me to doublecheck that everything is working as expected!). The changes are already in the SVN repository and will be released soon. Best Regards, Thorsten.

This video is a tribute to Andy aka. Latigid On who created a sophisticated PCB and Case which finally (after more than 5 years!) allows to build a BLM16x16+X for their MIDIbox SEQ V4. Best Regards, Thorsten.

Yes, they do! Very good work! Finally you are able to display the keyboard split zones with different colors, right? Best Regards, Thorsten.

They define the track length. The track length is also the loop end Best Regards, Thorsten.

No, this isn't correct. In MIOS32, many other interrupts are running. Also MIOS32_TIMER based app callbacks are called from interrupts with a much shorter interval if required. I've use cases in my own applications where I have to handle incoming bytes immediately. E.g. MIDI clock in slave mode requires that processes are (immediately) clocked with each incoming 0xf8, and/or that delays are measured between the 0xf8 events to avoid unwanted jitter. have a look into the MBCV V2 application where I'm running high prio synth processing with a MIOS32_TIMER I don't think that you need this - it would especially conflict with my own applications, so it would be a dedicated modification at your side, which isn't required if your ISR meets the requirements that I mentioned above. So, I ask you again: does your ISR consume more than 500 uS? (I don't think so...!) IIC needs high priority as well, USB doesn't (it's a handshake protocol), SPI is only a question of required bandwidth (but SD Card transfers are handled via DMA already...), no risk for data loss. Best Regards, Thorsten.

It isn't that easy, because you've to differ between ROM (=flash) and RAM, and especially for LPC17 between the lower and upper RAM bank. Before overcomplicating things: check the RAM pointers, ignore other sizes. Best Regards, Thorsten.

No, I don't know exactly how much stack memory is required. Once we touched the limit, users will typically complain about hard faults, which tells me that the last feature consumed too much RAM... If you want to be at the secure side, take the current __ram_end as the one which shouldn't be exceeded There is no optimization flag which would allow to reduce the RAM consumption, the only way is to remove existing features, or to use one of the newer cores (such as MBHP_CORE_STM32F4) Best Regards, Thorsten.

LPC17 has two RAM banks, one goes from 0x10000000..0x10007fff, and the second from 0x2007c000..0x20083fff But special care is required for the first bank, because the stack for background task (&IRQs) will be located from __ram_end..0x10007fff. It depends on the application itself how much stack memory is required for the background task, and since the worst case stack usage is difficult to determine, this is typically a source for unintended hard faults. Best Regards, Thorsten.

For single color LEDs, 220 Ohm should be fine regardless if green or red LEDs are used. More information (also about the LED polarity) can be found in the Wiki under: http://www.midibox.org/dokuwiki/doku.php?id=wilba_mb_seq_construction_guide Best Regards, Thorsten.

ok, I've to shorten the label name in the next release MIDI clock event handling is still on the TODO list - so, yes, could be possible sooner or later. the rainbow effect is handled in the background task. It's possible that it will be disabled from a higher prio task while new LED values are written, this results into the effect that you see. However, In the next release, LEDs should be cleared correctly. yes, it's plausible: timings are not ensured when functions (like the rainbow effect) are called from the background task. The AINSER module will cause some additional CPU load and this will slow down the rainbow effect. Not critical from my point of view (assuming that we are talking about a testing feature) Best Regards, Thorsten.

Unfortunately I can't help here, it requires a windows expert to check for options to overcome this issue. For MacOS it's sufficient to give each core a dedicated USB device name (see also: http://www.ucapps.de/mios32_bootstrap_newbies.html ) But as far as I know, this name isn't take by the Windows driver. Best Regards, Thorsten.

yes If you only need 10bit, 5631 is a good choice. Best Regards, Thorsten.

Got the case as well - really nice and especially robust one, I like it! :)

Actually you are right. If we ignore the initial question about the usage of MIOS32 w/o FreeRTOS the answer is simple: interrupt priorities are centrally defined in mios32_irq.h, and I also commented the reason for certain priority decisions there: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Finclude%2Fmios32%2Fmios32_irq.h Since Saureans application relies on UART based MIDI, it has to be ensured that the UART handler has such a high priority, that incoming bytes can't get lost. If time critical ISRs never consume more than ca. 500 uS in worst case, even if they are requested back-to-back, they could just run with superhigh priority (priority value < MIOS32_IRQ_PRIO_HIGHEST, e.g. 3) to fulfill the requirements w/o any changes in MIOS32 or the programming model. Best Regards, Thorsten.

The BLM port is nothing else than a combined MIDI IN/OUT. The QUAD IIC Board has already the required resistor and optocoupler components, so all you need to do is to connect one MI/MO pair + Vs + Vd from MIDI IO to the port to the Quad IIC Board Best Regards, Thorsten.

See this architectural overview which shows, how MIOS32 apps are structured: http://www.ucapps.de/mios32/mios32_flowchart.png The brown blocks are FreeRTOS related. The good news: none of them is located in trunk/mios32, but under programming_models/traditional Which means in other words: all you need to do is to create your own programming model w/o FreeRTOS, the "traditional" version can be taken as a reference. Alternatively, if you don't consider to share this model in different applications, you could locate main() and the a timer based task handling directly in your app.c file. Best Regards, Thorsten.

Just compare the brightness if only a small number of LEDs are enabled with fully brightness vs. all LEDs enabled at the same time. you could recompile the firmware with #define WS2812_NUM_LEDS 90 in the src/mios32_config.h file to allow the control of up to 90 RGB LEDs Best Regards, Thorsten.

As long as you don't enable all LEDs with full brightness, the power consumption is much lower, so that you could supply the strip via J4B The meta description says "LED 1-64", because in the driver only 64 LEDs are enabled (each LED consumes 48 bytes, therefore I'm careful). However, if somebody wants to drive more than 64 LEDs, I could increase the number. Here a new version which supports EVENT_RGBLED: -> http://www.ucapps.de/mios32/midibox_ng_v1_033_pre18.zip o added EVENT_RGBLED See cfg/test/rgbled_1.ngc for usage examples o .NGR file: added "set_hsv" command which allows to control the hue parameters of a RGBLEDNote that the meta commands that I introduced yesterday writes into the RGB LED RAM directly, while a EVENT_RGBLED will store the value in the patch and will overwrite this value on any update. That's also the reason why we need a "set_hsv" command which allows to change the HSV value of a RGBLED event which remains in the patch. Here some usage examples: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fmidibox_ng_v1%2Fcfg%2Ftests%2Frgbled_1.ngc Best Regards, Thorsten.

Code is ready for testing! :-) -> http://www.ucapps.de/mios32/midibox_ng_v1_033_pre17.zip Currently only meta commands are provided, more control (such as EVENT_RGBLED) will be available later: o support for WS2812 LED strips (currently only for the MBHP_CORE_STM32F4 module). The data input has to be connected to J4B.SC, ground to J4B.VS and +5V to an external PSU (required, since each RGB LED can consume up to 20 mA!) Following meta event commands are available: - RgbLedClearAll (clears all LEDs) - RgbLedSetRgb:<led>:<r>:<g>:<b> (led=1..64, r/g/b=0..255) - RgbLedSetHsv:<led>:<h>:<s>:<v> (led=1..64, h=0..359, s=0..100, v=0..100) - RgbLedRainbow:<speed>:<brightness> (speed=1..255, brightness=0..100) Most simple way to test a LED strip: enter following command in MIOS Terminal ngr exec_meta RgbLedRainbow:9:100 (don't forget to wear sunglasses, or start with brightness 20!!! ;-)Technical details: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fmodules%2Fws2812%2Fws2812.c And for the blink: following GIF shows "ngr exec_meta RgbLedRainbow:9:20" Best Regards, Thorsten.

Yes, good news! 140 nS should be feasible if bitbanging is handled by a DMA channel with highest priority. I ordered the LED stripe that I linked above and will test this weekend. If it works like expected, MBNG will get a new EVENT type which will allow to access the LEDs with 8bit resolution. Best Regards, Thorsten.

cool! :) Best Regards, Thorsten.

Btw.: please update the repository - yesterday I noticed that in MBNG the KEYBOARD_Periodic_1mS() function was running in the wrong task (background instead of APP_Tick()) This could cause random velocity values if LCD messages are print as well. Best Regards, Thorsten.