What interrupts occur in core SW?

Projects Programming
1

In my sketch on a Due there is a loop polling for a flag. When the flag is detected data are read from a port.

The problem is that sometimes data are missed. When all interrupts are blocked then all data are read correctly, i.e. interrupts are the reason for missing data.

I know that there is at least one timer interrupt for the functions millis() and micros(). In my application there is no problem to block these timer interrupts for some short time during the polling loop. But I'd like to use interrupts in my application too.

Therefore I need to know what interrupts will be generated by the core software. Then I can block only those interrupts and enable my interrupts.

Can somebody give me this information or tell me where to find it?

2

The Arduino core for the MCU is the place to look. All the serial I/O routines (UART, SPI and I2C) use interrupts, for example.

3

Additionally, as usual, Gammon weighed in usefully:

1 Like
4

There doesn't seem to be any easy way to find this.

  1. Search the Due core source code for a declaration of a function called xxx_Handler, that matches one of the names defined in cortex_handlers.c That file defines the default handlers for all interrupts that could be called, but can be overridden.

  2. Examine the linker map file to see what functions are linked in. Again you would need to search for xxx_Handler that are not in cortex_handlers.c. e.g.

 .text.UART_Handler
                0x00080150        0xc C:\Users\bobco\AppData\Local\Temp\arduino\sketches\AED66CCE1947D2B49A175637FCB81549\core\variant.cpp.o
                0x00080150                UART_Handler

Shows that UART_Handler is defined in variant_cpp.

It would be relatively easy to write a script to scan the map file and list out interrupt handlers.

5

This sounds like an XY problem. Give a better description of what you are trying to do and show the problem code. There is probably a better solution to your problem other than screwing with interrupts. Messing with interrupts is seldom the right answer to code problems.

1 Like
6

What kind of "port"?

7

The frequency that poll loop is run ... once per void loop() cycle?

How you are polling I don't know if with the Due can be sped up but with AVR-duinos we can read the port PINx register directly 5x faster than using digitalRead() which has noob-safe code written in that slows it down.

Your flag signals, how many do you poll and how fast do they change? A fast void loop on an Uno can keep up with 50+ KHz, and the Due is 6x faster.

8

Time to show us your code.

9

There are several questions in this sequence of posts I will answer.

The background of my question is my project for a stateanalyzer on a Due.
Of course I want to achieve a sampling frequency as fast as possible. The final solution is a loop in assembler. I had some questions to it in another post. The answers there helped me a lot. With this approach I achieved 4 to 5 MHz sampling rate.

Now your questions:

Messing with interrupts is seldom the right answer to code problems.

I agree, I found a better solution. The reason asking for interrupts in the core SW was my first idea to solve a timeout test with a timer which should generate an interrupt on timeout. My solution now: on timeout the timer will set a pin (TIOB2) to high which is checked in the assembler loop.

What kind of "port"?

It is port C (PIOC) on the Due.

Your flag signals, how many do you poll and how fast do they change? A fast void loop on an Uno can keep up with 50+ KHz, and the Due is 6x faster.

As mentioned above I can achieve polling/sampling with 4 to 5 MHz, depending what else actions are included (flag for measuring sampling rate, error check, etc.).

BTW, meantime I found a controller type with a parallel camera interface capable of up to 50 MHz sampling rate (e.g. STM32F407).
But I made a shield for the Due including some further functions (signal generator, frequency counter, oscilloscope) and I don't like to develop a new shield.

10

Some of those questions were not mine but I wondered.

I can't say it'd be all you want but the Teensy 4.1 for near $30:

  • ARM Cortex-M7 at 600 MHz
  • Float point math unit, 64 & 32 bits
  • 7936K Flash, 1024K RAM (512K tightly coupled), 4K EEPROM (emulated)
  • QSPI memory expansion, locations for 2 extra RAM or Flash chips
  • USB device 480 Mbit/sec & USB host 480 Mbit/sec
  • 55 digital input/output pins, 35 PWM output pins
  • 18 analog input pins
  • 8 serial, 3 SPI, 3 I2C ports
  • 2 I2S/TDM and 1 S/PDIF digital audio port
  • 3 CAN Bus (1 with CAN FD)
  • 1 SDIO (4 bit) native SD Card port
  • Ethernet 10/100 Mbit with DP83825 PHY
  • 32 general purpose DMA channels
  • Cryptographic Acceleration & Random Number Generator
  • RTC for date/time
  • Programmable FlexIO
  • Pixel Processing Pipeline
  • Peripheral cross triggering
  • Power On/Off management

is very small.

Arduino friendly compatible Teensy 4.1

The 4.0 is smaller with fewer features but still has the 600MHz M7 with FPU for around $20.

PJRC made the Teensy 2.0 before Arduino made the Leonardo and Micro. They were first with USB AVR's, Paul's software is what the Leonardo and Micro used -- PJRC discontinued the 2.0's and AFAIK Arduino discontinued the Micro and Leo but it's all Open Source, you can get clones from many sellers.

Google: buy teensy++ 2.0
The ++ has 8K RAM and USB, breadboard & beginner friendly.

11

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.