[RFC] Raspberry PI

This forum is dedicated to feedback, discussions about ongoing or future developments, ideas and suggestions regarding the ChibiOS projects are welcome.
User avatar
Giovanni
Site Admin
Posts: 10739
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 306 times
Been thanked: 257 times
Contact:

Re: [RFC] Raspberry PI

Postby Giovanni » Sat Oct 20, 2012 11:09 am

Hi,

I can't say I examined everything accurately but there are some things I notice in my first impact with the code:
- There are wait loops inside ISRs, is this really necessary?
- Peripheral interrupts are disabled and enabled in start() methods, usually those are only enabled there and disabled in stop().
- The device driver in general are incomplete, PAL does not have the initialization of all pins from board.h, PWM does not support callbacks and so on.

As soon I receive my PI I will start including in the mainline the changes required by ARM11, then we will look into device drivers and include them gradually when ready if you agree.

Giovanni

Steve
Posts: 5
Joined: Mon Oct 15, 2012 4:00 pm

Re: [RFC] Raspberry PI

Postby Steve » Mon Oct 22, 2012 2:16 pm

First, I'll warn you that although I'm an experienced programmer this project is a learning experience for me. I'm new to ChibiOS, to embedded programming and to the Raspberry Pi. Therefore it's very possible I haven't made the optimal design decisions in some areas.

> - There are wait loops inside ISRs, is this really necessary?

Are you referring to the checks on RX/TX ready status in the serial driver? I didn't have them and I saw some behavior during my early development that indicated they might be needed but we could try removing them again.

> - Peripheral interrupts are disabled and enabled in start() methods, usually
> those are only enabled there and disabled in stop().

It would be better to discuss specific cases. I had difficulty mapping some of the BCM2835 peripherals to the ChibiOS HAL models. I tried to base the approach I took on existing demonstration and testhal code (and the API documentation) but I could have easily misinterpreted the preferred way to use some of the HAL drivers.

> - The device driver in general are incomplete, PAL does not have the initialization of all pins from
> board.h, PWM does not support callbacks and so on.

The BCM2835 GPIO pins/pads are set to a known state at power up. Do you prefer explicit initialization? Is this needed in some scenarios where you want to reset the board back to power up state without power cycling the board?

The PAL model was one of those that was challenging to map to the BCM2835 because there are no explicit "ports".

It would help me if you can explain the ChibiOS PWM model a bit more. The driver for the BCM2835 drives a GPIO pin with a PWM signal. I wasn't clear to me how callbacks fit into that model.

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

Re: [RFC] Raspberry PI

Postby Giovanni » Mon Oct 22, 2012 3:17 pm

Hi Steve,

Don't worry, you did an excellent work considering it is your first approach to ChibiOS and you were able to make it work, let's approach things gradually. About your points:

Steve wrote:Are you referring to the checks on RX/TX ready status in the serial driver? I didn't have them and I saw some behavior during my early development that indicated they might be needed but we could try removing them again.


Yes those, realtime behavior is the first concern in a RTOS so wait loops into ISRs are a bit warning sign.

Steve wrote:It would be better to discuss specific cases. I had difficulty mapping some of the BCM2835 peripherals to the ChibiOS HAL models. I tried to base the approach I took on existing demonstration and testhal code (and the API documentation) but I could have easily misinterpreted the preferred way to use some of the HAL drivers.


It is very simple, in ChibiOS a driver is only active after xxxStart() and it is disabled after xxxStop(). A stopped driver is assumed to be inactive, see the drivers for other platforms for examples, there is always this pattern:
- In xxxInit() the driver is initialized, *if necessary* the HW state is set to "disabled".
- In xxxStart() the driver HW is initialized and IRQ sources are enabled.
- In xxxStop() the driver HW is de-initialized and IRQ sources are disabled.

This is true for all drivers on all architectures.

Steve wrote:The BCM2835 GPIO pins/pads are set to a known state at power up. Do you prefer explicit initialization? Is this needed in some scenarios where you want to reset the board back to power up state without power cycling the board?


