Duggle

Thanks, TK. The main thing is to understand what has to happen and that's pretty clear now.

Will it be possible to have a *large* number of LCD's? I've always felt that every control element needs a programmable label to identify it and give feedback as to it's current state. An example might be an array of 64encoders with a 2*40 LCD for every 4,6, or 8 knobs, that's a total of 16, 12, or 8 LCD's. I will surely build such a sick puppy!

I'm implementing a BLM based on modular LED matrix assembly. I think some users will find interesting and I'll post the details when its done. I'm finding the description of the "column mode" (my term) optimised patterns off-putting: BLM16x16 optimized LED pattern transfer with 90° rotated view (rows and columns swapped, LSB starts at top left edge!) Is it as simple as it might appear? That is, the specified pattern is applied to the specified column with the rows determined by the 2nd midi byte. The LSB of the pattern is applied to the first row (specified) in the column (specified). I don't see how (or why) anything is referred to as "rotated"?

I'm finding the legacy driver fails to communicate. I discovered two registry keys associated with the korg driver not present on the working installation: NumberOfDevices (or similar, set to 0) EnableMIDIIN (or similar, set to 2) I deleted both keys and the devices appear to applications :-) I'm still getting the same "null" sysex response to a patch dump request :-( I think I might have to abandon multiple USB ports for now. I realise I can use the USB interface on one of the keyboards to provide the connectivity to have patch editing/librarian on the second synth. I have still managed to achieve the setup I wanted it just means another long USB cable to the computer. The other way involves midi merging the keyboard with the computer (messy) but doable.

Here's an interesting one! music machine (legacy driver) the response to a patch dump is not recieved correctly and displayed wrongly: (last part of message) [3018.855] 90 75 00 Chn# 1 Note Off A-7 (optimized) [3018.855] 90 73 00 Chn# 1 Note Off G-7 (optimized) [3018.856] 90 20 00 Chn# 1 Note Off G#0 (optimized) [3018.856] 90 20 00 Chn# 1 Note Off G#0 (optimized) [3018.856] 90 4a 00 Chn# 1 Note Off D-4 (optimized) [3018.857] 90 53 00 Chn# 1 Note Off B-4 (optimized) [3018.857] 90 00 00 Chn# 1 Note Off c-2 (optimized) [3018.857] 90 04 00 Chn# 1 Note Off e-2 (optimized) [3018.858] 90 00 00 Chn# 1 Note Off c-2 (optimized) [3018.858] 90 01 00 Chn# 1 Note Off c#2 (optimized) [3018.858] 90 00 00 Chn# 1 Note Off c-2 (optimized) [3018.859] 90 7f 00 Chn# 1 Note Off G-8 (optimized) [3018.859] 90 22 00 Chn# 1 Note Off A#0 (optimized) [3018.859] f7 The "middle" bytes are actually the correct Sysex data. Then viola! it starts working correctly (patch req/dump) every time! I'll continue to explore....

Thanks for your help, TK! My development machine, KORG driver (win7 x64): 1) IN2 gives identical "null" Sysex response. My music machine, legacy driver, 4 port enabled (win7 x64): 1) both IN2,IN3 work correctly!!! Actually I was/am having a frustrating time trying to get the KORG driver to install properly on my music machine. It installs o.k with a device manager entry, but no ports are visible to applications. This happened since I tried to install with only one usb port enabled in the firmware. Since enabling the firmware for 4 ports, I then installed the KORG driver ( first attempt) on my development machine successfully. I will compare registry entries on the two machines to see if there is a difference....

