Yet another "Getting Started With ARM" post...

[james_s]

I've been in this boat as well. I started using 8 bit AVRs a little over 20 years ago, for the longest time I pooh-poohed the Arduino thing but finally I decided to give it a go due to the vast number of libraries and extreme ease of making all sorts of random peripherals work. Then the device support continued to grow and now has become extremely impressive, however it's still hobbled by software that is absolute garbage. Still, I can pick up a nifty serial OLED, sensors, whatever and have it up and running in 5 minutes so I put up with the painfully awful IDE.

Several times I've decided to give ARM a try, bought a cheap dev board to play with, started mucking around trying to figure out what software to use and get that set up and each time I've sunk several hours into it then finally given up and pulled out the Arduino or the old bare AVR with Bascom and quickly built whatever I was trying to build. I really want to like the ARM platform and use it but the complexity and hassle ends up being more than I want to deal with for the simple projects I typically build. 

[ataradov]

You can't really compare AVR and ARM this way. AVRs have one supplier, and they mostly feel the same (excluding Xmegas) and have the same tools.

ARM has many vendors, so if your idea is to use vendor libraries, then you will have to learn many times. And then vendors constantly obsolete and rewrite their libraries, so you will have to deal with that too.

But if you approach this from just taking the device and doing your own programming, once you have the basic environment set up, all the devices are essentially the same. So one time effort pays off many times. It does take some time to figure it out, but all things considered it is not that hard.

For me personally at this point it is much more of a hassle to use AVR than ARM from a vendor I have never seen before.

[kamtar]

Don't try to think too much into the future and don't overcomplicate it for yourself.

Pick a vendor
 - if you are undecided go for ST as they are widely used in hobby projects and you can find a lot of tutorials but it doesn't matter that much, remember that majority of those ARM MCUs are really similar and stuff are done and designed in a similar way.

- Pick a dev. board and stick with official vendor IDE + libraries. ST is using eclipse + gcc, NXP/freescale is using eclipse + gcc. You can always make those eclipse IDEs work with any other arm vendor MCUs later.

 - different SDKs and libraries aren't really an issue. It's just C API when you understand how typical ARM periphs. work it will make sense and it's going to take you just few hours to learn new API. Also don't forget that some libraries are really lacking and you will have to in the end write some of your own implementations.

GCC has great support for ARM so there aren't really that many reasons to use anything different as your compiler unless you want to pay up some solid business money for fancy features.

[james_s]

I'll try it again at some point and see if I can get somewhere with it this time. I don't really need the power of an ARM in anything I've made so far but it does seem to be the direction everything is going.

It would be nice if someone could build an Arduino compatible IDE that isn't garbage. Something that works with most of the existing community libraries and code but not done in Java and with some real debugging capabilities. Maybe there's too much inherent baggage to make that work but it is enticing given the vast array of supported hardware, it's so incredibly easy to slap together something that just works with minimal effort, except when it doesn't work it can be a real pain.

[T3sl4co1l]

It appears there is a Code::Blocks Arduino variant, if you're curious?

Tim

[tmadness]

I've been in this boat as well. I started using 8 bit AVRs a little over 20 years ago, for the longest time I pooh-poohed the Arduino thing but finally I decided to give it a go due to the vast number of libraries and extreme ease of making all sorts of random peripherals work. Then the device support continued to grow and now has become extremely impressive, however it's still hobbled by software that is absolute garbage. Still, I can pick up a nifty serial OLED, sensors, whatever and have it up and running in 5 minutes so I put up with the painfully awful IDE.

Several times I've decided to give ARM a try, bought a cheap dev board to play with, started mucking around trying to figure out what software to use and get that set up and each time I've sunk several hours into it then finally given up and pulled out the Arduino or the old bare AVR with Bascom and quickly built whatever I was trying to build. I really want to like the ARM platform and use it but the complexity and hassle ends up being more than I want to deal with for the simple projects I typically build.

I recently had the same epiphany. I'm primarily a electrical engineer who uses micros as a tool in solving my problem. The Arduino core framework is just beautiful representation of open source collaboration. Now, not all cores are made equal, but there exist some really high quality cores and libraries. PJRC's Teensy is a amazing example, yes, its not the most efficient code but by good lord does it work for 90% of the use cases, its amazingly documented (dare i say better than most vendor libraries), and the 3.5 3.6 and 4.1 are some beafy mofos. At the end of the day my work gets done faster, simpler, and i can go back in and optimize the shit out the existing libraries if I need to. The only thing I miss is debugging support on the hardware level in the teensy family (not a problem if you use the chip and roll your own board).

