Fast simple microcontroller

On 7/3/2021 11:56 AM, John Walliker wrote:
> On Saturday, 3 July 2021 at 18:39:14 UTC+1, Don Y wrote:
> 
>> The days of (hand-)counting clock cycles to determine the execution
>> time of a code fragment are long past.
>>
>> There's a reason data sheets are now hundreds of pages!
> 
> True enough.  However, there are other options with some of the ARMs
> such as co-processors in some of the TI and other devices.  The
> RP2040 has a programmable state machine which looks very deterministic
> and of course the Xcore devices which have been mentioned here
> provide another approach to deterministic systems.
> 
> For low-speed applications, the AT-tiny 13 or 2313 are still nice.

Of course.  My point was that processors are no longer simple,
intuitively predictable devices.  Anyone who is thinking along
those lines will be perplexed to discover that the rules have
changed!

Years ago, one could determine performance largely intuitively
by simply thinking about the number of bus cycles required in
a particular opcode execution and multiplying by the number
of clock cycles per bus cycle, adding fudge, as appropriate.

Now, there are invisible costs in moving data around "inside"
the SoC (e.g., TO floating point registers vs. FROM, etc.).
It's almost impossible to keep all of this sorted out in
your head -- unless you tie your efforts to a single
processor variant over multiple projects.

[Neglecting the costs/economies of caches, TLB misses, etc.]

One of the advantages of having an OS under you is that many of
these issues can be addressed there, largely freeing the
developer from worrying about them.

Of course, that assumes what your doing can be abstracted away
from the hardware; that an appropriate "driver" can be put in
place to handle those abstractions!

On 03/07/21 20:40, Don Y wrote:
> On 7/3/2021 11:56 AM, John Walliker wrote:
>> On Saturday, 3 July 2021 at 18:39:14 UTC+1, Don Y wrote:
>>
>>> The days of (hand-)counting clock cycles to determine the execution
>>> time of a code fragment are long past.
>>>
>>> There's a reason data sheets are now hundreds of pages!
>>
>> True enough.  However, there are other options with some of the ARMs
>> such as co-processors in some of the TI and other devices.  The
>> RP2040 has a programmable state machine which looks very deterministic
>> and of course the Xcore devices which have been mentioned here
>> provide another approach to deterministic systems.
>>
>> For low-speed applications, the AT-tiny 13 or 2313 are still nice.
> 
> Of course.  My point was that processors are no longer simple,
> intuitively predictable devices.  Anyone who is thinking along
> those lines will be perplexed to discover that the rules have
> changed!

The xCORE devices had zero surprises for me; I was gobsmacked :)

I was cutting real multiprocessor and i/o code within a day
of starting to use them


> Years ago, one could determine performance largely intuitively
> by simply thinking about the number of bus cycles required in
> a particular opcode execution and multiplying by the number
> of clock cycles per bus cycle, adding fudge, as appropriate.

You still can, for the 32-core 4000MIPS xCORE processors.

In fact the IDE will tell you the exact max timings from
here to there in you, for /all/ of the code paths in between.

Plus you can trivially specify that output occurs on a
particular cycle, and record the cycle on which input
occurred.


> Now, there are invisible costs in moving data around "inside"
> the SoC (e.g., TO floating point registers vs. FROM, etc.).
> It's almost impossible to keep all of this sorted out in
> your head -- unless you tie your efforts to a single
> processor variant over multiple projects.

Let the IDE do it for you.


> One of the advantages of having an OS under you is that many of
> these issues can be addressed there, largely freeing the
> developer from worrying about them.

For the xCORE devices, the RTOS is implemented in hardware,
from I/O up to inter-core message passing.

The I/O is /delightfully/ simple, from SERDES up to
the high level algorithm.


> Of course, that assumes what your doing can be abstracted away
> from the hardware; that an appropriate "driver" can be put in
> place to handle those abstractions!

Yuck :)

