Fast simple microcontroller

On 03/07/21 21:36, 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?  :>


That's a separate issue. I was commenting on your technical
statements.

The XMOS processors_language I've used were remarkably pleasant
to use.

It made programming fun again, in the way it isn't on
Arduino/ARM/Zync/x86 machines.

On 7/3/2021 3:33 PM, Tom Gardner wrote:
>> And these are available in the "under $5" price range?  :>
> 
> That's a separate issue. I was commenting on your technical
> statements.
> 
> The XMOS processors_language I've used were remarkably pleasant
> to use.
> 
> It made programming fun again, in the way it isn't on
> Arduino/ARM/Zync/x86 machines.

Well, you can't cherry pick features in a solution but, instead,
have to live with what's available OTS.  Or, build what you want
into/onto something that *is* COTS.  (that's the approach I'm
taking, presently, as nothing offers the features and
functionality that I want)

I find that if I can code in a HLL, I am largely isolated from
the peculiarities of the supporting host.  (I compile my code
on several different hosts to verify that it has a decent chance
of *really* being portable)

It boils down to how much "overhead" is involved in getting/making
the environment that you want vs. the application you're trying
to support.

On Saturday, July 3, 2021 at 9:30:21 AM UTC-4, Chris Jones wrote:
> On 03/07/2021 01:01, Clive Arthur wrote: 
> > On 02/07/2021 15:42, Anthony William Sloman wrote: 
> >> On Friday, July 2, 2021 at 11:32:12 PM UTC+10, Chris Jones wrote: 
> > 
> > <snipped> 
> > 
> >>> You'd probably be better off with a small cheap fpga. Some of them work 
> >>> with open-source software now. 
> >> 
> >> But I wouldn't get the A/D converter thrown in, and I'd have to make 
> >> my own 100MHz clock. I've been fond of programmable devices for a long 
> >> time now - my 1996 paper used the (fairly rudimentrary) ICT PA7024 - 
> >> but in this application a micro-controller would provide a lot of bang 
> >> for very few bucks. 
> >> 
> > 
> > The first thing I do for any hard real time control type project is code 
> > some simple functions to use a spare UART as a diagnostics port plugged 
> > in to an ANSI terminal emulator on a PC. TeraTerm works fine. 
> > 
> > Then I use generally single key commands to dump things to the terminal, 
> > adjust things, whatever. On a complicated project I may have several 
> > menus focussed on different aspects. Here's one screen of about ten in 
> > a current project... 
> > 
> > Real Time Clock and Timer test Menu 
> > 
> > Esc : Back 
> > 
> > T : Read Time 
> > D : Dump RTC chip 
> > P : Show Timestamp Parameters 
> > 
> > Clock frequency on J6 pin 1 
> > 0 : Off 
> > 1 : 100Hz 
> > 2 : 1kHz 
> > 3 : 10kHz 
> > 4 : 100kHz 
> > 5 : 1MHz 
> > 
> > Pressing 'D' for example displays this... 
> > 
> > RTC chip dump 
> > 00 : 17 55 14 05 02 07 21 00 00 00 00 00 00 00 00 C8 
> > 10 : 00 1E C0 00 08 00 00 00 00 00 00 00 00 02 00 14 
> > 20 : 40 00 00 00 00 00 00 00 00 20 00 00 00 00 00 00... 
> > 
> > And so on. I can't imagine the pain of not having this. In Bill's 
> > system, you might press '<' or '>' to move the square wave slightly. 'A' 
> > might display the current ADC value. I just add stuff as it's needed 
> > and remove stuff which is no longer useful. 
> > 
> > But not in an FPGA. 
> >
> You could do it in an FPGA. Obviously you could put a CPU with UART in 
> the FPGA design, with the CPU running whatever code to make a menu you 
> would have put on a micro, (but with peripherals that do exactly 
> whatever fast logic you need, unlike those on most microcontrollers), 
> though there are much more efficient ways. 

Why would you need a CPU to provide a simple menu interface???  I've done exactly that in an FPGA will very little effort.  It's the same basic coding structure done so as to facilitate the block RAM for the menu storage.  

Actually it might be fun to see if there are ways of using existing MCU peripherals to do the heavy lifting of this application.  Some of the peripherals can be very capable.  If everything is driven by timers and DMA transfers it might reduce some of the timing uncertainty. 


