ilmenator

I assumed that mios32_config.h has to be located in the same folder as the makefile, so I had added a new one there - well, now I discovered it in mios32 and it works - only that the offset is actually the full eight SRs that are "virtual", not the difference between virtual and real SRs. So I need to subtract 64 instead of 48. Thanks!

Well here is another idea how I thought this could be handled. In seq_led.c, LEDs are set according to SR/pin numbers as defined in the config file. The routines there differentiate between direct LEDs and those arranged in Wilba's 8x8 matrix. How about extending this in order to accomodate more SRs? E.g. ///////////////////////////////////////////////////////////////////////////// // Sets a LED, differs between LEDs directly connected to DOUT pins // (pin = 0..127) and LEDS which are connected to a 8x8 matrix (pin = 128..195) // (pin = 196...203) are connected to DOUT pins again ///////////////////////////////////////////////////////////////////////////// s32 SEQ_LED_PinSet(u32 pin, u32 value) { #ifdef MBSEQV4L if( pin < 64 ) return BLM_CHEAPO_DOUT_PinSet(pin, value); if( pin >= 128 && pin < 196 ) return BLM_X_LEDSet(pin-128, 0, value); #else if( pin < 128 ) return MIOS32_DOUT_PinSet(pin, value); if( pin < 196 ) return BLM_X_LEDSet(pin-128, 0, value); if( pin < 204 ) return MIOS32_DOUT_PinSet(pin-48, value); #endif return -1; // pin not available } My reasoning is that the 8 virtual SRs of pins 128...195 of Wilba's 8x8 matrix are connected to 2 real SRs in the chain. Hence, the subsequent real pins 196...204 must be shifted down the chain by 6 SRs (or 48 pins). I also modified SEQ_LED_SRSet and SEQ_LED_SRGet accordingly, however, it doesn't work that way. Now I wonder where my logic fails me? Thanks, ilmenator

I'll send you a board once I have rev. 1.06 in my hands so you'll see how much fun this is. I'm sure we'll find a solution :yes:

In order to make use of the 4 additional duo-color LEDs on my TPD module I need to activate one additional DOUT SR in the MB SEQv4. Why? The current MB SEQv4 firmware allows for a total of 24 SRs only. Of those, the first 16 are considered "direct" connections to LEDs, whereas the last 8 are forwarded to a LED matrix via the BLM_X module. With the TPD and a traditional BLM connected to Wilba's MBSEQ PCB, I need direct acces to 17 DOUT SRs, as there are 9 DOUT SRs on the TPD module. Electrically speaking, this should not be a problem, because in reality I have only connected 17 DOUT SRs - the matrixed ones are purely "virtual" in my case. However, I cannot only append another DOUT SR - the BLM_X-routines get in the way. Also, I was not successful in simply shifting the boundaries for direct- vs. matrix-handling in seq_led.c (and setting SEQ_LED_NUM_SR to 25 in seq_led.h), such that the first matrix-SR would be SR 18 / pin 137. Yes, I added mios32_config.h containing the line #define MIOS32_SRIO_NUM_SR 25 to the folder. Before I continue with this, I think it might be a good idea to ask for advice on how TK would like to handle this within the general framework of MBSEQv4. I got quite some feedback with respect to the TPD module and I could imagine a few more usecases which make the LED matrix display attractive. Thanks, ilmenator

Hi /t/, seems like you have not been on the forum for very long! Yes, you can sell your MIDIbox (or your family can), no problem. It seems like max. 10 per year is some kind of magical number that makes you fly below the radar. Of course, it makes sense to sell them here in the forum as you will probably reach an interested crowd more easily, but elsewhere is also okay. As MIDIbox is a non-profit endeavour it is always recommended to sell MIDIboxes for roughly the cost of parts. Hope you stay around some longer!

Much respect!

Great! Actually, I find that hard to read and therefore rather impractical. I'd prefer a more readable font any time!

All my protoboards are gone, sorry. If I was located in a place where shipping costs are reasonable then I'd probably do another run. However, boards that size are expensive to ship from here, and if you wanted tracking it's even worse. If you stay within single-digit quantities you will probably not find a better offer than what I pointed you towards.

Do the search, Luke!

Well then simply add a 74HC04 8bit inverter, one for each DOUT block of eight. The same could be done with the DINs.

