[Arm-netbook] stress! and working with libopencm3, stm32sprog and an STM32F103

[luke.leighton]

On Sun, Oct 20, 2013 at 9:42 AM, krasi gichev <krasimirr at gmail.com> wrote:
> Not sure what particulat problem this could be, but I know that "BOOT0"
> selects the boot mode.

 yes.  what i've assumed is that it's ok to just completely overwrite
the entire flash on each dev-cycle (no flash-based usb-based
bootloader like the one used on the leaflabs maple).  as long as i
don't hit a flash block write-cycle limit within the development
period it'll be ok.

> About your last statement - wasn't it clear the doing things on general-purpose
> MCU means trading off development resources for freedom/flexibility?

 in a word, yes.  but it's been an absolute sod for hardware verification.
 Q ODM: we want to sign off the development of the hardware!
 A: err... you can't.  there's no firmware yet.
 Q: well how can we test if the board we put together is correct or not
 A: err... you' can't!

 so it was a bit of a risk.

> If it was easier/cheaper that why would someone the earth make specialized
> chips

 because it's possible with those specialised chips (USB-audio IC,
USB-camera IC) to just... plug them in and go.  the irony is that most
USB-camera ICs have an 8051 embedded microcontroller with on-board ROM
or flash, and most good Audio CODEC ICs have a Tensilica DSP with
on-board ROM or flash!

 so there are companies out there selling exactly the software that's
required to do the job, using exactly the same kind of solution, it's
just that they're entirely proprietary and ready-to-go.  but the fact
that these ICs have an on-board MCU/DSP means that they're going to be
the same order of magnitude of cost.

 *sigh* i'd _really_ like to use the STM32F207 with DCMI but the
pricing out of HK is $5.50 for 10k units: nearly 20% *higher* than the
10k pricing off of digikey in EU/USA!  which is nuts.

l.