BTW I use VSCode and Platform IO for development. its just leagues ahead of the Arduino IDE and a lot more faster than the eclipse based vendor IDEs that exist out there.

[nigelwright7557]

I have always been  a PIC man having been a PIC consultant for 13 years.
However I recently ventured into M7.
I found the data sheet extremely vague and unhelpful.
I also really struggled getting info on the programming port.
I found one and used that on my pcb.
I also managed to get a basic circuit for the M7 for my pcb.
The pcb came back and I built up a bare system with just an LED.
I used MPLAB X and Harmony to get some basic software.
The M7 programmed once and then I just had a flashing LED but couldnt program it again.
It turned out I had NRST on pin 6 of Microchip Snap programmer and it should be on pin 1.
So sorted that but M7 still wouldnt program.
I asked Microchip and they said it had bricked and needed a high on ERASE and a reset pulse.
That unbricked it but I couldnt flash the LED.
So into debug mode and single stepped.
It got through processor clock setup ok but crashed out when setting up PIO.
So on to Microchip again and they asked for circuit and my code.
That was about a week ago and still no reply.

I design USB scopes (mid speed) and wanted to know if the M7 could clock out data from a A2D fast enough to make the £10 it cost worthwhile.
Luckily I have other projects to be getting on with but Microchip are slow with help.

[westfw]

However I recently ventured into M7.

Into the deep end, eh?  Which chip?

I found the data sheet extremely vague and unhelpful.

ARM Chip datasheets almost exclusively have "refer to the ARM manual for documentation of the CPU and ARM peripherals."  That's somewhat understandable, since the ARM manual is another 800+ pages (and, alas, not well written for anyone new to the architecture.)  But annoying.
Some datasheets are just for the particular chip.  See the "chip-family reference manual" for details.  In the worst case, separate PDF for each peripheral.  :-(

I also really struggled getting info on the programming port.

There generally is no programming port.   There's a debug port that can be used for programming, and maybe a bootloader.Programming via the debug port is frequently done by loading sort-of-bootloader code into RAM and executing it.

So on to Microchip again and they asked for circuit and my code.
That was about a week ago and still no reply.

Vendors tend to suck at both beginner questions and very technical questions.  You'd be better off finding a user forum like EEVBLOG, Arduino, or AVRFreaks.  (I suspect you'd be more likely to get answers on Arduino or AVRFreaks Forums, even though neither one is supposed to be about Cortex-M7  :-) )

[ignilux]

So I've spent the past few days getting re-acquainted with doing things as generically ARM as possible, using CMSIS-CORE and -SVD as needed. After the revelation that many manufacturers use the same format of collecting peripheral registers in structs, and that accessing them is done with the standard abbreviated struct pointer dereferencing (SYSCON->SOME_REG_IN_SYSCON[0].SOME_MEMBER |= (1 << n); ), everything has become much more clear. The hardest part for me intellectually was separating the bells and whistles of the SDK from the standardized format of CMSIS. The (NXP, at least) SDK is handy, since it abstracts writing to registers by replacing those operations with functions, but it is much less portable. The NXP user manual does a nice job of giving a simple list of steps to configure the peripheral at the beginning of each chapter, with notes about the order in which things must be done. So to those who were in the same boat as myself, get familiar with CMSIS, and things will become clearer. I'll also second the recommendation for the Embedded Systems Programming Course from Miro Samek.

For a long time I, too, turned my nose up at Arduino. At some point I realized that it is simply a tool, and it can be used for the forces of good or the forces of evil. If you need some one-time utility hardware like an EEPROM programmer, you will get there faster and easier with an Arduino than by any other route. Sure, the code size might be huge, and it might run slower than it should, but you'll spend an hour or two instead of a weekend. It's no different than any other development board, in that it lets you get things done faster and easier, but you'd be foolish to use it in a finished product. Of course, I recently designed a bit of hardware for a finished product that includes a Teensy 4.0, but it's there for the fact that I won't be writing the firmware, and the person who will has limited experience writing C/C++ for embedded systems. As with the entirety of engineering, everything is a trade-off, and our job is to pick the best compromise for the constraints given.

