Close

Rethinking viability

A project log for Arduino Blocks for MIDI Controllers

A series of typical MIDI-event-oriented *duino shields, accompanied by graphical programming blocks that are MIDI specific.

uri.shaniuri.shani 04/10/2018 at 18:460 Comments

I ordered the demo boards today from ELECROW. I went through finalizing the panel and making sure all my design rules were correct and there were no stray ground plane artifacts. While I already had the cost estimates, I re-thought the value of the modularity of having shields which connect to pots, buttons, etc.. It makes building a MIDI controller quite expensive if one needs to have an Arduino, a MIDI / mocoLUFA shield, and an additional shield for analog MUX or a digital matrix, plus pots or buttons or what have you. And you still need to have cables to connect peripherals to the shield. So I think I'll do some re-evaluation of cost, starting with available cables and smt cable connectors to match. I also think that the next iteration of the shields should have a single board for both SPI and I2C, but in a different configuration. Currently, the SPI / I2C selection (based on pin compatibility of MCP23S08 and MCP23008 port expanders) is designed to be done through manual jumper selection, and the port expander can be replaced, as it's spec'd as 18-DIP in a socket. A much lower cost alternative will be to have to have the port expanders as smd parts, selectable only in manufacturing, and having two solder stencils - one for SPI, and the other to bridge connectors and get I2C. A third, kind of compromise, option will be to have the port expanders placed in a smt DIP socket, and the jumpers either as smt DIP switches. Further still, having the port expander in a smt socket while having the SPI / I2C jumper selectors as pads on the board can further reduce cost, while still allowing future flexibility. This is  maybe more fitting to the goal of having this system address novice users, since I think most such users will not want to decide whether to go with this protocol or the other, just something that works. Having the chip in a socket and having pads as jumpers still means future compatibility for users who outgrow the use of stock option. I'm currently leaning towards SPI as the main protocol as it's a lot faster, but waiting on the boards to test the usefulness. I'll probably have to design some breakout boards for pots and a button matrix to test the first boards anyway.

Discussions