MCU boards

Oh, so close. M32C goes up to 32 MHz. If you can live with that...

It has a three-phase motor unit (six PWM) plus five other independent PWM, 34 ADC @10 bit, 7 UART (5 can do SPI, 5 can do I2C, one does IrDA, etc). Programming involves setting one jumper, reset, then TTL-level serial (it has a built-in monitor program). Remove jumper, reset, it's running.

Tools are all free - gcc et al - and support C, C++, Asm, and probably FORTRAN and Objective C. You could probably get Pascal and/or Eclipse working if you wanted to ;-) You can buy support if you need it.

It could be hard, but I'll give it a try :)

Uh, the board will be installed in a "remote" place. It will be very difficult to set and remove the jumper for firmware upgrading. I hope it supports a bootloader to avoid this.

Great! ehm... are we talking about M32C by Renesas, aren't we? :)

Thanks a lot

Bye Marco / iw2nzm

If you have control over DTR and other signals, you can use those to control reset and mode, the two signals. I have a board that uses a FTD232R for that purpose:

I suppose it's possible to use *just* DTR, if you put a one-shot on it

- fast pulse for reset-to-run, slow pulse for reset-to-program. Linux at least drops DTR when you set the speed to 0 baud, which is handy. No special software needed.

All programming is done with TTL logic levels. Another alternative is to add an R8C next to it, pre-programmed with the monitor, and feed serial to *that*. Give it the ability to fiddle the programming pins on the M32C. Then you just need Rx and Tx :-) The R8C can also act as a watchdog.

The M32C family *can* reprogram its own flash from within its own user program, too - if you copy the relevent opcodes to ram first (set it all up, jump to ram to program the flash block, return to flash for the next chunk). The flash is broken into multiple erasable blocks for this purpose. The starterkits came with such a monitor pre-installed, but it was geared towards their debugger, so isn't suitable for live systems (i.e. it won't run the program until the debugger says to).

Or you could do it with just a DTR reset, if your startup code looks for serial data within N mS of a reset. Or interrupt-driven serial. Lots of options.

Yes.

Or beam it over with wireless. But Marco doesn't want RF right now. Bet that could change after the umpteenth "It doesn't work" complaint. Automotive is quite unforgiving when it comes to connector dirt, corrosion, critters munching on cables etc.

Yeah, I know what you're talking about. I also know RF couldn't work in this case, either. The board is placed several hundreds feet underwaters... During development and the first period of use we need to reprogram it without the "surface-dry-unscrew-open-setjumper-program-removejumper-close-screw-dive" dance every time I want to change a bit the code :)

Bye! Marco / iw2nzm

I'm happy to hear this.

Thanks once again Marco / iw2nzm

Hmm, automotive ... under water? Doesn't sound too healthy for the driver ;-)

You might want to consider inductive coupling. Would reduce the above process to "Surface-dive". Or maybe ultrasound where you could even leave the whole chebang down there and just lower the transducer close enough to the target.