I have (amongst others) the following connections with my SEQV4L: USB1->MIDI OUT1->Virus B Virus B->MIDI IN3->USB1 accordingly I have the corresponding router nodes set up: SRC:USB1 all DST:OUT1 all SRC:IN3 all DST:USB1 all With SEQ V4L IN A (USB1) selected as both midi in and out in mios studio: The normal patch dump request is sent: [1099.159] f0 00 20 33 01 00 30 01 00 f7 but a null sysex message is recieved: [1099.181] f0 00 00 f7 Now if I use my GM5 interface for mios studio MIDI IN and plug midi out of the virus into it: request: [3060.600] f0 00 20 33 01 00 30 01 00 f7 response: [3060.720] f0 00 20 33 01 00 10 01 00 07 00 00 00 03 .......................00 01 00 7f 22 f7 (success!) So it appears the path ->MIDI IN3->USB1 is not passing Sysex properly?

I have two keyboards attached to my SEQV4L: one that records to the sequencer (IN1->seq->OUT1(synth A))another that does not, but uses the router to merge the external clock as well as use USB connectivity. (IN2->OUT2(synth B))I have the IN->OUT button set to inactive and have set up router nodes IN1->OUT1, IN2->OUT2 so that the keyboards are controlling the respective synths correctly. So my question is: how do I stop the MIDI IN2 from writing to the sequencer?

Works great, Thank you so much Thorsten! There is a warning generated which I haven't looked into yet but here is: Creating object file for osc_server.c w:/sw/tempmios/trunk/modules/uip_task_standard/osc_server.c: In function 'OSC_SE RVER_AppCall': w:/sw/tempmios/trunk/modules/uip_task_standard/osc_server.c:273:7: warning: pass ing argument 3 of 'MIOS32_OSC_ParsePacket' discards qualifiers from pointer targ et type w:/sw/tempmios/trunk/include/mios32/mios32_osc.h:106:12: note: expected 'struct mios32_osc_search_tree_t *' but argument is of type 'const struct mios32_osc_sea rch_tree_t *' w:/sw/tempmios/trunk/modules/uip_task_standard/osc_server.c: At top level: w:/sw/tempmios/trunk/modules/uip_task_standard/osc_server.c:765:3: warning: init ialization discards qualifiers from pointer target type w:/sw/tempmios/trunk/modules/uip_task_standard/osc_server.c:766:3: warning: init ialization discards qualifiers from pointer target type w:/sw/tempmios/trunk/modules/uip_task_standard/osc_server.c:767:3: warning: init ialization discards qualifiers from pointer target type w:/sw/tempmios/trunk/modules/uip_task_standard/osc_server.c:768:3: warning: init ialization discards qualifiers from pointer target type w:/sw/tempmios/trunk/modules/uip_task_standard/osc_server.c:769:3: warning: init ialization discards qualifiers from pointer target type w:/sw/tempmios/trunk/modules/uip_task_standard/osc_server.c:770:3: warning: init ialization discards qualifiers from pointer target type w:/sw/tempmios/trunk/modules/uip_task_standard/osc_server.c:801:3: warning: init ialization discards qualifiers from pointer target type w:/sw/tempmios/trunk/modules/uip_task_standard/osc_server.c:803:3: warning: init ialization discards qualifiers from pointer target type w:/sw/tempmios/trunk/modules/uip_task_standard/osc_server.c:804:3: warning: init ialization discards qualifiers from pointer target type w:/sw/tempmios/trunk/modules/uip_task_standard/osc_server.c:805:3: warning: init ialization discards qualifiers from pointer target type w:/sw/tempmios/trunk/modules/uip_task_standard/osc_server.c:806:3: warning: init ialization discards qualifiers from pointer target type w:/sw/tempmios/trunk/modules/uip_task_standard/osc_server.c:807:3: warning: init ialization discards qualifiers from pointer target type w:/sw/tempmios/trunk/modules/uip_task_standard/osc_server.c:808:3: warning: init ialization discards qualifiers from pointer target type w:/sw/tempmios/trunk/modules/uip_task_standard/osc_server.c:809:3: warning: init ialization discards qualifiers from pointer target type w:/sw/tempmios/trunk/modules/uip_task_standard/osc_server.c:810:3: warning: init ialization discards qualifiers from pointer target type w:/sw/tempmios/trunk/modules/uip_task_standard/osc_server.c:811:3: warning: init ialization discards qualifiers from pointer target type w:/sw/tempmios/trunk/modules/uip_task_standard/osc_server.c:812:3: warning: init ialization discards qualifiers from pointer target type w:/sw/tempmios/trunk/modules/uip_task_standard/osc_server.c:813:3: warning: init ialization discards qualifiers from pointer target type w:/sw/tempmios/trunk/modules/uip_task_standard/osc_server.c:814:3: warning: init ialization discards qualifiers from pointer target type w:/sw/tempmios/trunk/modules/uip_task_standard/osc_server.c:815:3: warning: init ialization discards qualifiers from pointer target type w:/sw/tempmios/trunk/modules/uip_task_standard/osc_server.c:816:3: warning: init ialization discards qualifiers from pointer target type w:/sw/tempmios/trunk/modules/uip_task_standard/osc_server.c:817:3: warning: init ialization discards qualifiers from pointer target type w:/sw/tempmios/trunk/modules/uip_task_standard/osc_server.c:818:3: warning: init ialization discards qualifiers from pointer target type

