latigid on

POIDH!

Hi Matthias, What's the version number printed on the Discovery board? Did you try removing the solder bridges as detailed in the post above? Best,

Hi Zam, Okay, is the D variant working whilst plugged into a computer or standalone? Best,

For interest, can you post the version number silkscreened above the ST logo (topside)? MB997C seems to behave okay, while it looks like MB997D has problems with the bootloader if a USB host isn't present.

Seems like there is a problem (when a USB host isn't connected to the Discovery board??) Try to unbridge those connections and see if it helps. Also it would help if you listed your version number.

I have an STM32F4 board (about a year old from Mouser) with MB997C above the ST logo on the topside. My newer Disco boards (a few weeks old from RS) have MB997D. I haven't needed to test these yet, but I found a thread that may be of help: https://my.st.com/public/STe2ecommunities/mcu/Lists/STM32Discovery/DispForm.aspx?ID=15970&RootFolder=%2Fpublic%2FSTe2ecommunities%2Fmcu%2FLists%2FSTM32Discovery%2FSTM32F407G-Discovery-STlinkV2(V2.J25.M13)%20%20-%20Boot%20fail%20using%20external%20power%20supply Hope that can be of help.

I don't think so, but from memory it uses a PIC. I don't have personal experience with scanning pots into MIOS, apart from the BLM 16*16+X. AINSER(X) is the external ADC solution to expand the AIN capabilities but I don't know about the performance (try searching the forum). PICs in general have better handling of analogue inputs; this is why they are used as part of the MF_NG module. Then again, Mutable Instruments uses a single ADC pin and four multiplexer chips to scan 28 pots in Elements. I know from using the module that some parameters are definitely lower resolution, e.g. the tuning controls are quantised.

Only you can decide that. My perspective on pots is that they make less sense on architectures with presets, like a universal controller. Of course you have relative/snap/absolute handling modes, but they don't beat the simplicity of an incremental encoder. Pots (also encoders) are subject to wear and dust and are inherently more difficult to scan. This difficulty increases with the number of inputs (slower scan rate etc.), although I'm sure TK. has routines for minimising jitter errors. If you're sending CC data rather than NRPN (well first we have to look at the effective resolution of the ADC), it's all quantised anyway. Pots also make little sense with lower resolution parameters. A prime example is the Rhodes Chroma ENABLER. Almost $4000 to have one built (a lot of wiring and parts) and some parameters have as few as 4 values. But it demonstrates that it can be done with pots if you choose. Finally the likelihood of a project being completed is inversely proportional to its size and complexity. Pimping the ELO (Programma) boards, this breaks the task down into smaller chunks.

Fair enough. Out of interest, how many pots are you looking to implement?

I think it would be possible to do a 4*20 display on a single OLED. Understand that the traditional SCS layout (visible in the MB CV control surface above) typically puts 4 buttons below the LCD to select menu items. You're describing the Programma. 1-4 ELO boards with sets of 16 illuminated encoders and 4 "labelling" OLEDs, auxiliary SCS-OLED boards for patch name, envelope shapes, SCS button labelling etc.

No worries, PCBs should be here today if DHL get their act together. I have white 0.96" OLEDs on the way, could possibly try with a yellow-blue I have left. The thing is, you don't have an ordinary button layout, so maybe traditional SCS LCD functions don't make sense anyway. But as far as the display goes, a 2*20 CLCD is 100 pixels across with a gap of ~1 pixel in between characters. So the horizontal resolution is comparable. I chose the 6 button "hex" layout just to try something different. My thought was that there's enough space to provide two menu rows of 3 items each. Have to see though, my guess is @Hawkeye will do most of the hard work with the Programma builds ;-). This gives an idea of how the text fits, approximately 20 characters:

Not yet.

Here's an updated picture: You can see 7 pin SIL rows for the displays and the six switches/encoder (two positions possible). Encoders with built-in switches are supported but you have to wire your own pins. Possible configs are: OLED OLED OLED OLED OLED [6 buttons] OLED OLED OLED encoder OLED [6 buttons] encoder only switches only encoder combo of switches + encoder fewer OLEDs Pinning for the OLEDs is based off J15A from the Core32F4, same for the display driver. Pinning for the SCS is the standard J10(A). It would be possible to split the SCS functions across two boards, e.g. with OLED [buttons] OLED on one and OLED OLED encoder on the other.

Some cool grooves in there! Aphex Twin fan? What's the synth/sampler setup?

Do you know if it's possible to have say 4x 128x64 OLEDs and 1x 256x64 OLED all with the same controller chips on it in a MBNG system without customizing the code? I don't know for certain, but at a naive guess I think you would need to program the displays with the maximum pixels in mind. So in your suggested setup you have five 256*64p displays, where the first four are only used at 50%.

You and me both, PCB protos expected next week. You can't mix different display drivers on the same signal chain without significant re-coding. MBCV uses two separate ports and is noted as an exception. If you wished to have this coded into MBNG you'd likely have to do it yourself.

The 0.96" displays are really nice (hi-res thus sharp pixels) and really cheap. Most also have a carrier board meaning you could mount them easily. The one you found needs an FFC or 0.5mm pitch soldering, so go for the mounted option if you choose this route. I don't think that mixing display controllers is possible without special coding (works for example on MBCV). As far as chaining multiple displays, I know @Hawkeye implemented this for the Programma v0.1 My SCS-OLED boards will have a similar arrangement of rows of 4 OLEDs, which can be omitted in place of switches/an encoder.

We're all coming from different backgrounds, with different time commitments and so on. The number one priority is that the board should work, and that's the responsibility of the designer. Many other choices come down to personal preference or experience, which is totally cool seeing as we aren't under contract to provide a specific service. E.g. I will always put decoupling caps near the power pins, and if you don't believe in them (:-P) it's your choice not to populate those components. The direction towards a casing standard is quite smart, because that's often the limiting factor in builds and can contribute majorly to the cost. @Rowan actually suggested that as a direction a little while ago, and it's very doable simply by limiting the PCB height to ~100mm. I don't agree that panel sizes should be equal to a power of two, though there is a loose idea to keep the HP values as even numbers. It's very rational to use SMT, not just because of size and certain availability, but it allows for easier trace routing, double sided placement, closer clearance (look at the registers placed under the dot matrices above), less drill hits etc. And you'll actually find that it's easier than through hole assembly as you don't have to clip leads. Can be much cheaper for components too. Avoid SMT on parts that experience mechanical stress like pots, switches, sockets etc. Personally I stick to through hole design when I can. Sorry for the off-topic discussion, feel free to split if needed.

The EAGLE library part has pin 1 on the right as referenced to the schematic: I can't say how this would relate to KiCAD, but it would be great to standardise the power connector on the right relative to the polarity tab on the bottom edge.

All good, here is the part: http://www.mouser.de/ProductDetail/Molex/22-23-2031/ Also available for next to nothing at Tayda: http://www.taydaelectronics.com/connectors-sockets/wafer-housing-crimp-terminal/serie-2500-2-54mm.html Pin 3 NC Pin 2 0V/ground Pin 1 +5V Lots of edits today: it's of course possible to use an ordinary 100mil breakaway header in place of the Molex part. Best, Andy

If the current consumption is "high" then it makes sense to wire the power lines in parallel EDIT: I should say "star wired." This sends the return current back to the source rather than influencing other modules in the chain. I only asked because I was wondering about the 2-pin connector at the top on the rear side. Flexibility, even if it's "over designed," can extend the device beyond its original purpose.

I don't agree; I've read about cases where decoupling caps were the difference between a chain of serial shift registers working or not. A fly-wired cap would be just as effective as your current layout -- the closer to the power pins the better.