How to flash on-module firmware?

Lol. My modular is a bit smaller, but still looks like I should be “one dingy dingy, two ringy dingy” :slight_smile:

Pete

@ Pete Brown - look forward to the show and tell video when its finished :slight_smile:

Unless I can figure out how to universally decrease the font size for board legends, I think I’m done here. I added some pins on the left to break out some unused pins for debugging, or just general use. And, because I did that, I also broke out the power.

Thanks for the help on IAP, but I’m punting on that for the moment. I need to just get the basic functions working for this prototype, and want to get the board out tonight so it’ll be waiting for me shortly after I return from India :slight_smile:

Pete

That is going to be some awesome MIDI demo when this is done :slight_smile:

Thanks.

I’ve come up with this because NETMF’s strong point isn’t in data processing. Despite all my optimizations to my MIDI module, I still can’t keep tight timing on the UARTs, or deal with the 24ppqn (at 120bpm that’s 48 data packets per second just for the timing clock), or deal with the flood of messages that happen when someone hits the pitch bend on their controller. Your ear can pick out any lag over around 10-15ms, so it’s critical to keep things tight. A customer in Germany was getting lag of > 1 second when he used pitch bend or other continuous controllers. That’s just the nature of interpreted code. You can flip bits quite quickly, but assembling the data packets, forwarding THRU messages, etc. are all better done in native code. (I considered NETMF firmware extensions etc., but decided to go with logic on the module).

By going this way, I can let NETMF handle setting configuration options, dealing with only the messages it wants, and serving as the user interface.

The amusing thing is that five of those chips are necessary only because we’re working with 3v3 microcontrollers. If I felt like using a 5v PIC or AVR, I could eliminate those chips. (They’re logic gates used as level shifters). I’m trying to cut down on how many different architectures I try to learn at once, however.

Here’s my development board (and C compiler), BTW :slight_smile:

MIDI, DIN Sync, and most analog gate/clock signals are all 0 to +5v coming and going.

Also, the isolator I’m using is brand new and untested in this scenario (the more widely spaced package on the left). If it works, it’s nice because it replaces 6n137/6n138 opto isolators that come in giant 0.1" pin pitch only.

Processor is STM32F205RBT6. Plenty of horsepower to manage synching all those ports in native code.

UART may not be the correct interface for this long-term. I may need to go SPI or DaisyLink, or something else. Most main boards seem to have more UART support than SPI support, though.

Pete

Oh, and after fighting EAGLE’s ridiculous user interface for a while, and faced with the prospect of paying a crapload of money to produce larger boards, I’ve standardized on DipTrace. With very few exceptions, it works exactly like I do.

The board here is a hair under 5cm x 10cm and just under 300 pins. I’m using DipTrace standard, but you can see it would work in DipTrace Lite with room to spare. Oh, and no obnoxious EAGLE prompts about being outside the design area. DipTrace goes by pin count – the boards can be as large as you want.

I’ve been using DF Robot for PCB manufacturing. They did my NES controller Gadgeteer board previously, and I was very happy with quality, time, and price. They’ve since added an option to let you have arrays of boards which fit in their dimensions. For example, they don’t have a 5cm x 10cm option, so I need to use 10cm x 10cm. However, with this option, I can tell them to place two boards in that footprint. It’s not panelization, but for a hobby service, that’s really great.

http://www.dfrobot.com/index.php?route=product/category&path=135_134

Pete

@ Pete Brown - i asked about panelising, so they added it, great service and i got free boards for the suggestion :slight_smile:

I forgot to mention - after discussions with Lauren ad DFRobot about a few issues…

  1. Manufacture codes - add an image like the attached so they hide manufacture codes under the Gadgeteer socket or IC’s etc
  2. Corner holes - add a circle on tKeepOut to stop the corner holes being plated

Great info on the code. Previously, I had a “place codes here” marker in the silkscreen and mentioned in email, but they ignored it. This approach is better.

Corner holes: whatever I did last time seems to have worked. I’ll check.

Pete

BTW, what’s that board? Looks like it holds two motor drivers or something.

@ Pete Brown - 4 digit seven seg via spi

Can see them here http://www.tinyclr.com/forum/topic?id=11176