The current layout is a little tight to be adding too many chips, I agree. The biggest improvement to brightness would be to add the ULN2803 to the row drivers. In the case of "all LED on" the maximum current for a whole row goes from 35mA to 16*35mA (the limit now coming from the column driver). That's 16 times brighter! Actually there is a current limit of something like 70mA per SR but the brightness increase will still be huge! The flicker issue (if it is desired) can be overcome in software (without adding SR's) by scheduling extra SRIO scans to say double the default rate. (BTW: Long chains of SR's (much higher than16) can be used with MBHP if good routing and termination are done, it's quite simple. TK has stated the limitation to stop newbies getting into trouble.)

Brightness may not be that important but if the LEDs disappear in moderate ambient room light then it cant be a good thing. If the row driver (which is limited to 35mA) is divided by 16 ( all row LEDs lit) then we have 2.2mA per LED. With 1/16 duty cycle then we'd have the equivalent brightness of 0.13mA per LED. That's really dim! ULN2803 makes a really convenient row driver used with a DOUT shift register ( the pins line up very well) and work really well in this specific application. With the standard 1mS SRIO refresh rate and a column driver with 8 rows instead of 16 that' s 1/8ms=125Hz with the current design 75.5Hz. The human eye will start to notice flicker below 100Hz. Hence the suggestion of extra shift registers. I've proposed the two changes as they would have a pretty big impact on the appearance of the display with a modest increase in parts count.

Sorry to arrive on this thread so late with advice for improvement. It's about the cathode row drivers and the brightness of the display: At present each row is driven by a single pin of a HC595. Each pin may draw only 35mA and is driving up 16 LEDs at 1/16 duty cycle. I predict that the current design is dull (not bright) and has excessive flicker. I'm proposing two changes that will improve the display substantially: Place a ULN2803 driver in line each of with SR1 and SR2. This will increase the max current in each row to around 1A. Will result in much brighter. See SmashTV info pages on the DOUT module wiring options for the picture with ULN28xx soldered into the position of the current limiting resistors. Note that the GND pin on the driver needs to be connected to power GND on the PCB.Include an extra pair of shift registers (duplicate SR3, SR4 and RN1,RN2) so that the display is driven in two halves. This will double the refresh rate (1/8 duty) resulting in double brightness and much less flicker. If I am correct, all of TK's designs have a maximum of 1/8 duty cycle.I think I read that this is the authors first attempt at PCB design. Well done, its a very nice layout! Those of us that have been doing this for many years know that you never achieve perfection first up. ( But you DO on subsequent iterations!)

When the sequencer is running I'm getting can't allocate 342 blocks at 835 repeatedly printed on the debug console. I suppose there is a better way to save 40 bytes in the upper ram?

My "quick fix" for the build problem when #define MIOS32_UART_NUM 4 was to reduce the heap by 1k: #define MIOS32_HEAP_SIZE 14*1024 change to #define MIOS32_HEAP_SIZE 13*1024 Will (might) this cause run time problems? Thanks