On 7/3/2021 12:55 PM, Tom Gardner wrote:
> On 03/07/21 20:40, Don Y wrote:
>> On 7/3/2021 11:56 AM, John Walliker wrote:
>>> On Saturday, 3 July 2021 at 18:39:14 UTC+1, Don Y wrote:
>>>
>>>> The days of (hand-)counting clock cycles to determine the execution
>>>> time of a code fragment are long past.
>>>>
>>>> There's a reason data sheets are now hundreds of pages!
>>>
>>> True enough.  However, there are other options with some of the ARMs
>>> such as co-processors in some of the TI and other devices.  The
>>> RP2040 has a programmable state machine which looks very deterministic
>>> and of course the Xcore devices which have been mentioned here
>>> provide another approach to deterministic systems.
>>>
>>> For low-speed applications, the AT-tiny 13 or 2313 are still nice.
>>
>> Of course.  My point was that processors are no longer simple,
>> intuitively predictable devices.  Anyone who is thinking along
>> those lines will be perplexed to discover that the rules have
>> changed!
> 
> The xCORE devices had zero surprises for me; I was gobsmacked :)
> 
> I was cutting real multiprocessor and i/o code within a day
> of starting to use them
> 
> 
>> Years ago, one could determine performance largely intuitively
>> by simply thinking about the number of bus cycles required in
>> a particular opcode execution and multiplying by the number
>> of clock cycles per bus cycle, adding fudge, as appropriate.
> 
> You still can, for the 32-core 4000MIPS xCORE processors.
> 
> In fact the IDE will tell you the exact max timings from
> here to there in you, for /all/ of the code paths in between.
> 
> Plus you can trivially specify that output occurs on a
> particular cycle, and record the cycle on which input
> occurred.
> 
> 
>> Now, there are invisible costs in moving data around "inside"
>> the SoC (e.g., TO floating point registers vs. FROM, etc.).
>> It's almost impossible to keep all of this sorted out in
>> your head -- unless you tie your efforts to a single
>> processor variant over multiple projects.
> 
> Let the IDE do it for you.
> 
> 
>> One of the advantages of having an OS under you is that many of
>> these issues can be addressed there, largely freeing the
>> developer from worrying about them.
> 
> For the xCORE devices, the RTOS is implemented in hardware,
> from I/O up to inter-core message passing.
> 
> The I/O is /delightfully/ simple, from SERDES up to
> the high level algorithm.
> 
> 
>> Of course, that assumes what your doing can be abstracted away
>> from the hardware; that an appropriate "driver" can be put in
>> place to handle those abstractions!
> 
> Yuck :)

And these are available in the "under $5" price range?  :>

On Saturday, July 3, 2021 at 12:55:28 PM UTC-7, Tom Gardner wrote:
> On 03/07/21 20:40, Don Y wrote: 
> > On 7/3/2021 11:56 AM, John Walliker wrote: 
> >> On Saturday, 3 July 2021 at 18:39:14 UTC+1, Don Y wrote: 
> >> 
> >>> The days of (hand-)counting clock cycles to determine the execution 
> >>> time of a code fragment are long past. 
> >>> 
> >>> There's a reason data sheets are now hundreds of pages! 
> >> 
> >> True enough. However, there are other options with some of the ARMs 
> >> such as co-processors in some of the TI and other devices. The 
> >> RP2040 has a programmable state machine which looks very deterministic 
> >> and of course the Xcore devices which have been mentioned here 
> >> provide another approach to deterministic systems. 
> >> 
> >> For low-speed applications, the AT-tiny 13 or 2313 are still nice. 
> > 
> > Of course. My point was that processors are no longer simple, 
> > intuitively predictable devices. Anyone who is thinking along 
> > those lines will be perplexed to discover that the rules have 
> > changed!
> The xCORE devices had zero surprises for me; I was gobsmacked :) 
> 
> I was cutting real multiprocessor and i/o code within a day 
> of starting to use them
> > Years ago, one could determine performance largely intuitively 
> > by simply thinking about the number of bus cycles required in 
> > a particular opcode execution and multiplying by the number 
> > of clock cycles per bus cycle, adding fudge, as appropriate.
> You still can, for the 32-core 4000MIPS xCORE processors. 
> 
> In fact the IDE will tell you the exact max timings from 
> here to there in you, for /all/ of the code paths in between. 
> 
> Plus you can trivially specify that output occurs on a 
> particular cycle, and record the cycle on which input 
> occurred.
> > Now, there are invisible costs in moving data around "inside" 
> > the SoC (e.g., TO floating point registers vs. FROM, etc.). 
> > It's almost impossible to keep all of this sorted out in 
> > your head -- unless you tie your efforts to a single 
> > processor variant over multiple projects.

> Let the IDE do it for you.
If there is a reliable one.

STM32CubeIDE is not really so.