> There are for example logic analyzers that you can drop into your fpga 
> design, that connect to an external PC for debugging. This is much 
> better than some printf statements to a uart, as you can get timing 
> information about when things happen, that is much more accurate than 
> over a UART. I think most of the bugs are usually caught in simulation 
> so the need for debugging on the hardware may be rare anyway.

Drop in logic analyzers?  Just provide a connector on the board to connect a simple logic analyzer.  Use the existing signals on the interface and a few internal signals that are connected as you desire.  I even added an 8 bit register in one design to select sets of signals to put on an 8 bit I/O port for this.  It never uncovered design flaws in the FPGA, but it did turn up initialization issues from the controlling system software. 

There are quite capable logic analyzers available for a hundred dollars or so. 

-- 

Rick C.

-- Get 1,000 miles of free Supercharging
-- Tesla referral code - https://ts.la/richard11209

On Saturday, July 3, 2021 at 9:46:38 AM UTC-4, bill....@ieee.org wrote:
> On Saturday, July 3, 2021 at 11:00:29 PM UTC+10, gnuarm.del...@gmail.com wrote: 
> > On Friday, July 2, 2021 at 10:35:11 PM UTC-4, bill....@ieee.org wrote: 
> > > On Saturday, July 3, 2021 at 11:28:33 AM UTC+10, gnuarm.del...@gmail.com wrote: 
> > > > On Friday, July 2, 2021 at 1:33:59 AM UTC-4, bill....@ieee.org wrote: 
> > > > > I've been thinking about Timo's inverter, and it looks as if a micro-controller that offered a 100MHz clock rate would be fast enough to do a decent job of switching the Siliconix Si3440DV DMOSFet that I fancy. 
> > > > > 
> > > > > I've found a PIC part that's fast enough, and pretty cheap, but it is designed for digital signal processing, which makes it more complicated than necessary. A nice, dumb but quick 8051 would be good enough. 
> > > > > 
> > > > > Somebody is apparently offers a 600MHz part, but I want something cheap and simple - if fairly fast (but not that fast). Browsing element-14 threw up a few candidates, but I didn't find their search engine all that helpful. 
> > > > > 
> > > > > Has anybody got a favourite part? 
> > > > 
> > > > An FPGA can be used to implement an 8051 or any other MCU architecture you wish at 100 MHz without much trouble. Then you can tailor the peripherals as you choose. Gowin has parts for $3 or less with internal Flash. > 
> > > And the Microchip dsPIC33EPxxxSP50X will do the job for for $3, and throws in a PPL that will multiply up a 7MHz clock to 100MHz as well as an A/D converter that I can use. 
> > > 
> > > The aim is to get a single chip processor that is cheaper and simpler of the shelf. 
> > 
> > Single chip is not synonymous with simple.
> Obviously not. Back when I was working with electron beam microfabicators, the floor plan of a single layer of single chip could be as complex as the street map of New York. Minimum features sizes have gone down quite a bit since then.
> > "Cheap" is relative and you haven't really looked at the total price. For example you seem to think supplying a 7 MHz clock and using a PLL to the MCU is somehow cheaper than the same process with an FPGA. The clock is not an expensive part by any means.
> Actually the Microchip dsPIC33EPxxxSP50X does seem to have an internal RC oscillator, which would probably be good enough for what I need to do. The circuit has to drive the resonant tank at (or just below) it's resonant frequency and the control loop could also cope with drift in the internal oscillator frequency.
> > Likewise, a one input ADC is not an expensive part either.
> Clearly.
> > So you are not looking for cheap as much as "cheapest possible".
> I'm actually looking for "simple" and it looks as if the Microchip part would cost about as much as the Si3440DV MOSFet switches, which is cheap enough.

The trouble is this has become a bit of the X/Y problem.  You ask for X when you are really trying to do Y.  "Simple" has no definition, so you can't really expect to get good advice.  


> > I hope you can get the timing to work with a single instruction stream processor. With the sort of timing requirements your design seems to need it can be tricky to make a sequential processor responsive enough.
> Not in this application.
> > An FPGA, on the other hand, will do the job with very high resolution and not break a sweat... or more accurately, the programmer won't break a sweat. You won't be limited to 100 MHz as the internal PLLs and the logic in FPGAs often work at much higher frequencies, even the low power devices. This project in an FPGA is a slam dunk with probably the shortest development time and smallest risk. 
> > 
> > So it would appear you asked for "simple" but really want minimum price. 
> 
> > Sigma-delta converters are often the choice for FPGAs, but successive approximation is easily done as well. The hard part is the DAC output you need.
> I don't need a DAC at all. All the micro-controller would do would change the period of the square wave-drive to keep it at (or just below) the resonant frequency of the tank circuit