The setup in board.h is meant to bring all pins to a known state after the system is started. In case of the RPI the boot process is "slow" so it is less important but it would still be convenient for the user to configure all pins in board.h and not have to modify them in the application.

Steve wrote:It would help me if you can explain the ChibiOS PWM model a bit more. The driver for the BCM2835 drives a GPIO pin with a PWM signal. I wasn't clear to me how callbacks fit into that model.


It is simple, a callback is invoked every cycle when the output goes active (for all channels) and another is called when the output goes inactive (a separate callback for each channel).

In general it would be a good idea to get one of the supported board (an STM32 Discovery for example) and compare with the behavior with the RPI, a test application written for the STM32 should be portable with minimal changes to the RPI and vice versa.

Giovanni

Steve
Posts: 5
Joined: Mon Oct 15, 2012 4:00 pm

Re: [RFC] Raspberry PI

Postby Steve » Mon Oct 22, 2012 6:05 pm

Hello Giovanni,

Thanks for the quick reply.

... realtime behavior is the first concern in a RTOS so wait loops into ISRs are a bit warning sign.


I understand. I'll remove those and retest my demo and testhal code.


It is very simple, in ChibiOS a driver is only active after xxxStart() and it is disabled after xxxStop(). A stopped driver is assumed to be inactive, see the drivers for other platforms for examples, there is always this pattern:
- In xxxInit() the driver is initialized, *if necessary* the HW state is set to "disabled".
- In xxxStart() the driver HW is initialized and IRQ sources are enabled.
- In xxxStop() the driver HW is de-initialized and IRQ sources are disabled.

This is true for all drivers on all architectures.


The SPI driver model supports both interrupt-driven and polled operation depending on the specific API function that is called. I was thinking the interrupts should only be enabled for the asynchronous calls since otherwise it would interfere with polled SPI access.

The setup in board.h is meant to bring all pins to a known state after the system is started. In case of the RPI the boot process is "slow" so it is less important but it would still be convenient for the user to configure all pins in board.h and not have to modify them in the application.


I'm assuming the settings in board.h would be application-independent. Is that correct? The RPI pins are all set to input (no pullup/pulldown) at start time. When would the board.h configurations be different? Wouldn't a specific application still need to configure any application-specific, non-default, use of the GPIO pins?

(Re: PWM callbacks) It is simple, a callback is invoked every cycle when the output goes active (for all channels) and another is called when the output goes inactive (a separate callback for each channel).


Hmmm. I'm not sure that the RPI PWM peripheral generates these types of interrupts, but I'll investigate further. I saw in the STM32 demo that the PWM callbacks are being used to trigger ADC sampling. On the RPI, most people are using PWM for purposes like controlling LED brightness or servo positioning versus triggering interrupts.

In general it would be a good idea to get one of the supported board (an STM32 Discovery for example) and compare with the behavior with the RPI, a test application written for the STM32 should be portable with minimal changes to the RPI and vice versa.


I've ordered an STM32 Discovery for comparison. However, I suspect the available RPI peripherals might not allow me to directly compare the demo programs (the RPI doesn't have onboard ADC or RTC, for example).

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

Re: [RFC] Raspberry PI

Postby Giovanni » Mon Oct 22, 2012 6:18 pm

Hi,

Steve wrote:The SPI driver model supports both interrupt-driven and polled operation depending on the specific API function that is called. I was thinking the interrupts should only be enabled for the asynchronous calls since otherwise it would interfere with polled SPI access.


The high level driver does a state check before calling the low level driver using an assertion so it is not possible to make a polled operation if an asynchronous operation is ongoing. The handling of the ISR during the polled phase is implementation dependent.

Steve wrote:I'm assuming the settings in board.h would be application-independent. Is that correct? The RPI pins are all set to input (no pullup/pulldown) at start time. When would the board.h configurations be different? Wouldn't a specific application still need to configure any application-specific, non-default, use of the GPIO pins?