On 03/07/2021 13:46, Anthony William Sloman wrote:
> On Saturday, July 3, 2021 at 7:32:56 PM UTC+10, Michael Kellett wrote:
>> On 02/07/2021 17:59, Don Y wrote:
>>> On 7/2/2021 9:18 AM, Michael Kellett wrote:
>>>> Your biggest problem right now is finding a part that you can actually
>>>> buy.
>>>
>>> Yup. Having disti/rep friends is golden, now! :>
>>>
>>>> In normal times I'd have suggested an STM32Fxxxx part, there are chips
>>>> with multiple ADCs capable of > 2MHz sampling rates in small packages
>>>> - but the trick will be finding stock.
>>>
>>> I've been eying the STM32F730R8T6 -- a reasonably small package, a bit
>>> pricey
>>> (almost $3 at 10K) and WAY overkill. But, I like some of the features that
>>> can help "lock" the hardware into a particular configuration that,
>>> hopefully,
>>> keeps the circuit "safe".
>>>
>>> I've not yet reviewed the security provisions, etc. (but the CPU is
>>> overkill
>>> for my needs)
>>>
>>>> If you just want a cheapo development board then one of the Nucleo
>>>> boards from ST will do you nicely.
>>>> Farnell have 924 of the Nucleo F429ZI in stock (but no chips until 2022)
>>>> It's overkill for your job perhaps - but might be the best way to
>>>> start work.
>>>> If you just want to do it on paper I'd suggest you need to pick a
>>>> processor with at least 2 ADCs capable of the rate you need. You need
>>>> a fast clock to have fine enough control over the pulse generator
>>>> frequency. That's the easy route but perhaps not the most cost
>>>> effective if you care about production in volume.
>>>>
>>>> It would be tempting to try an STM32G071 - Cortex M0 core, 64MHz, very
>>>> cheap, tiny packages which would (maybe) be just capable but make a
>>>> really nice (small and cheap) controller. Problem is finding any in
>>>> less than 6 months.
>>>
>>> Samples (from a good contact) *or* buy a prebuilt "module" and, use as is,
>>> or disassemble to salvage the components.
>>>
>>> Or, find someone who's using it already (again, a friendly rep can leak
>>> the name of other customers to approach).
>> Another one worth considering (maybe not for your job) is the
>> STM32H750xB - cheapest way I know to get three 16 bit ADCs (3.6MHz
>> sampling rate).
>> Core runs at 480MHz, 1M ram, 128k flash. The LQFP part (100pin) is £5.76
>> (100 off Farnell) - no stock of course but some due in time for Christmas.
>> You might need to go for one of the BGA packages to get access to enough
>> pins to use all the features you need.
> 
> I suspect that I'd use very few pins indeed. The job needs two output - one for each of the two MOSFet drivers, and one input to the A/C converter.
> 
> It might need an external clock, but clock stability isn't an issue, since the MCU would be there to make sure that the MOSFets were driven at - or just below - the resonant frequency of the tank circuit which is going to drift around a bit as the inductor and capacitor warm up, and will probably change if the load changes and the dissipation in the circuit - which isn't going to be large  -changes in consequence.
> 
> You might provide a few signalling outputs - maybe two or three - but it's a pretty simple circuit doing a pretty simple job.
> 
In that case I'd suggest looking at the ST STM32G071 - comes in 32pin 
packages, 64MHz clock, a little slower than ideal but might well be good 
enough. Built in RC oscillator within 1%.
Nice simple Cortex M0 core with at least one fancy timer that can do 
compementary digitial drives (going from memory there so check before 
making irrevocable decisions !).

MK

On 02/07/2021 1:56 pm, Anthony William Sloman wrote:
> The trick would be to look at the output of the inverter, and get the nominally 100kHz square wave to run exactly at the resonant frequency of the tank circuit (100kHz +/-17%), or very slightly slower.
> 

Getting the inverter to run at the tank resonant frequency could be 
regarded as self oscillation - no digital processing needed :(

I guess pulling frequency slightly low could be done by similar 
all-analog means too.

Perhaps someone on SED can do it with just seven transistors!

piglet

On Saturday, 3 July 2021 at 21:36:58 UTC+1, Don Y wrote:
> On 7/3/2021 12:55 PM, Tom Gardner wrote: 
> > On 03/07/21 20:40, Don Y wrote: 
> >> On 7/3/2021 11:56 AM, John Walliker wrote: 
> >>> On Saturday, 3 July 2021 at 18:39:14 UTC+1, Don Y wrote: 
> >>> 
> >>>> The days of (hand-)counting clock cycles to determine the execution 
> >>>> time of a code fragment are long past. 
> >>>> 
> >>>> There's a reason data sheets are now hundreds of pages! 
> >>> 
> >>> True enough. However, there are other options with some of the ARMs 
> >>> such as co-processors in some of the TI and other devices. The 
> >>> RP2040 has a programmable state machine which looks very deterministic 
> >>> and of course the Xcore devices which have been mentioned here 
> >>> provide another approach to deterministic systems. 
> >>> 
> >>> For low-speed applications, the AT-tiny 13 or 2313 are still nice. 
> >> 
> >> Of course. My point was that processors are no longer simple, 
> >> intuitively predictable devices. Anyone who is thinking along 
> >> those lines will be perplexed to discover that the rules have 
> >> changed! 
> > 
> > The xCORE devices had zero surprises for me; I was gobsmacked :) 
> > 
> > I was cutting real multiprocessor and i/o code within a day 
> > of starting to use them 
> > 
> > 
> >> Years ago, one could determine performance largely intuitively 
> >> by simply thinking about the number of bus cycles required in 
> >> a particular opcode execution and multiplying by the number 
> >> of clock cycles per bus cycle, adding fudge, as appropriate. 
> > 
> > You still can, for the 32-core 4000MIPS xCORE processors. 
> > 
> > In fact the IDE will tell you the exact max timings from 
> > here to there in you, for /all/ of the code paths in between. 
> > 
> > Plus you can trivially specify that output occurs on a 
> > particular cycle, and record the cycle on which input 
> > occurred. 
> > 
> > 
> >> Now, there are invisible costs in moving data around "inside" 
> >> the SoC (e.g., TO floating point registers vs. FROM, etc.). 
> >> It's almost impossible to keep all of this sorted out in 
> >> your head -- unless you tie your efforts to a single 
> >> processor variant over multiple projects. 
> > 
> > Let the IDE do it for you. 
> > 
> > 
> >> One of the advantages of having an OS under you is that many of 
> >> these issues can be addressed there, largely freeing the 
> >> developer from worrying about them. 
> > 
> > For the xCORE devices, the RTOS is implemented in hardware, 
> > from I/O up to inter-core message passing. 
> > 
> > The I/O is /delightfully/ simple, from SERDES up to 
> > the high level algorithm. 
> > 
> > 
> >> Of course, that assumes what your doing can be abstracted away 
> >> from the hardware; that an appropriate "driver" can be put in 
> >> place to handle those abstractions! 
> > 
> > Yuck :)
> And these are available in the "under $5" price range? :>