I guess you aren't following the ideas.  To implement a successive approximation ADC you need a DAC.  You set the msb to the DAC and if the comparator indicates the DAC output is greater than the ADC input, you back off that bit and set the next lesser bit.  lather, rinse, repeat.  With an adequately fast DAC you can get MHz sample rates.  This is what they are most likely using in the MCUs at 500 kSPS and 12 bits. 


> > You can get 0.1% resistors for an R-2R ladder without too high a price. It's not clear if that would be adequate or not. The I/O supplies on each bank of FPGA I/Os are separate, so noise from the FPGA internals is minimal.
> I do know about 0.1% resistors. I've specified lots of them. This isn't an application that seems to need them

Yeah, as I said, you aren't following the concepts. 


> > I seem to recall a 100 MHz 8051 created some years ago with the same idea as the propeller that peripherals can be implemented in software. Anyone remember that?
> A 100MHz 8051 would do exactly what I need. At one point I spent a couple of weeks learning about 8051 assembler - it's a pretty rudimentary processor, but does everything I'd need
> > There's also the various Cypress PSOC lines with an emphasis on low cost by trading off fixed peripherals for programmable analog and logic. The processor may not run at 100 MHz, but if you can off load some of the heavy lifting to the programmable portions maybe the lower clock rate is good enough.
> The idea is is to get two roughly 100kHz square waves. With a 100MHz clock, that's a 10-bit counter. Since there is +/17% tolerance on that 100kHz resonant frequency, you might need 11-bits to cope with the worst case. You then have tweak that "100kHz" to fit the tank circuit you've got, and keep tweaking it track the actual resonant frequecy as it cahnges withb load and room temperature. It's not rocket science. 

Yes, I'm sure it's not, but what you describe does not explain how you get from ±17% to 11 bits of resolution on a 100 kHz output  counter.   If you want to explain enough for others to understand, fine.  If not, that's fine too. 

But as I have said very clearly, this is all a slam dunk in an FPGA unless there are parts to the design you aren't explaining.  That's what I think of when someone asks for "simple", something that is easy and straight forward to implement.  

-- 

Rick C.

-+ Get 1,000 miles of free Supercharging
-+ Tesla referral code - https://ts.la/richard11209

On Saturday, July 3, 2021 at 11:04:33 AM UTC-4, Ed Lee wrote:
> On Saturday, July 3, 2021 at 6:30:21 AM UTC-7, Chris Jones wrote: 
> > You could do it in an FPGA. Obviously you could put a CPU with UART in 
> > the FPGA design, with the CPU running whatever code to make a menu you 
> > would have put on a micro, (but with peripherals that do exactly 
> > whatever fast logic you need, unlike those on most microcontrollers), 
> > though there are much more efficient ways.
> But FPGA cannot do the deep sleep as micro. Many micros can sleep in 100uA.

You need to learn about FPGAs before you post.  That is simply not correct.  There's more than one brand that has 100 uA or less sleep modes. 

-- 

Rick C.

+- Get 1,000 miles of free Supercharging
+- Tesla referral code - https://ts.la/richard11209 

On Saturday, July 3, 2021 at 5:17:50 PM UTC-7, gnuarm.del...@gmail.com wrote:
> On Saturday, July 3, 2021 at 11:04:33 AM UTC-4, Ed Lee wrote: 
> > On Saturday, July 3, 2021 at 6:30:21 AM UTC-7, Chris Jones wrote: 
> > > You could do it in an FPGA. Obviously you could put a CPU with UART in 
> > > the FPGA design, with the CPU running whatever code to make a menu you 
> > > would have put on a micro, (but with peripherals that do exactly 
> > > whatever fast logic you need, unlike those on most microcontrollers), 
> > > though there are much more efficient ways. 
> > But FPGA cannot do the deep sleep as micro. Many micros can sleep in 100uA.
> You need to learn about FPGAs before you post. That is simply not correct. There's more than one brand that has 100 uA or less sleep modes. 