[Siwastaja]

Hi, all-

I've been programming bare metal C on 8-bit ATmega, ATtiny, and PIC MCUs for the past 5 years or so, and have become very comfortable with the workflow, i.e. efficient scanning of the datasheet, set a handful of registers for a given peripheral, and write the program. Despite my enduring love for the 8-bit-ers, it's become increasingly apparent that I need to familiarize myself with the ARM Cortex-M family. However, every time I try I find the whole process quite discouraging.

Spot on.

I simply declined to do anything else than what I had been doing with Atmel or PIC MCUs, and that was a great success. You describe the process which works for AVRs and PICs - and guess what, it works for ARM Cortex-M microcontrollers equally well.

Of course, having more features, the documents are longer. Instead of a 400-page "datasheet", you might have a 200-page datasheet just for physical/electrical properties, plus a 2000-page "reference manual" which explains all the peripherals, plus a few hundred pages of CPU core documentation (rarely needed).

Being more complex, there are more traps. OTOH, you have likely experienced such traps already, this isn't going to change the game.

So the process is the same, and all your prior experience helps you.

It seems that what makes the architecture great (many manufacturers to choose from, tons of different peripherals available, etc) also makes it easy to get lost. For example, I picked up an NXP LPC54114 dev board a while back. There are diehard endorsements across the web of different software from Keil, IAR, Eclipse, stfu use emacs, etc. Well, NXP wants you to install their IDE, and their SDK. Fine, I'll do that. The SDK has a fairly hefty API, with functions that do a lot of register setting, peripheral configuration, etc. It also includes a number of CMSIS libraries, which initially looked like a great concept but it soon becomes clear that it isn't nearly as portable as it should be. The board itself includes a "Link 2" debug probe, but many will tell you to pick up a Black Magic Probe or J-Link EDU.

Note there is absolutely nothing in the architecture that dictates this. The ARM microcontroller architecture and typical MCU peripheral implementations actually tend to be quite sane and understandable, and easily worked with in C, from scratch, just reading the documentation.

I just looked for the .h files that define the register names in the reference manual, and that's it. Some manufacturers may require you to install some stupid software package just to extract the files. This sucks; alternatively, just google for the header files and you'll find copies hanging around the 'net.

Any way that programs a chip works. UART bootloader, or the integrated debug interface of the eval board you have.

So now we have multiple compilers,

Use GCC.

multiple C library implementations,

Nothing wrong with newlib, I think? Don't think about it too much, you'll find out if you need something else.

Get everything here:
https://launchpad.net/gcc-arm-embedded

many IDEs

No need to use any IDE. If you want to, then you obviously know what you want to use.

I currently use gedit to write code. Programmer's notepad, Notepad++ and so on come to mind on Windows.

three overlapping ways to write the code (SDK, CMSIS, register manipulation),

Do it like you did with AVR or PIC. Consider using libraries only with complex things (USB, TCP/IP...)

and three ways to debug and program.

I started with UART bootloader on STM32 and still mostly use it. No special hardware needed, an improvement over AVR.

Equivalent of "printf debugging", i.e., "turn on LED debugging" works fine and is scalable for complex/demanding projects where debug interfaces and IDE debug tools do not suffice anymore.

Yes, without a "debugger" you can't easily single-step through all code to see if it does what you think you wanted to do, but that's not a viable way to write code anyway, despite people doing that.

The worst part is that everywhere you look for help, all you find is tutorials about the SDK, mbed, FreeRTOS, proprietary vendor tools, etc.

It took some time for me to realize that all these tutorials exist because all such systems are so freaking difficult, hence the need for tutorials!

To do what you did with AVR/PIC, you don't need too many tutorials - a few code samples, like those given by ataradov, suffice. Basically, just follow the advice of ataradov.

Is there any toolchain that will provide a workflow similar to that in MPLAB or Atmel Studio 7? I don't want 10k of program memory eaten up by vendor bloatware, but on the other hand I quite enjoy some level of abstraction in terms of SFR macros, etc. After all, I'd just use assembly if I was anti-abstraction. I'm not looking for an "Arduino solution", but I don't want to have to write my own reset vector with inline assembly. I hope this makes sense, and thanks for your time.

