Interrupts: can be lost?

Archive a VM or container.

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs 
Principal Consultant 
ElectroOptical Innovations LLC / Hobbs ElectroOptics 
Optics, Electro-optics, Photonics, Analog Electronics 
Briarcliff Manor NY 10510 

http://electrooptical.net 
http://hobbs-eo.com

I thought there were some Chinese clones of the lower end STM32F series but I haven't paid close attention.

I think current practice is to run your system inside a VM that you snapshot so you can later reproduce it. In critical systems you do that whenever you make a software release, so you snapshot not only the current source code (revision control already does that), but also the complete tool chain including compilers, libraries, all the build artifacts, and the whole OS.

yep, I know there are several clones of STM32F103xxxx

But they're not exactly compatible. I heard they fixed some of the bugs.

"time-triggered" is special variant of polled system. With polled system it is pretty clear that you need to poll frequently enough and after testing you can be resonably sure that various pieces run in allocated time.

With interrupt-driven system at first glance one can think that much slower processor will do the job. Namely, it is typical that on average there are no or little problematic coincidencies. So is system is fast enough to handle each interrupt separately it may appear to work. Problem is that coincidencies happen. They happen infrequently enough that testing for them is hard or impossible. But coincidencies may cause failure in operation. Related problem is correctness of code. For long time it is known that is essentially imposible to test correctness is interrupt driven system. More precisly, it is imposible to test interaction of components. So system must be correct by design. It is known how to do this. But correct design requires effort and apparently many programmers lack needed knowledge. So simpler alternatives may look attractive, especially to managers and regulatory agencies.

--
                              Waldek Hebisch

For example, MISRA ;-)

Yes, that is exactly what a company will be counting on for 20 years of support, Chinese clones. Are you actually reading the thread?

You still need the OS and hardware interfaces. Can you still buy a copy of XP?

--

  Rick C. 

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

So "clone" equals "second source"???

--

  Rick C. 

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

Not really. They haven't licensed ST's masks, they've just designed their own chips to match the documented behaviour.

The chips I know of are by GigiDevice and Mindmotion, part numbers GD32F3??? and MM32F??? to match the STM32F???.

I see over 100 variants waiting on reels in JLCPCB's fab.

Clifford Heath.

Il 10/07/2020 01:24, snipped-for-privacy@math.uni.wroc.pl ha scritto:

How to do this? :-)

es

Ok, then they are pretty useless as second sources. I see someone mentione d bugs that are being worked out. Not encouraging. Is Gigidevice a compan y that makes FPGAs? Or am I mixing them up with someone else? Ah, I see I have downloaded their data sheets, so I guess I was looking at a low cost RISC-V board and also have info on their ARM ST clone chip. Wait, it's the same chip! No sign of FPGAs. That was one of the other companies like AG M, Anlogic or maybe Gowin. AGM has an interesting data sheet, but it's two years old and no sign of the device.

--

  Rick C. 

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

You are looking for an education on interrupt design in MCU systems? I can recommend a few good companies who teach this material. It is also covered in many text books.

Once again, I will say, this is no small reason why I like FPGA design in HDL. It just doesn't have this sort of complexity. The only complexity is from the design itself, nothing added gratuitously.

--

  Rick C. 

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

