<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div>I briefly forgot how easily "OT" is fixed, mea culpa.<br/>
<br/>
(sorry for quoting the original message below all - the web based editor of my mail provider sucks...)<br/>
<br/>
"amount of other people's code in your product" (in 32 bit MCU firmware):<br/>
<br/>
I don't necessarily discern (in my worries about 3rd party work) between silicon designed by other people and lowest level firmware support libraries done by others, especially if done by the silicon designers themselves (roughly speaking).<br/>
It's not as bad on the littler ones like I linked to earlier, with Cortex M0 core.<br/>
Yeah, most likely you'd end up using ARM's CMSIS at least, which is tested quite well and thought through I suspect.<br/>
Unlike the e.g. ST library stuff (esp. the "thought through" part).<br/>
Which isn't "necessary" to get a M0 running and output some noise.<br/>
<br/>
Where it gets increasingly unwise to not use the configurator tool, at least for checking the clock tree for "legal" settings etc, is something like the stm32L4. (And to get the proper ADC sampling rate, selecting the "best" crystal, and in-between clock settings also good for other stuff, I had to write a script that computes possible combinations and filter it to needed specs - so many screws to adjust that it seemed impossible to do it in a minute on paper just by staring at it)<br/>
<br/>
Now you mentioned learning curve. I suspect that an increasing number of  youngsters will not come in contact with a PIC or so anymore.<br/>
Vendors today a throwing out cheap dev kits with built-in debuggers and a lot of interesting peripherals, "can do more" is tempting, even Arduinos moved beyond 8bit, IIRC.<br/>
Using an old school 8 bitter will be an extra learning curve then for those.<br/>
For someone who knows those in his sleep, it may make sense to use.<br/>
I never developed for an 8 bit micro (unless you count Commodore 64 :D Which wasn't so micro, considering the peripherals were spread out in a bread box), and unless there arises a very good reason, I won't bother anymore in this parallel universe.<br/>
To me, they look to be on the way out.<br/>
<br/>
(yes, I am also playing with analog synth chips and such, and even vacuum tubes, out of a special fondness - that doesn't mean I want to use obsolete stuff for every aspect of what I do ;))<br/>
 
<div> 
<div name="quote" style="margin:10px 5px 5px 10px; padding: 10px 0 10px 10px; border-left:2px solid #C3D9E5; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">
<div style="margin:0 0 10px 0;"><b>Von:</b> "MTG" <grant@musictechnologiesgroup.com><br/>
<br/>
Way OT now, but I think one of the concerns with a 32-bit micro is the<br/>
learning curve and sheer amount of Other People's code in the final<br/>
product. Even on an 8-bitter, assuming C, you have startup code,<br/>
potentially libraries written by Other People (standard libs and<br/>
peripheral config, even such things as getting the osc going). I for one<br/>
don't get the warm fuzzies when 90% of the code in a given micro I've<br/>
not written or at least observed enough to know it's correct. On a<br/>
32-bit vs 8, the amount of Other People's code increases dramatically.<br/>
I'm guessing there's an equation for it. :)<br/>
<br/>
GB<br/>
<br/>
On 11/12/2019 9:18 AM, Steve wrote:<br/>
> 32 vs. 8 bit micro:<br/>
> Now go spank me with details - a hobbyist with chaotic observation<br/>
> fragments forming ideas and more opininons than he probably should have :P<br/>
_______________________________________________<br/>
Synth-diy mailing list<br/>
Synth-diy@synth-diy.org<br/>
<a href="http://synth-diy.org/mailman/listinfo/synth-diy" target="_blank">http://synth-diy.org/mailman/listinfo/synth-diy</a></div>
</div>
</div>
</div></div></body></html>