Duggle

Thanks for the hint! It caused me to look at the size of another queue in my app which made a difference. However it did not come fully good until I disabled debug messages as you suggested. I had been using #define MIOS32_MIDI_DEBUG_PORT UART0 which I didn't would be a problem but it clearly is/was. I'm now thinking about how I increase the (data buffer) capacity for debug messages. My app is not resource heavy and I'm using an F4 core, so there should be plenty available.

My MIO32 application is failing when the host computer sends too much USB sysex to my F4 core at application startup. I have tried to increase MIOS32_USB_MIDI_RX_BUFFER_SIZE to 0x400 and MIOS32_USB_MIDI_DATA_IN_SIZE to 128 (256 and the USB of the core basically stops working) This has not changed the behaviour... I'm not sure what I'm doing but I would like to increase the USB midi data rx buffer. Thanks for any help.

The usual way is to have the shift registers close to where their io is needed. This minimises interconnects and tracks. The high speed serial wires can be kept reliable and quiet with source impedance matching resistor on the clock line IIRC.

good now. WooHoo! thanks for the tip!

I'm developing a midi monitor that listens to 4 of USB MIDI Ports. So I'm using MiosStudio for debug messages on UART0. I'm made a code change to my app which has stopped USB from working (I changed buffer sizes). Anyhow, to upload fixed code I am trying to upload on the UART0 connection and I have always found that MiosStudio complains that it cannot contact the bootloader even though the query message always works. Is this expected? Is so is there a way to rebuild the bootloader to enable UART0 bootloading? I suppose I can reset the core using ST Link but I hope I don't have to!

Like I said the previous index of blue led is addressed. I'm not saying there's a bug in the repo, because I used it fine in the recent past. The problem affects both WS2812_LED_SetRGB(led,2,val), and WS2812_LED_GetRGB(led,2,val) i.e getting and setting the Blue led. To make things work right I have made the following changes to ws2812.c (to get me out of trouble...) if( colour == 0 ) colour_ix = 2; else if( colour == 1 ) colour_ix = 0; else if( colour == 2 ){ colour_ix = 1; led++; } else return -2; // unsupported colour i.e increment led for the blue (and only blue) LED. in both the Get and Set function. This is obviously a problem of my own making but I can't see what i could have done to cause it! :-)

I'm away from my usual development computer so I've set up all the tools on my laptop and compiled an app that I'm developing. In this new context I'm finding that the blue colour component is showing on the previous LED in the chain. extern "C" void APP_Init(void){ // mled.test(); // Initialise all LEDs MIOS32_BOARD_LED_Init(0xffffffff); WS2812_Init(0); WS2812_LED_SetRGB(10,0,100); WS2812_LED_SetRGB(10,1,000); WS2812_LED_SetRGB(10,2,100); So here we see LED #9 is blue and LED #10 is red. This also happens with WS2812_LED_SetHSV(..). I'm left with the fact that it seems to be a problem in the driver that wasn't in my other setup which I don't have access to ATM. Any help appreciated!

Thanks TK. That is understandable, It would be nice to have in this specific instance but straight forward to do without as well.

Using ENC command it is possible to specify which DIN pins of which Shift Register an encoder is wired to. Is it possible to do this with buttons? You see I'm assembling a large array of encoders that have push switches, and to rationalise (neaten) the wiring I would like the encoder pins and its push switch pin to use adjacent pins on the DIN Shift Register(s). Thanks for any hints!

That's great news. I suspect the problem I have between GM5 and Midibox NG is something different. I'll need to revisit it. Do you know which field(s) need to be different between the 2 cores?

AFAIK the solution is not so simple as changing some data in the bootloader, but I can be wrong.

I have had a very similar problem between a midibox core and my GM5 under windows 7 that I never solved. Also had the same problem under windows 10 IIRC. Seems really sad to have to buy a new USB OEM midi interface if I want to connect a midibox on the same computer! Sorry I can't help, but I would love a fix for this also...

OK, I've stripped the alternate ngc to the absolute minimum: RESET_HW LCD "%C" ENC n=1 sr=5 pins=0:1 type=non_detented EVENT_ENC id= 1 hw_id= 1 fwd_id=LED_MATRIX:17 bank=1 fwd_to_lcd=1 chn=2 type=CC range=0:127 offset=0 ports=1000010000000000 led_matrix_pattern=3 cc=17 offset=-64 syxdump_pos=1:17 label="^Osc1Shp" Encoder #1 outputs data on CC#17 on channel 1. Any help appreciated.

Hi, thanks, yes there is: ROUTER n= 1 src_port=IN1 src_chn=17 dst_port=OUT2 dst_chn=17 ROUTER n= 2 src_port=IN2 src_chn=17 dst_port=OUT1 dst_chn=17 ROUTER n= 3 src_port=IN3 src_chn=17 dst_port=OUT4 dst_chn=17 ROUTER n= 4 src_port=IN4 src_chn=17 dst_port=OUT3 dst_chn=17 ROUTER n= 5 src_port=USB1 src_chn=17 dst_port=OUT2 dst_chn=17 ROUTER n= 6 src_port=IN2 src_chn=17 dst_port=USB1 dst_chn=17 Nodes 5 and 6 are the only ones that are important at the moment. The value 17 means all channels passed and none translated IIRC.....

I'm talking about MIDI events channel number, not ports. In the config, as shown above, the CC should happen on midi channel 2, but its seen to be on channel 1.