The 16-core versions are around 13 to 15 USD in small quantities.
If you can find stock.  I just had to order some of the 16-core
USB2.0 2000MIPs devices (XU216-512-TQ128) from China.

John

On Saturday, 3 July 2021 at 21:59:38 UTC+1, Michael Kellett wrote:

> In that case I'd suggest looking at the ST STM32G071 - comes in 32pin 
> packages, 64MHz clock, a little slower than ideal but might well be good 
> enough. Built in RC oscillator within 1%. 
> Nice simple Cortex M0 core with at least one fancy timer that can do 
> compementary digitial drives (going from memory there so check before 
> making irrevocable decisions !). 
> 
But do also check the RP2040.  Two ARM M0+ cores at 133MHz,
eight programmable i/o state machines and lots of other nice things.
It costs $1.

John

On 7/3/2021 2:19 PM, John Walliker wrote:

>>>> Of course, that assumes what your doing can be abstracted away
>>>> from the hardware; that an appropriate "driver" can be put in
>>>> place to handle those abstractions!
>>>
>>> Yuck :)
>> And these are available in the "under $5" price range? :>
> 
> The 16-core versions are around 13 to 15 USD in small quantities.

I don't see any of them having mixed-mode capabilities (A/DC, D/AC).
So, unlikely to fit the needs of my PoE controller; unsure how they
would fit the OP's needs...

For my "host" processor requirement, they'd need to support protection
domains (separate address spaces or "object/descriptor based" schemes)
as I need to support "foreign" code at run-time.  And, a wider variety of
peripherals (e.g., at least one Gbe NIC)

But, as a substitute for something like an M-series device, they may
be appropriate (?)

> If you can find stock.  I just had to order some of the 16-core
> USB2.0 2000MIPs devices (XU216-512-TQ128) from China.

I think supply chain problems are going to ding just about every
"interesting" solution -- and maybe some of the boring ones, as well!

I am trying to put off purchasing the rest of my prototypes
as I'm not excited about paying a premium (I need a few thousand
pieces) and I'm sure I won't be able to "weasel" that sort of quantity
from a rep "as a personal favor" (a couple of pieces?  maybe...)

On 7/3/2021 1:55 PM, Ed Lee wrote:

>>> Now, there are invisible costs in moving data around "inside"
>>> the SoC (e.g., TO floating point registers vs. FROM, etc.).
>>> It's almost impossible to keep all of this sorted out in
>>> your head -- unless you tie your efforts to a single
>>> processor variant over multiple projects.
> 
>> Let the IDE do it for you.

> If there is a reliable one.
> 
> STM32CubeIDE is not really so.

IME, there is a great deal of variance in the quality of "factory
tools".  I, long ago, gave up trusting sample application code
or schematics as there were just too many obvious screwups to
leave me with any sort of confidence in "embracing" those tools
(or components).

[I recall talking to a prospective client many years ago wrt a
job he wanted some help with.  He showed me his initial design,
design strategy, etc.  I looked at it and said, "this won't work!"
(no, it wasn't a question of how WELL it would work; it wouldn't work
at all!).  He then confided that he had copied the schematic
from various app notes...  (Run away!  This is NOT going to be
a worthwhile undertaking!!!)]

One of the reasons I develop on FOSS platforms is that I have a chance
of fixing problems that I uncover.  Or, at least, controlling how
may "patches" are introduced to the version that *I* choose to run.
The idea of "updating" to a completely new set of BUGS doesn't
appeal to me!