[PATCH] AVR EXT Topic is solved

ChibiOS public support forum for topics related to the Atmel AVR family of micro-controllers.

Moderators: utzig, tfAteba

User avatar
tfAteba
Posts: 547
Joined: Fri Oct 16, 2015 11:03 pm
Location: Strasbourg, France
Has thanked: 91 times
Been thanked: 48 times

Re: [PATCH] AVR EXT

Postby tfAteba » Wed Aug 02, 2017 10:46 am

Hi MGeo,

MGeo wrote:
I see that hal_ext_lld.c has major changes. It looks like PCINTx support is removed from EXT for now?

Yes, that what I did, for the moment, I removed the PCINTx support because all conflicts added by PCINTx support.
I will reumplement this PCINTx driver later.

MGeo wrote:
much easier to follow

:D yes, it is one of my goal when writing code.

MGeo wrote:
A quick check with simulator looks much better. I'll continue testing and report back.

Nice to hear that, I will be happy to have your feedback.
regards,

Theo.

MGeo
Posts: 22
Joined: Wed Jul 26, 2017 12:05 pm
Been thanked: 4 times

Re: [PATCH] AVR EXT

Postby MGeo » Wed Aug 09, 2017 10:58 am

Hi Theo,

I got a chance to work with the EXT driver, using single and multiple active interrupts in my tests. My goals here are to learn how to apply Chibios and understand how HAL works and is applied. I also want to get a feel for interrupt latency under an RTOS on AVR.

I modified testhal EXT example to activate multiple interrupts (INT0 and INT4 in this case). I wired up my incoming 115200 serial stream to both INT0 and INT4 pins on my Arduino Mega board. I've included the modified example files used for this test in the attached ZIP.

Test results look to be as expected, logic analyzer screen cap is included below to show latencies. In this case, serial stream is on analyzer Channel 0, INT4 is on analyzer Channel 1, and INT0 is on analyzer Channel 2. With both pins seeing the same serial stream, INT0 gets serviced first with about 4.25 uS of latency, followed by INT4 with about 13.8 uS of latency. Not too bad I think.

Thanks,
George
Attachments
EXT.zip
(14.33 KiB) Downloaded 253 times
cap5_init_EXT0_and_EXT4.png

User avatar
tfAteba
Posts: 547
Joined: Fri Oct 16, 2015 11:03 pm
Location: Strasbourg, France
Has thanked: 91 times
Been thanked: 48 times

Re: [PATCH] AVR EXT

Postby tfAteba » Wed Aug 09, 2017 8:49 pm

Hello MGeo,

Thank you for your analyses and your feedback with all tests you made with the EXT driver.

Happy to see that all your tests went well.
regards,

Theo.

MGeo
Posts: 22
Joined: Wed Jul 26, 2017 12:05 pm
Been thanked: 4 times

Re: [PATCH] AVR EXT

Postby MGeo » Wed Aug 16, 2017 11:18 am

I wanted to see how Chibios interrupt latencies compare with bare metal latencies. Chibios must save additional state info as part of interrupt servicing, I wanted to measure this impact.

I used the same Arduino Mega test setup as was used in the post above. along with the sketch below.

The logic analyzer screen cap is included below to show bare metal latencies. With both pins seeing the same serial stream, INT0 gets serviced first with about 1.33 uS of latency, followed by INT4 with about 4.58 uS of latency.

Code: Select all

#include <digitalWriteFast.h>

volatile static int isrCpt0; /**< Interrupt 0 counter. */
volatile static int isrCpt4; /**< Interrupt 4 counter. */

#define PORTB_PIN5_D11 11
#define PORTB_PIN6_D12 12


ISR(INT0_vect) {
  digitalWriteFast(PORTB_PIN5_D11, HIGH);
  isrCpt0++;
  digitalWriteFast(PORTB_PIN5_D11, LOW);
}// Interrupt Service Routine (ISR)


ISR(INT4_vect) {
  digitalWriteFast(PORTB_PIN6_D12, HIGH);
  isrCpt4++;
  digitalWriteFast(PORTB_PIN6_D12, LOW);
}


void setup () {

  pinModeFast(LED_BUILTIN, OUTPUT);  // so we can update the LED
  digitalWriteFast(LED_BUILTIN, LOW);

  pinModeFast(PORTB_PIN5_D11, OUTPUT);  // so we can update the LED
  digitalWriteFast(PORTB_PIN5_D11, LOW);
 
  pinModeFast(PORTB_PIN6_D12, OUTPUT);  // so we can update the LED
  digitalWriteFast(PORTB_PIN6_D12, LOW);

  Serial.begin(115200);

  cli ();                                 // clear interrupts flag

  EICRA &= ~((1 << ISC00) | (1 << ISC01));  // clear existing flags
  EICRA |= (1 << ISC01);                    // set wanted flags (falling level interrupt)

  EICRB &= ~((1 << ISC40) | (1 << ISC41));  // clear existing flags
  EICRB |= (1 << ISC41);                    // set wanted flags (falling level interrupt)

  EIMSK |= ((1 << INT4) | (1 << INT0));     // enable it

  sei ();                                   // set interrupts flag
 
}
Attachments
cap6_init_EXT0_and_EXT4.png

User avatar
tfAteba
Posts: 547
Joined: Fri Oct 16, 2015 11:03 pm
Location: Strasbourg, France
Has thanked: 91 times
Been thanked: 48 times

Re: [PATCH] AVR EXT

Postby tfAteba » Wed Aug 16, 2017 12:41 pm

Hi MGeo,

