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
[RFC] Raspberry PI
- Giovanni
- Site Admin
- Posts: 14457
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: [RFC] Raspberry PI
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.
> - 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.
- Giovanni
- Site Admin
- Posts: 14457
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: [RFC] Raspberry PI
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:
Yes those, realtime behavior is the first concern in a RTOS so wait loops into ISRs are a bit warning sign.
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 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.
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
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
Re: [RFC] Raspberry PI
Hello Giovanni,
Thanks for the quick reply.
I understand. I'll remove those and retest my demo and testhal code.
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.
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?
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.
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).
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).
- Giovanni
- Site Admin
- Posts: 14457
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: [RFC] Raspberry PI
Hi,
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.
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.
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.
No RTC? how system time is kept?
Giovanni
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
Re: [RFC] Raspberry PI
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.
Re: [RFC] Raspberry PI
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?
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 210 times
- Giovanni
- Site Admin
- Posts: 14457
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: [RFC] Raspberry PI
Hi,
You can edit posts, no problem anyway.
I believe the home is here: http://www.stevebate.net/chibios-rpi/Ge ... arted.html
Giovanni
You can edit posts, no problem anyway.
I believe the home is here: http://www.stevebate.net/chibios-rpi/Ge ... arted.html
Giovanni
Re: [RFC] Raspberry PI
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?
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 51 guests