I've now got the LEDs working correctly by switching out any code with MIOS32_BOARD_J28_PinInit() or MIOS32_BOARD_J28_PinSet() involving pin 0, or 1. I'll provide the details when all the midi ports are working. If I now include #define MIOS32_UART_NUM 4 in mios32_config.h I get the following build error: c:/mios32_toolchain/bin/../lib/gcc/arm-none-eabi/4.5.1/../../../../arm-none-eabi/bin/ld.exe: project_build/project.elf section `.bss_ahb' will not fit in region `RAMAHB' c:/mios32_toolchain/bin/../lib/gcc/arm-none-eabi/4.5.1/../../../../arm-none-eabi/bin/ld.exe: region `RAMAHB' overflowed by 40 bytes collect2: ld returned 1 exit status make: *** [project_build/project.elf] Error 1 Any suggestion on how to resolve this? Thanks. (edit) I can now confirm that with #define MIOS32_UART_NUM 3 I'm not getting the build error and MIDI Port 3 is working!

What call(s) should I switch out with an #ifdef?

I've chosen J28.0 and J28.1 to drive the columns that were driven by J15.6 and J15.7 // LED columns at J5A/B MIOS32_BOARD_J5_Set(led_row[selected_row]); //***dug***bits 6 and 7 are not initialised for GPIO so have no effect MIOS32_BOARD_J28_Set(led_row[selected_row]>>6);//put 6,7 into 0,1 Is working but there is another (unused) peripheral accessing J28 when the sequencer is running causing an additional flicker to two of the led columns. It turns out there are calls involving J28 in seq_cv.c How do I disable the other function (Aout, I think) from the app build? PS: at the moment to make the affected led matrix columns work (at all) I call MIOS32_BOARD_J28_PinInit(0, MIOS32_BOARD_PIN_MODE_OUTPUT_PP); MIOS32_BOARD_J28_PinInit(1, MIOS32_BOARD_PIN_MODE_OUTPUT_PP); every time in BLM_CHEAPO_PrepareCol().

O.K, I think I've tracked down to where the column drivers are written: ///////////////////////////////////////////////////////////////////////////// //! This function services the row selection lines at J15 and the //! LED output lines at J5A/B //! It should be called from the APP_SRIO_ServicePrepare() //! \return < 0 on errors ///////////////////////////////////////////////////////////////////////////// s32 BLM_CHEAPO_PrepareCol(void) { if( ++selected_row >= 8 ) selected_row = 0; // selection lines at J15 u8 selection_mask = (1 << selected_row); MIOS32_BOARD_J15_DataSet(selection_mask); // LED columns at J5A/B MIOS32_BOARD_J5_Set(led_row[selected_row]); return 0; // no error } So it would appear that if I copy the bit states of bits 6 and 7 of led_row[selected_row] to the new I/O lines from say J19 then it will work as I need. Does selecting UART functionality mean that bits 6,7 of J5 are no longer affected by MIOS32_BOARD_J5_Set(led_row[selected_row]) ? Actually, J28 is free and also supported by the mios32_board.c functions so I'll try this.

I'd like to have 4 midi ports on my SEQV4L and have wired up the interfaces but I've hit a snag. MIDI IN/OUT4 is straight forward as J4B.SC and J4B.SD are unused in the SEQV4L. MIDI IN/OUT3 However, requires J5B.A6 and J5B.A7 which are currently used to drive LED matrix columns. It looks like it should be straight forward to use 2*I/O lines from either J8/9 or J19 for the last two LED column drivers and free up the MIDI IN/OUT3 pins. I'm having trouble finding my way around the source and would really appreciate some hints. Thanks!