It is normal to have such result, in RTOS program, you have more context switch to do compare to a bare-metal program.

I think this result is good for me, but it really depend on response time needed by your application ;)

Any way, thanks for showing us the difference between the two concept :)
regards,

Theo.

User avatar
Giovanni
Site Admin
Posts: 14444
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 1074 times
Been thanked: 921 times
Contact:

Re: [PATCH] AVR EXT

Postby Giovanni » Wed Aug 16, 2017 2:07 pm

The RTOS has to perform a reschedule check after each ISR, there is some overhead even without reschedule.

Note that you can write plain ISRs without putting any RTOS code inside, no overhead in that case.

Giovanni

MGeo
Posts: 22
Joined: Wed Jul 26, 2017 12:05 pm
Been thanked: 4 times

Re: [PATCH] AVR EXT

Postby MGeo » Sun Aug 20, 2017 12:28 am

Thanks Theo, Giovanni.

I think I am starting to understand the external interrupt interface thanks to your help.

My learning application is a flight controller with an IMU (3 axis gyro plus 3 axis accelerometer) for stabilization and a serial interface RC receiver for command inputs from a pilot. The IMU (an Invensense MPU-6050 https://www.invensense.com/products/mot ... /mpu-6050/ or MPU-9250 https://www.invensense.com/products/mot ... /mpu-9250/) is programmed for self-clocking, providing readings and an external data ready interrupt signal at between a planned programmable rate between 200 and 1000 Hz. The serial stream from the pilot comes via TTL serial input, at 115.2kbps with 16 byte data payload arriving every 22 msec assuming a good signal. The processor I'm starting with is an AVR ATMega644PA at 20 MHz, but I am also looking at moving up to an STM32F3 or F4 once the application is up and running. Ideally my same code base can support both AVR and STM32 targets but we shall see. I've included a simple block diagram showing interfaces.

I think I can get away with Serial interface module in Chibios, and use EXT to handle the IMU data ready interrupts. These data ready interrupts will be used to trigger a synchronous PID control loop. Serial input and IMU data timings are independent of each other.

My question is regarding external interrupts to sync the PID loop to the gyro data. If I only plan to set a semaphore that will trigger a synchronous PID calculation loop thread, can I get away with a faster 'bare metal' ISR or is a full context save Chibios ISR needed? I suspect the later but it would be good to understand why, and when it might be ok to 'cheat' and make do with a faster bare metal ISR?

Thanks,
George
Attachments
Interfaces.JPG

User avatar
tfAteba
Posts: 547
Joined: Fri Oct 16, 2015 11:03 pm
Location: Strasbourg, France
Has thanked: 91 times
Been thanked: 48 times

Re: [PATCH] AVR EXT

Postby tfAteba » Sun Aug 20, 2017 10:56 am

Hi MGeo,

MGeo wrote:
My question is regarding external interrupts to sync the PID loop to the gyro data. If I only plan to set a semaphore that will trigger a synchronous PID calculation loop thread, can I get away with a faster 'bare metal' ISR or is a full context save Chibios ISR needed? I suspect the later but it would be good to understand why, and when it might be ok to 'cheat' and make do with a faster bare metal ISR?


Sorry I'm a bit confuse with your question can you make it simple so that I can understand what you need??

Thanks.
regards,

Theo.

User avatar
tfAteba
Posts: 547
Joined: Fri Oct 16, 2015 11:03 pm
Location: Strasbourg, France
Has thanked: 91 times
Been thanked: 48 times

Re: [PATCH] AVR EXT

Postby tfAteba » Sun Aug 20, 2017 11:29 am

MGeo,

Good project, it remember me one of my project too :) , my self-balancing robot. You can find information about it here: http://www.chibios.com/forum/viewtopic.php?f=8&t=3721&p=30323#p30323

For what I have understand, you want to use an external interrupt generated by the MPU6050, to have IMU data. You have to know the frequency at which MPU6050 will trigger an interruption and see if you will have the time to (get the phone PID data + compute the PID asserv + Apply the PID result to the Spectrum). I think it will depend on this period.

In my case, I used another method. MPU make measurement often, and just when I need data, I asked them trough the I2C interface then I can have all the time to compute data (kalman filter + PID + apply it to the Motor). In my side, to make an asserv of the robot, I need to respect a period of 10ms.

As I told you, please clearly ask you question so that I can help ;)
Thanks.
regards,

Theo.

MGeo
Posts: 22
Joined: Wed Jul 26, 2017 12:05 pm
Been thanked: 4 times

Re: [PATCH] AVR EXT

Postby MGeo » Sun Aug 20, 2017 12:34 pm

tfAteba wrote:For what I have understand, you want to use an external interrupt generated by the MPU6050, to have IMU data. You have to know the frequency at which MPU6050 will trigger an interruption and see if you will have the time to (get the phone PID data + compute the PID asserv + Apply the PID result to the Spectrum). I think it will depend on this period.


This is the correct interpretation (except Spektrum receiver provides the input commands from user, outputs go to servos or motors). MPU can be configured to sample sensors at a user defined frequency (from about 4Hz all the way up to 8KHz) by programming the SMPLRT_DIV register.

The higher the sampling rate the higher the PID loop bandwidth. I plan to adjust this frequency (period) to match what the processor can keep up with.

In my case the MPU6050 will also be configured to provide provide a hardware Data Ready Interrupt when new sensor values are available to be read by the processor. (DATA_RDY_EN bit in INT_ENABLE register. When set to 1, this bit enables the Data Ready interrupt).

George


Return to “AVR Support”

Who is online

Users browsing this forum: No registered users and 4 guests