Is there an interrupt that fires when serialAvailable() goes true?

Exactly.

1 Like

Oh, sorry, that wasn't clear to me.

Like something is hidden in a book? It remains a secret until you open the book and start reading. The Arduino firmware and controller data sheets are accessible to everybody, you only have to read and learn.

1 Like

In English Engineering Idiom, to say that something is a "Black Box" means that "you can't see inside to tell how it works." The Arduino may be a magic box, but it's not black...

Really, it's difficult to be more transparent than having open source code and open source electronic circuit and using components which have enough documentation available to clobber a buffalo to death with. Seriously, even the Atmega 328 at the core of the Uno has more documentation available than anybody would ever want to read.

I have used the ESP32's API to do the serial thingy under the Arduino IDE.

https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/peripherals/uart.html

A little snippet from the ESP32's UART API about using interrupts:

Using Interrupts
There are many interrupts that can be generated following specific UART states or detected errors. The full list of available interrupts is provided in ESP32 Technical Reference Manual > UART Controller (UART) > UART Interrupts and UHCI Interrupts [PDF]. You can enable or disable specific interrupts by calling uart_enable_intr_mask() or uart_disable_intr_mask() respectively.

The uart_driver_install() function installs the driver’s internal interrupt handler to manage the Tx and Rx ring buffers and provides high-level API functions like events (see below).

The API provides a convenient way to handle specific interrupts discussed in this document by wrapping them into dedicated functions:

Event detection: There are several events defined in uart_event_type_t that may be reported to a user application using the FreeRTOS queue functionality. You can enable this functionality when calling uart_driver_install() described in Driver Installation. An example of using Event detection can be found in peripherals/uart/uart_events.

FIFO space threshold or transmission timeout reached: The Tx and Rx FIFO buffers can trigger an interrupt when they are filled with a specific number of characters, or on a timeout of sending or receiving data. To use these interrupts, do the following:

Configure respective threshold values of the buffer length and timeout by entering them in the structure uart_intr_config_t and calling uart_intr_config()

Enable the interrupts using the functions uart_enable_tx_intr() and uart_enable_rx_intr()

Disable these interrupts using the corresponding functions uart_disable_tx_intr() or uart_disable_rx_intr()

Pattern detection: An interrupt triggered on detecting a ā€˜pattern’ of the same character being received/sent repeatedly for a number of times. This functionality is demonstrated in the example peripherals/uart/uart_events. It can be used, e.g., to detect a command string followed by a specific number of identical characters (the ā€˜pattern’) added at the end of the comma

I like being able to define buffer size

int BUF_SIZE = 1024;

  uart_driver_install( UART_NUM_1, BUF_SIZE * 2, 0, 0, NULL, ESP_INTR_FLAG_IRAM );

It's the old catch-22, an interrupt can respond without polling. But then normally you have to poll the results or state of the ISR anyway. So no gain.

Well, you know what they say: "pain but no gain". Or was it the other way round?

Thats part of the problem, it's like trying to drink from a firehose and without reading ALL of it a noob doesn't really have a map to give the big picture.
I must say tho that the online docs for the language sometimes are obscure and more examples would help.
Searching for simple command examples will turn up one Reference hit and 500 project hits, none of which seem to be on point. Maybe I just don't know how to use the docs effectively. But searching for string vs String vs \0 char array leads in circles at the top level with little depth.

1 Like

That's more of a C++ issue than it is an Arduino issue, and a lot of it has to do with the history of C and C++. I agree, a lot of this stuff is obtuse to someone just starting to get into it.

I like the top level of code to deal with messages and the IRQ handle character concatenation into messages. One of the messages said the API has the ability to fire an interrupt when a repeat character count is reached. This is the EOM detection I was chatting about earlier. It was said that the system couldn't do EOM, but appearently, it can. I learned something new.

Incidentally, I did that several years ago. I just added the MIT license to it so others can use it freely. Check it out if you want: GitHub - abbrev/uartty: UART library for AVR microcontrollers.

In face-to-face class room, it is really hard to convince the pupils that those eight steps (post #77) are embedded in this single line command (unsigned int y = analogRead(A4);); finally, they get convinced having done parallel experiments in Register Level Codes and Arduino Level Codes and come up with the voice -- Arduino is indeed a Black Magic Box!

My Arduino came in a golden box entitled The Arduino Starter Kit and its content was not magic :slight_smile:

So everybody can have an Arduino Box and find out whether it's magic or science.

I see my all Arduino stuff as packed up in an Engineering Tool Box. The Magic comes up when I write pinMode(2, INPUT_PULLUP); and the internal pull-up resistor is automatically connected (Fig-1).

Should the Arduino be absenting, I (we) would have the opportunity to know the Science of how the internal pull-up gets connected with DPin-2 (typical example, Fig-1). Arduino has made my (our) Programming Life enjoyable as I (we) can still do something without knowing many things -- a great paradigm of "Learning".


Figure-1:
The pinMode(2, INPUT_PULLUP); instruction is the single line version of the following three lines:

bitWrite(DDRD, DDRD2, LOW);   
bitWrite(PORTD, PORTD2, HIGH);
bitWrite(MCUCR, PUD, LOW);

Did you miss that such functions are required for controller independent pin configuration? The lines you mention are for some controllers only. It's not magic, it's a tool.

Do you want to be admired as an outstanding magic wizard for your knowledge about hardware and software? Then of course you have to obfuscate to your audience as magic what other people can explain instead.

Yes! pinMode() function is independent of MCU architecture; whereas, the bitWrite() functions are not.

Not at all! Everybody collects information from the data sheets and then present in their own ways -- good or bad?

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