Floating inputs are *bad* because RFI and power consumption, leaving the port in that state is a bad idea. In general unused pins should be outputs or inputs with pull-up/down, the default settings in board.h help with this.

Steve wrote:Hmmm. I'm not sure that the RPI PWM peripheral generates these types of interrupts, but I'll investigate further. I saw in the STM32 demo that the PWM callbacks are being used to trigger ADC sampling. On the RPI, most people are using PWM for purposes like controlling LED brightness or servo positioning versus triggering interrupts.


If the device does not support interrups on the PWM then it is acceptable to simply do not do that. Callbacks are not required in all applications anyway.

Steve wrote:I've ordered an STM32 Discovery for comparison. However, I suspect the available RPI peripherals might not allow me to directly compare the demo programs (the RPI doesn't have onboard ADC or RTC, for example).


No RTC? how system time is kept?

Giovanni

Steve
Posts: 5
Joined: Mon Oct 15, 2012 4:00 pm

Re: [RFC] Raspberry PI

Postby Steve » Mon Oct 22, 2012 9:47 pm

Floating inputs are *bad* because RFI and power consumption, leaving the port in that state is a bad idea. In general unused pins should be outputs or inputs with pull-up/down, the default settings in board.h help with this.


Yeah, I mispoke (miswrote) there. The peripheral reference manual says the pins revert to the default input mode (pullup or pulldown) at reset. The default is not clear. Apparently if a pullup or pulldown is configured it will still be in that state after reset. There's no way to query the current state. Given the ambiguity, I agree even more that it's a good idea to put defaults in the board.h file. Do you have a preference for the default pin modes?

No RTC? how system time is kept?


With Linux, the system time is expected to be set over the network (typically using a time server). I have an example of using a DS1307 I2C RTC for ChibiOS or bare metal applications.

rvanspaa
Posts: 11
Joined: Mon Apr 24, 2017 7:51 am

Re: [RFC] Raspberry PI

Postby rvanspaa » Mon May 22, 2017 6:33 am

Hi Giovani,

Is there now an official "home" for the RPi port?
I have partially updated Steves, 2.5.1 port to 3.0.3. It is more stable and things work somewhat better. e.g.
1) Each interrupt can now be handled independently.
2) The wait loop in the serial IO input interrupt is no longer needed.

I also added a while loop to the serial IO output interrupt, so that the FIFO could be loaded, thus ensuring that more than 1 byte was output per interrupt.
However I haven't even looked at most of the other IO related things, though I have added a GPIO interrupt handler.

I was quite disappointed to note that test performance is roughly comparable to that of a 72 MHz STM32F103, despite the fact that the RPi supposedly runs at 10 times the speed. See attached test report (run with clock set to 800 MHz, on a RPi B+).

Do you have any idea why this might be so? Also, are there any test results from any processors run with versions of ChibiOS > 2.4?
Attachments
RPi_test.zip
(1.18 KiB) Downloaded 22 times

rvanspaa
Posts: 11
Joined: Mon Apr 24, 2017 7:51 am

Re: [RFC] Raspberry PI

Postby rvanspaa » Mon May 22, 2017 6:36 am

Hi Giovanni,

Apologies for misspelling your name. :oops:

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

Re: [RFC] Raspberry PI

Postby Giovanni » Mon May 22, 2017 7:36 am

Hi,

You can edit posts, no problem anyway.

I believe the home is here: http://www.stevebate.net/chibios-rpi/Ge ... arted.html

Giovanni

rvanspaa
Posts: 11
Joined: Mon Apr 24, 2017 7:51 am

Re: [RFC] Raspberry PI

Postby rvanspaa » Mon May 22, 2017 10:48 pm

Hi Giovanni,

Actually I meant does it have a home under ChibiOS, but apparently not. Back in 2012 you seemed to be interested in the RPi, but not any more?


Return to “Development and Feedback”

Who is online

Users browsing this forum: No registered users and 5 guests