And with timer and interrupt to wakeup?  Which one?

On Saturday, July 3, 2021 at 12:55:52 PM UTC-4, John Walliker wrote:
> On Friday, 2 July 2021 at 17:51:49 UTC+1, Don Y wrote: 
> 
> > It's documented, but the architecture of (esp ARMs) isn't as simple/clean 
> > as older processors. The I/O subsystem and processor operate independently 
> > of each other -- different clocks, etc. So, one needs to insert R/W barriers 
> > if you want to ensure the two are back in sync at any point in time.
> The M0+ ARMs seem to have very tight coupling between the cpu and the i/o pins. 
> ARM claim: 
> "The processor optionally implements a single-cycle I/O port that provides 
> very high speed access to tightly-coupled peripherals, such as 
> general-purpose-I/O (GPIO)." 
> 
> Microchip claim: 
> "The Arm® Cortex®-M0+ CPU's local bus (IOBUS) provides a direct connection 
> between the CPU and the PORT. IOBUS transactions bypass the Advanced 
> High-performance Bus (AHB) bus allowing I/O pins to be manipulated in a single 
> instruction cycle. IOBUS transactions are not subject to any wait-states induced 
> by AHB bus arbitration. 
> 
> ST claim: 
> "The Cortex ® -M0+ also features a Single-cycle I/O Port, 
> enabling the CPU to access data with a 1-clock latency. 
> In the STM32G0, the Single-cycle I/O Port is used to 
> access GPIO port registers, enabling these ports to work 
> at the processor frequency." 

This is the sort of stuff that makes MCUs complex to use in my opinion.  They have manuals many, many pages thick and take tons of work to master each peripheral because they try to be so general purpose.  It is much easier to roll your own peripheral in many cases. 

-- 

Rick C.

++ Get 1,000 miles of free Supercharging
++ Tesla referral code - https://ts.la/richard11209

On 4/7/21 5:55 am, Tom Gardner wrote:
> 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.

What you just said implies that they have solved the halting problem.

Which makes it clear that you are more enthusiastic than factual.

It still sounds like they have a nice feature there, even if it cannot 
do what you say.

CH

On Saturday, July 3, 2021 at 8:19:39 PM UTC-4, Ed Lee wrote:
> On Saturday, July 3, 2021 at 5:17:50 PM UTC-7, gnuarm.del...@gmail.com wrote: 
> > On Saturday, July 3, 2021 at 11:04:33 AM UTC-4, Ed Lee wrote: 
> > > On Saturday, July 3, 2021 at 6:30:21 AM UTC-7, Chris Jones wrote: 
> > > > You could do it in an FPGA. Obviously you could put a CPU with UART in 
> > > > the FPGA design, with the CPU running whatever code to make a menu you 
> > > > would have put on a micro, (but with peripherals that do exactly 
> > > > whatever fast logic you need, unlike those on most microcontrollers), 
> > > > though there are much more efficient ways. 
> > > But FPGA cannot do the deep sleep as micro. Many micros can sleep in 100uA. 
> > You need to learn about FPGAs before you post. That is simply not correct. There's more than one brand that has 100 uA or less sleep modes.
> And with timer and interrupt to wakeup? Which one?

There are some low idle current parts from the company that used to be Actel until they were bought by Microsemi who was bought by Microchip, Polar something I think.  I never researched them much.  The ones I know more about are the ICE40 parts from Lattice.  There are some versions that have idle currents in the ~50 uA range.  If you keep a fast clock running there will be additional current just like in an MCU.  Run a slow clock for a timer and it will draw virtually no additional current. 

-- 

Rick C.

--- Get 1,000 miles of free Supercharging
--- Tesla referral code - https://ts.la/richard11209

On Saturday, July 3, 2021 at 8:35:49 PM UTC-4, Clifford Heath wrote:
> On 4/7/21 5:55 am, Tom Gardner wrote: 
> > 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.
> What you just said implies that they have solved the halting problem. 
> 
> Which makes it clear that you are more enthusiastic than factual. 
> 
> It still sounds like they have a nice feature there, even if it cannot 
> do what you say. 

What you just said shows you don't understand the halting problem.  Can you state it in a few words?  Maybe that will help you understand why your claim is not correct. 

-- 

Rick C.

--+ Get 1,000 miles of free Supercharging
--+ Tesla referral code - https://ts.la/richard11209