Roughly speaking, you have to know how often the different interrupts can occur, what priorities they have, how long you take to handle them - that kind of thing. And you have to calculate the worst-case scenarios so that you can guarantee that you don't lose (important) events if you are unlucky in the ordering and timing. As Waldek says, you generally can't check this sort of thing by testing as it is usually very difficult to make the timing in the test happen in exactly the right places. (It's like race conditions in multi-threading systems in that aspect.)

If you use timing-driven polling, it is often easier to be sure of things because you have more regularity in the system.

And if you use a microcontroller with appropriate peripherals for the task, it is also much simpler. Peripherals with buffers, DMAs, etc., that can handle at least a little of the timing autonomously means you have a lot more flexibility in how you need to react to events in software.

Separate your parts into the bits that generate code, and the rest. The toolchain is important - the compiler, libraries and build-critical parts. The IDE is not critical, nor are debuggers, programmers, etc. I don't (usually) archive VM's - I archive folders with toolchains. You only need a VM if the tools won't run on later OS's (or DOSBox or Wine).

It can be a lot more difficult if the toolchain has some kind of licensing and protection mechanism. You might have to archive physical computers, not just VM's, to get that all preserved.

I don't believe you can still buy a license for XP. But an installation CD from long ago works perfectly well as an installation CD now (especially if it is an iso file for a VM...). You have IIRC 30 days to use it before the "activation" mechanism locks you out. (And there are ways around that too, if you want to go down that path.)

s

support, Chinese clones. Are you actually reading the thread?

at

y of XP?

All vendor supplied tool chains for FPGAs have licensing. The only way to continue to use an old license is to continue to reset the date on the mach ine. Even if you have a perpetual license you have to renew the license fi le. I recall finding out about that on a CAE system from 40 years ago. I asked what happens if the company goes under and the guy just shrugged. I don't recall which company it was from, but it was on Apollo computers. An yone remember them? I think they got bought by Sun, no? Looks like it was HP!

--

  Rick C. 

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

In a perfect world (from my viewpoint!), development software doesn't need any kind of license renewal, internet connection, time-limitation, software lock, USB dongle, etc., to work. And it works on Linux with little or no requirements for particular distributions or non-default libraries. I have nothing against paying for software or a license - that's okay. I also don't mind paying yearly fees for updates. But when I buy the software, I want the software I bought to be useable from any system, at any time in the future. There can be /legal/ restrictions (single user, single company, single project, whatever), but I don't want /technical/ restrictions that limit my ability to use the software. I've dealt with enough crap from software locked to laptops that died, software that "phones home" to servers that no longer exist, dongles that don't work, etc.

This kind of nonsense just makes honest users use workarounds. I have more than enough virtual machines with virtual network cards that all have the same MAC address, and have at least four ancient hard disks that all have the same serial number. And I have seen a computer with its time and date locked to an old date because the old license dongle worked but the new one did not.

I don't always get things the way I want, but these things are a significant influence for my choice of tools, and therefore my choice of hardware. I've rejected microcontroller families solely on the basis of a lack of Linux support in their development tools. And if I do any more FPGA work, the way the license and "software protection" is handled will definitely be a factor in choosing devices and tools. (I don't claim it will be the overriding factor - there are bigger differences and fewer vendor choices in the FPGA world than in the microcontroller world.)

I don't know 8051, but every MCU I've ever used had interrupt flag registers. When an interrupt comes a flag is set, and then until you don't reset this flag (generally within the ISR) the subsequent interrupts on the same source are ignored. Therefore it is true that subsequent interrupts on the same source can be lost if they are too close [1].

But if the interrupts are different, this is not true. Two different interrupts events can come even at the exact same time, and both will be flagged. Of course they won't be serviced at the same time (unless you have a multicore CPU, maybe) but they will be "queued" and processed one at a time.

[1] Actually I think that there are some MCUs that have a counter instead of a flag for each interrupt source, and therefore they can queue multiple interrupts of the same source before they are processed. Then each call of the ISR will decrement the counter.

--
Fletto i muscoli e sono nel vuoto.

Second source in the context of processors is overrated. Rewind about 40 years when the 6809 had a second source, a 6309 from Hitachi to no effect on the processor lifespan. With some luck and a lot of careful consideration one can pick a processor which will live for >10 years. I have managed that with the 68hc11, 68340, mpc5200b, mcf52211... not so sure about the mpc824x, but my design with it did not live long enough for this to matter (yet it did a good job aiding the migration 68k -> power).

I can't speak firsthand on the toolchains people use as those I use are 100% mine, I can even run on a VM emulating the 6809 in dps windows what I ran before I had all toolchains mine, things I have written back in the 80-s.

I know some people archive entire machines so they can replicate the design process years later if needed; but with flash memories relying on tinier and tinier gate charges this becomes less and less viable (I have a dps machine on my desk 20+ years old, and I have 10+ years old netMCA devices in the field which show no issues... I think flash memories of a few megabytes which will hold charge for 10+ years are still available, time will tell.

Dimiter ====================================================== Dimiter Popoff, TGI

======================================================

Il 11/07/2020 12:12, dalai lamah ha scritto:

This is exactly what I thought when reading that sentence in the book.