<div dir="ltr">Yes, difference is that those specialized chips are fixed, non-flexible - but ready. Yes, with FW, but those FWs are already done and tested.<div>Overwriting entire flash is also OK, if it is specified for 10K cycles. I remembet the times when embedded program flash was rated for 100 cycles.</div>
<div><br></div><div>How about tracking the reason for this "interrupt-causes-a-problem"? </div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/10/20 luke.leighton <span dir="ltr"><<a href="mailto:luke.leighton@gmail.com" target="_blank">luke.leighton@gmail.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Sun, Oct 20, 2013 at 9:42 AM, krasi gichev <<a href="mailto:krasimirr@gmail.com">krasimirr@gmail.com</a>> wrote:<br>

> Not sure what particulat problem this could be, but I know that "BOOT0"<br>
> selects the boot mode.<br>
<br>
</div> yes.  what i've assumed is that it's ok to just completely overwrite<br>
the entire flash on each dev-cycle (no flash-based usb-based<br>
bootloader like the one used on the leaflabs maple).  as long as i<br>
don't hit a flash block write-cycle limit within the development<br>
period it'll be ok.<br>
<div class="im"><br>
> About your last statement - wasn't it clear the doing things on general-purpose<br>
> MCU means trading off development resources for freedom/flexibility?<br>
<br>
</div> in a word, yes.  but it's been an absolute sod for hardware verification.<br>
 Q ODM: we want to sign off the development of the hardware!<br>
 A: err... you can't.  there's no firmware yet.<br>
 Q: well how can we test if the board we put together is correct or not<br>
 A: err... you' can't!<br>
<br>
 so it was a bit of a risk.<br>
<div class="im"><br>
> If it was easier/cheaper that why would someone the earth make specialized<br>
> chips<br>
<br>
</div> because it's possible with those specialised chips (USB-audio IC,<br>
USB-camera IC) to just... plug them in and go.  the irony is that most<br>
USB-camera ICs have an 8051 embedded microcontroller with on-board ROM<br>
or flash, and most good Audio CODEC ICs have a Tensilica DSP with<br>
on-board ROM or flash!<br>
<br>
 so there are companies out there selling exactly the software that's<br>
required to do the job, using exactly the same kind of solution, it's<br>
just that they're entirely proprietary and ready-to-go.  but the fact<br>
that these ICs have an on-board MCU/DSP means that they're going to be<br>
the same order of magnitude of cost.<br>
<br>
 *sigh* i'd _really_ like to use the STM32F207 with DCMI but the<br>
pricing out of HK is $5.50 for 10k units: nearly 20% *higher* than the<br>
10k pricing off of digikey in EU/USA!  which is nuts.<br>
<div class="HOEnZb"><div class="h5"><br>
l.<br>
<br>
_______________________________________________<br>
arm-netbook mailing list <a href="mailto:arm-netbook@lists.phcomp.co.uk">arm-netbook@lists.phcomp.co.uk</a><br>
<a href="http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook" target="_blank">http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook</a><br>
Send large attachments to <a href="mailto:arm-netbook@files.phcomp.co.uk">arm-netbook@files.phcomp.co.uk</a><br>
</div></div></blockquote></div><br></div>