I'm looking into two issues with compilation Command line:To have a batch file to set the environment for command line compilation (win XP and 7). There is the the setx which does the same thing that modifying computer/properties/environment variables dialog does only quicker as it is put in a batch file. I'm still looking into this.Eclipse project: I find that the eclipse project in repo (e.g. SeqV4L ) doesn't have mios files as linked resource in the project. In other words the mios32 source code is not in the file tree presented in the project column of Eclipse. I have my Eclipse projects organised with mios32 included in the project (comes from Jonathan Farmers original WIKI) and it works well, with being able to reference the mios32 code very easily.I don't know if this has anything to do with (2) above, I must have somehow had an old version of mios32_dout.h being there (one without the reverse array declaration). I wonder whether the declaration has always been in the file. I definitely did do an svn update.

Putting aside issues to do with setting the environment from windows batch files (ugh....I'll look in to that one in due course), I ve managed to compile and flash the firmware with 4 USB midi ports! (yay) Having a 4x4x4 router (in the SEQ) in my rig really rationalises the midi wiring but particularly it gives Sysex editing and librarian connectivity to everything! I'll definitely be adding opto/connectors for MIDI IN/OUT 3 and 4 on my SEQv4L! The Korg driver seems fine so far... Woohoo!

I've just discovered that setting the environment variables in a batch file is not working as I expected...

Ok, now on another machine I have updated the mios working copy from the repo. -go into directory C:\MIOS32prj\mios32\trunk\apps\sequencers\midibox_seq_v4_lite -open a command window, run a batch file with the following contents: set PATH= c:\mios32_toolchain\bin;C:\msys\1.0\bin;%PATH%; set MIOS32_PATH=/C/MIOS32prj/mios32/trunk set MIOS32_BIN_PATH=/C/MIOS32prj/mios32/trunk/bin set MIOS32_GCC_PREFIX=arm-none-eabi set MIOS32_FAMILY=LPC17xx set MIOS32_PROCESSOR=LPC1769 set MIOS32_BOARD=MBHP_CORE_LPC17 set MIOS32_LCD=universal -type make "make: *** /C/MIOS32prj/mios32/trunk/modules/app_lcd/universal: Invalid request code. Stop." -now if I experimentally comment out the line include $(MIOS32_PATH)/modules/app_lcd/$(LCD)/app_lcd.mk a whole bunch of compilation takes place ending with "Creating object file for mios32_lcd.c....[snip]...../mios32/common/mios32_lcd.c:26:fatal error:app_lcd.h No such file or directory compilation terminated. make: *** [project_buid//CCMIOS32prj/mios32/trunk/mios32/common/mios32_lcd/o] Error 1" A simple fix?

I can compile fine for STM32 but my SEQV4L is LPC17 based so this is my target of compilation. I did SVN update the repo prior to compiling. Can you confirm that mios32_dout.h does declare the reverse array? It needs to because some file cheapo_blm.c ( or whatever it is called) accesses this array. That was the only error (easily fixed) I had to compile correctly for STM32. So all I did after this was change the processor to LPC17 and now the linker error.

I've imported the eclipse project for midibox_seq_v4_lite. For the record, the only change made to the project settings: MIOS32PATH The only change to source files necessary to successfully compile with STM32 was to add extern const u8 mios32_dout_reverse_tab[]; missing from mios32_dout.h Compiled successfully (not tested). Now, with the further changes to the project settings:MIOS32_BOARD (to MBHP_CORE_LPC17, presumably to override the USER:PREFS setting of STM32 core that I have used before now)MIOS32_FAMILY (to LPC17xx " " ditto)MIOS32_PROCESSOR (to LPC1769 " " " ditto) [snip] Creating object file for freertos_heap.cpp c:/mios32_toolchain/bin/../lib/gcc/arm-none-eabi/4.5.1/../../../../arm-none-eabi/bin/ld.exe: project_build/project.elf section `.bss' will not fit in region `RAM' c:/mios32_toolchain/bin/../lib/gcc/arm-none-eabi/4.5.1/../../../../arm-none-eabi/bin/ld.exe: region `RAM' overflowed by 11688 bytes collect2: ld returned 1 exit status make: *** [project_build/project.elf] Error 1 **** Build Finished **** I'm not sure what to do(???)