Yes, I understand where you are coming from: for the standard AVR workflow, avr-gcc somehow autogenerated the startup code (or picked a correct file automatically), and was able to map the data and code to the correct memory addresses - i.e., choose a correct linker script -, all this happened behind my back, didn't have to think about it at all.

arm-gcc-none-eabi does not do this. So I need to supply startup code and a linker script. But, in the end, this won't ruin your day. Copy-paste the startup code and linker script, modify when needed - problem solved in a very pragmatic way. You still have the benefit of being able to look at them if you need to understand what happens under the hood - not to mention being able to modify them when you later find out you have special requirements and want to use the fancy features higher-end MCUs offer, such as core-coupled fast RAMs. The best part, what you learn here, is all applicable on all ARM MCUs, and not only ARM, it's basic computer science that has been relevant for decades, and will be relevant for decades to come. This is complete opposite to time wasted going through tutorials and learning how to install the trend IDE and trend framework of the year, only to learn the new trends the next year (or the next device you use).

[SiliconWizard]

I found the data sheet extremely vague and unhelpful.

ARM Chip datasheets almost exclusively have "refer to the ARM manual for documentation of the CPU and ARM peripherals."  That's somewhat understandable, since the ARM manual is another 800+ pages (and, alas, not well written for anyone new to the architecture.)  But annoying.
Some datasheets are just for the particular chip.  See the "chip-family reference manual" for details.  In the worst case, separate PDF for each peripheral.  :-(

That's the beauty and the pain of dealing with ARM-based MCUs. They can leverage the whole ARM ecosystem. Drawback for the user, on some level, is that you'll be expected to get enough knowledge about the ARM architecture and ecosystem itself. Individual MCU vendors are not going to bother duplicating existing and general information about ARM cores and related tools. The benefit is that once you've built enough such knowledge, you'll be able to reuse it for other ARM-based MCUs. So that's an investment.

Many users not willing to bother with the details will use the IDEs, code generators, libraries provided by each vendor and stick to that (even when that's a bit painful). Those willing to get further and more "baremetal" will have quite a few things to learn. Certainly more than with your basic, proprietary MCU such as pre-PIC32 PIC MCUs. And a significant chunk of this information will be found outside of the vendor's documentation.

[techman-001]

<snip>
 If you need some one-time utility hardware like an EEPROM programmer, you will get there faster and easier with an Arduino than by any other route.
<snip>

I have built many eprom programmers since 1974 including a 48 unit 2732 production programmer (1985), a GPL general purpose MCU and ROM burner (1999) and I believe that Forth on ARM is the easiest method by far for such a project.

One MCU, some transistors (for the EPROM high voltage switching) and I could have a unit up and running in a couple of hours, no libraries, no java IDE, no Arduino.

[james_s]

I have built many eprom programmers since 1974 including a 48 unit 2732 production programmer (1985), a GPL general purpose MCU and ROM burner (1999) and I believe that Forth on ARM is the easiest method by far for such a project.

One MCU, some transistors (for the EPROM high voltage switching) and I could have a unit up and running in a couple of hours, no libraries, no java IDE, no Arduino.

That's great, good for you, but how many hobbyists do you think could do that without extensive handholding? Forth? I played with it a few times on an old Sun workstation, seemed like an interesting language but I don't know anyone personally who has ever really used it. Obviously you are not the target audience of the Arduino platform. The advantage is the user community, libraries and documentation, it makes it easy for people who are NOT seasoned software developers to jump in and make something work. As I already mentioned, I've been using AVRs bare metal for over 20 years, obviously I know how to do it, but even I was eventually won over by the absolutely ridiculous ease of lashing up something that works with Arduino. It's like building something out of Legos or Erector set, it's not a slick production ready product but if you just need quick and easy it's fantastic. I remember spending many hours trying to make sense of Chinese datasheets for various widgets and figure out how to talk to them, now I just load up a library and off it goes, I can have it doing something in minutes.

I don't want to turn this thread into yet another Arduino vs everything else debate though.

[nigelwright7557]

However I recently ventured into M7.

Into the deep end, eh?  Which chip?

I found the data sheet extremely vague and unhelpful.

ARM Chip datasheets almost exclusively have "refer to the ARM manual for documentation of the CPU and ARM peripherals."  That's somewhat understandable, since the ARM manual is another 800+ pages (and, alas, not well written for anyone new to the architecture.)  But annoying.
Some datasheets are just for the particular chip.  See the "chip-family reference manual" for details.  In the worst case, separate PDF for each peripheral.  :-(

I also really struggled getting info on the programming port.

There generally is no programming port.   There's a debug port that can be used for programming, and maybe a bootloader.Programming via the debug port is frequently done by loading sort-of-bootloader code into RAM and executing it.

So on to Microchip again and they asked for circuit and my code.
That was about a week ago and still no reply.

Vendors tend to suck at both beginner questions and very technical questions.  You'd be better off finding a user forum like EEVBLOG, Arduino, or AVRFreaks.  (I suspect you'd be more likely to get answers on Arduino or AVRFreaks Forums, even though neither one is supposed to be about Cortex-M7  :-) )

I decided on the ATSAME70J21B. When  I originally sent my circuit to Microchip when I was having problems they said the A2D doesnt work on that model.
It says it does in the datasheet but Microchip said I should have read the errata sheet to find out all the bugs.

Microchip do manage to throw a spanner in works sometimes. I upgraded a project from pic32mx220 to pic32mx 274 using same pins but a faster PIC.
I built up the pcb and it wasnt working right. I found in the end Microchip had changed a GPIO pin to input only on that device. I couldnt find that information in the datasheet and also Harmony shows the pin as GPIO input or output ! So I was upset I had to add a wire to my pcb to another free pin.

[ataradov]

What specific errata says that ADC does not work on SAM E70? There are a couple erratas, but nothing that would render it unusable. A lot of people use it and it generally works.

[nigelwright7557]

That's great, good for you, but how many hobbyists do you think could do that without extensive handholding? Forth? I played with it a few times on an old Sun workstation, seemed like an interesting language but I don't know anyone personally who has ever really used it. Obviously you are not the target audience of the Arduino platform. The advantage is the user community, libraries and documentation, it makes it easy for people who are NOT seasoned software developers to jump in and make something work. As I already mentioned, I've been using AVRs bare metal for over 20 years, obviously I know how to do it, but even I was eventually won over by the absolutely ridiculous ease of lashing up something that works with Arduino. It's like building something out of Legos or Erector set, it's not a slick production ready product but if you just need quick and easy it's fantastic. I remember spending many hours trying to make sense of Chinese datasheets for various widgets and figure out how to talk to them, now I just load up a library and off it goes, I can have it doing something in minutes.

I don't want to turn this thread into yet another Arduino vs everything else debate though.

I have worked on PIC micro's since about 1985.
Pretty horrible beasts but cheap and plentiful.
I much preferred the Z80.
Some of the early ones were very basic.
As time has gone on the complexity has gone through the roof.
Some of the newer PIC32 series almost need a degree in chip design to understand them.
Early years A2D was fairly simple to setup and use.
Some of the new ones needs lots of register setting up with 32 bits of data.
Microchip Harmony does help quite a bit but you still need detailed understanding of the hardware.
What was once just a quick datasheet read is now a datasheet and many supporting pdf's to understand the hardware details.

[nigelwright7557]

What specific errata says that ADC does not work on SAM E70? There are a couple erratas, but nothing that would render it unusable. A lot of people use it and it generally works.

Apparently USB doesnt work on 64 pin devices. At least according to Microchip and the errata sheet.
I have changed my design to the 100 pin ATSAME70N19.

[ataradov]

Yes, USB HS does not work on 64-pin parts, since there is no VBG pin, which sets the bias current.

[techman-001]

I have built many eprom programmers since 1974 including a 48 unit 2732 production programmer (1985), a GPL general purpose MCU and ROM burner (1999) and I believe that Forth on ARM is the easiest method by far for such a project.

One MCU, some transistors (for the EPROM high voltage switching) and I could have a unit up and running in a couple of hours, no libraries, no java IDE, no Arduino.

That's great, good for you, but how many hobbyists do you think could do that without extensive handholding? Forth? I played with it a few times on an old Sun workstation, seemed like an interesting language but I don't know anyone personally who has ever really used it. Obviously you are not the target audience of the Arduino platform. The advantage is the user community, libraries and documentation, it makes it easy for people who are NOT seasoned software developers to jump in and make something work. As I already mentioned, I've been using AVRs bare metal for over 20 years, obviously I know how to do it, but even I was eventually won over by the absolutely ridiculous ease of lashing up something that works with Arduino. It's like building something out of Legos or Erector set, it's not a slick production ready product but if you just need quick and easy it's fantastic. I remember spending many hours trying to make sense of Chinese datasheets for various widgets and figure out how to talk to them, now I just load up a library and off it goes, I can have it doing something in minutes.

I don't want to turn this thread into yet another Arduino vs everything else debate though.

I believe that hobbyists are capable of anything, I don't see them as needing extensive hand-holding, I believe they can learn all by themselves.

I do however believe that any hobbyist who wants to learn real embedded needs to get far away from Arduino asap, and even if they're not interested in Forth, at least use GCC, libcm3 ( or whatever) and a editor.

[james_s]

I believe that hobbyists are capable of anything, I don't see them as needing extensive hand-holding, I believe they can learn all by themselves.

I do however believe that any hobbyist who wants to learn real embedded needs to get far away from Arduino asap, and even if they're not interested in Forth, at least use GCC, libcm3 ( or whatever) and a editor.

Good for you, but you have an extremely elitist attitude that comes off as very condescending. The advice to use Forth may have been sound in 1987 but I wouldn't put it on my resume today unless I was looking in a very specific niche. I suppose if they want to be a "real" software developer they should get a VAX and learn Cobol?

A hobbyist should use whatever works for them and allows them to build the stuff they want to build and have fun because that's what hobbies are all about. If they want to do "real embedded" they should learn C, it's the language used for embedded micros in every hardware company I've worked at. The hardware platform used for learning it is all but irrelevant, the language is fairly universal. The Arduino platform isn't targeted at professional embedded software developers, it's targeted at hobbyists, casual users and hardware types for whom coding is a means to an end. It's clearly not targeted at you but you shouldn't worry yourself over what others use. It has lowered the barrier of entry and enabled millions of people to get into microcontrollers with a minimal investment. Ultimately it's just another tool in my toolbox, it has its place.

[westfw]

Nothing wrong with newlib, I think?

Well, those used to avr-libc are likely to find it pretty bloated, even in its "nano" form.  And I think newlib is the famous example of "printf() pulls in malloc()" (I mean, it does, but I'm not sure it's the only version that does so...)


Also, lib-gcc for CM0 doesn't have optimized floating point code, so it uses the gcc default "C" version, which is big and slow.

[snarkysparky]

I always want to do bare metal setups.  So far have used SAMD parts.  How do vendors compare regarding data sheet quality ( mostly complete and understandable )  and access to code examples for bare metal setup. 

[nctnico]

Nothing wrong with newlib, I think?

Well, those used to avr-libc are likely to find it pretty bloated, even in its "nano" form.  And I think newlib is the famous example of "printf() pulls in malloc()" (I mean, it does, but I'm not sure it's the only version that does so...)

Newlib is quite bloated indeed. I'm still using the small C library which comes with the MSP430 GCC. I 'ported' (changed the make files) that to ARM about a decade ago.

[Siwastaja]

Bloatness of newlib does not prevent getting started with it if it happens to come as the default with the toolset you can easily download.

Replace it once you hit the limits.

I have never liked using printf() on MCUs. It's quite expensive, and the smaller versions tend to be crippled in some way or another, in which case I want to use simpler functions (itoa et al) which perform as expected, not in some limited way instead. So give me a full-featured, standard-compliant printf I can rely on, when you have the resources for it, otherwise no printf() at all, thanks.

If you are coming from AVR/PIC, especially if you worked with the smaller chips, it's very likely you are not used to using printf() anyway, for the obvious reasons.

I kind of locked to a home-brew class of itoa-like and some other string functions because I wrote them in a pinch due to an extremely stupid problem with newlib which I did not have time to debug properly, then just got so used to them that I still use them. I made them return a pointer to the created zero-termination character, so that strings can be easily appended, a feature not present in standard itoa class of functions.

[snarkysparky]

for debugging i wrote a routing that takes a 16 bit argument and outputs 16 pulses on a digital IO pin as fast as pin toggling allows.

A binary one is two write cycles and a binary zero is one write cycle.  I separate the nibbles by a few off pulses to enable reading the word off the scope.   zero bits are padded with an extra low cycle to keep all the rising edges in the same place.

runs in tens of us on a good processor and doesn't significantly impact other running code.

Only call it when some abnormal value is present usually.