For the buttons you could modify the standard hook to only check for releases and skip the button presses. Instead of this void APP_DIN_NotifyToggle(u32 pin, u32 pin_value) { // only check for button presses and skip releases if (pin_value == 0x01) return; switch (pin) { .... you would then write something like void APP_DIN_NotifyToggle(u32 pin, u32 pin_value) { // only check for releases and skip button presses if (pin_value == 0x00) return; switch (pin) { .... The same could probably be done for the LEDs, just set the DOUT state to be 1 for all outputs, e.g. during the init phase, and then switch to 0 individually if needed.

You could order at Gold Phoenix PCB - the size of the design is just below their maximum allowable single board size for their "specialprice" prototype order. The 155 sq inch panel gives you three boards - sometimes they will actually make it four, but they don't promise that so don't expect it.

Well, if you move the parts closer together you will need less total area :rolleyes: .

Thanks! Pro tip: the outline needs to be cut only once, as the parts interlock. So, if you move those parts that share the same outline and remove one of the cut traces (this is explained in the Formulor turorial) then you will save a few more Euros on manufacturing costs. For your file this would be top, front and bottom. Also, it makes sense then to move the back part down below the top/front/bottom "block", and move the sides to the right so that they interlock with the top and bottom parts. Also, you could add some mounting holes for the LPC17 core board to the bottom. And you probably want to move it a bit more into the center, not sure if it will otherwise collide with the standoffs for the UI board. Best, ilmenator

Glückwunsch, sieht gut aus!

This doesn't seem to be EPS v8 file format, I cannot open it in AI CS2!? Is it the exact same file uploaded and accepted by Formulor?

Thanks for sharing this!

At least this is what the data sheet suggests, and my displays have the same pinout. One of your pictures (the Eagle PCB screenshot) looks as if you used a component that represents an LCD - at least it seems to print some silkscreen on to the PCB. That might be the cause for your confusion. I would suggest to use a simple Wannenstecker compontent, which you can then place on the top or bottom layer without being overly confused by the silkscreen. After having the PCB fabricated, mounting it either on top or on the bottom will then give you the correct pinout.

The newer version is good.

Super Entwurf! Dann zeig doch mal das fertige Ergebnis --> POIDH :whistle:

Yes, that just shows that you got the cable / Wannenstecker on the LPC17 right, in spite of the misleading "1" marking. I was suspecting that there must be some other cause for you mixing up the cabling, and this confirms it, because on the LPC17 board you got it right... :smile: My guess is that the problem is somehow related to the LCD component that you used in Eagle - I assume that this is what you used, it's a little hard to see because the second image in your first post is cropped.

Yes, that is the case, but it's only the little "1" that is wrong - if the notch of the "Wannenstecker" is pointing towards you, then pin 1 is on the left close to you. However, you could align the "1" marked on the board only properly to your cable's "1" if you had mounted it from below... which you probably haven't done anyways, right? So that marking alone can hardly be the sole cause for this :-/.

That's a relatively simple error: when you designed the board, one of the connectors was supposed to be on a different layer than it ended up when you soldered it - either top or bottom. It's not clear to me from the images you provide, but maybe the LCD "component" that you apparently use expects the connector to be mounted on top, whereas you have it soldered to its bottom.

Well thanks for the link - actually, I had figured that out already, MIDIbox land is well documented in a way :phone: . So, what are my findings? Actually, only good news so far. Playing around with the code a bit, I can now confirm that my original board layout works with the common anode duo LED matrix, and it should also work with common cathode types. Comparing the datasheets of many of the variants I could find on the Internet, it seems like the pinout of the modules is always the same, with common anode / common cathode pins corresponding. In other words, only one board layout is required, no matter whether common anode or cathode type is used, and it is not necessary to buy the Sparkfun/Watterott variant which is not even in stock. Here is a link to a video that shows the two modules in action. The left one uses only the red color and shows tracks 1-8, the right one demonstrates that also the green color can be chosen and shows tracks 9-16. Ideally, I would like to have the dots running from top to bottom and not from the center outwards, but I guess I'll leave this to Hawkeye's implementation skills. Here is the piece of code I use for the demo video: // $Id: seq_tpd.c 1403 2012-01-08 21:50:31Z tk $ /* * Routines for relative track position matrix LED display (by hawkeye) * quick-and-dirty mod for double duo-LED matrix demo 2013-02-19 by ilmenator * * ========================================================================== * * Copyright © 2008 Thorsten Klose (tk@midibox.org) * Licensed for personal non-commercial use only. * All other rights reserved. * * ========================================================================== */ ///////////////////////////////////////////////////////////////////////////// // Include files ///////////////////////////////////////////////////////////////////////////// #include <mios32.h> #include "seq_hwcfg.h" #include "seq_core.h" #include "seq_ui.h" #include "seq_bpm.h" #include "seq_led.h" #include "seq_cc.h" ///////////////////////////////////////////////////////////////////////////// // LED update routine ///////////////////////////////////////////////////////////////////////////// s32 SEQ_TPD_LED_Update(void) { // Shift Registers are hard coded for simplicity of the demo implementation, counting from 0: // right LED matrix: // SR 10 = green // SR 11 = red // SR 12 = common anode // left LED matrix: // SR 13 = green // SR 14 = red // SR 15 = common anode static u8 cycle_ctr = 0; // Switch off "the other color" MIOS32_DOUT_SRSet(11, 0xFF); MIOS32_DOUT_SRSet(13, 0xFF); if (cycle_ctr++ > 8) cycle_ctr = 0; // Power the corresponding column cathode of this cycle MIOS32_DOUT_SRSet(12, (1 << cycle_ctr)); MIOS32_DOUT_SRSet(15, (1 << cycle_ctr)); // Determine relative track position (tracks 1-8, left LED matrix) s32 steps = SEQ_CC_Get(cycle_ctr, SEQ_CC_LENGTH); s32 curstep = 2*seq_core_trk[cycle_ctr].step; u8 relpos_left = (s32)(curstep << 2)/ steps; // Determine relative track position (tracks 9-16, right LED matrix) steps = SEQ_CC_Get(cycle_ctr + 8, SEQ_CC_LENGTH); curstep = 2*seq_core_trk[cycle_ctr + 8].step; u8 relpos_right = 7 - (s32)(curstep << 2)/ steps; // Gate the corresponding anodes of this cycle (if the tracks are not muted) u8 setbyte_left = 0xFF; u8 setbyte_right = 0xFF; if (!(seq_core_trk_muted & (1 << cycle_ctr))) setbyte_left ^= (1 << relpos_left); if (!(seq_core_trk_muted & (1 << (cycle_ctr + 8)))) setbyte_right ^= (1 << relpos_right); MIOS32_DOUT_SRSet(14, setbyte_left); MIOS32_DOUT_SRSet(10, setbyte_right); return 0; // no error } Kind regards, ilmenator

Did you have your scrambled display hooked up to the inversed voltages? That might explain a garbled screen and a dead first row...