Skip to content

Add RP2040 support #341

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 9 commits into from
Jun 30, 2021
Merged

Add RP2040 support #341

merged 9 commits into from
Jun 30, 2021

Conversation

kilograham
Copy link
Contributor

Adds support for RP2040 using the Raspberry Pi Pico SDK. FreeRTOS can be run on either core. SDK semaphores, queues, mutexes, and sleep functions can be used freely to/from FreeRTOS tasks and can be used to interact with code running on the other RP2040 core.

The entirety of this change is located within the RP2040 port except for the new portSTACK_LIMIT_PADDING define (which is only used by stack overflow checking). This is added to allow a port to keep extra state for the switched out task below the normal "top" of stack location. This allows extra information to be saved on the stack without disrupting a debuggers ability to parse the stack frame.

@kilograham kilograham requested a review from a team as a code owner June 2, 2021 16:47
@kilograham kilograham mentioned this pull request Jun 2, 2021
@codecov
Copy link

codecov bot commented Jun 4, 2021

Codecov Report

Merging #341 (81af7b2) into main (4200226) will not change coverage.
The diff coverage is n/a.

Impacted file tree graph

@@           Coverage Diff           @@
##             main     #341   +/-   ##
=======================================
  Coverage   92.13%   92.13%           
=======================================
  Files           4        4           
  Lines        1272     1272           
  Branches      342      342           
=======================================
  Hits         1172     1172           
  Misses         53       53           
  Partials       47       47           
Flag Coverage Δ
unittests 92.13% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.


Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 4200226...81af7b2. Read the comment docs.

FREE_RTOS_KERNEL_SMP=0
)

add_library(FreeRTOS-Kernel-Static INTERFACE)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Similar to my comments regarding selecting a heap implementation, perhaps you could include idle_task_static_memory.c if configSUPPORT_STATIC_ALLOCATION is set.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

configSUPPORT_STATIC_ALLOCATION is a preprocessor define not a build time definition. This library (perhaps poorly named) was intended as a utility library the user could add to get a basic definition of static defines. Basically we prefer adding a library dependency on an INTERFACE library to pull in code rather than explicitly adding source files.

That said, if this code is indeed generic, and useful for all configSUPPORT_STATIC_ALLOCATION=1, we could add the source file, but then guard the code

pico_base_headers
hardware_exception)

target_compile_definitions(FreeRTOS-Kernel INTERFACE
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you comment on your choice of INTERFACE rather than STATIC for the library definition?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All libraries within the Raspberry Pi Pico SDK build as INTERFACE libraries to gather build options/configuration settings on a per target binary basis. i.e. there may be multiple target executables in a single cmake build that use differently configured FreeRTOS and or SDK settings

@@ -0,0 +1,67 @@
# Called after the Raspberry Pi Pico SDK has been initialized to add our libraries
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This file should have a copyright and SPDX identifier.


add_library(FreeRTOS-Kernel INTERFACE)
target_sources(FreeRTOS-Kernel INTERFACE
${CMAKE_CURRENT_LIST_DIR}/port.c
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should probably be named something port specific.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah i mean the namespace is what the user build has included. i.e. they chose to include the RP2040 port of FreeRTOS. We would need a more specific name if installed, but I think that could be handled by namespacing during the packaging step (we don't use system installed libraries yet with the SDK)

@@ -0,0 +1,62 @@
# This is a copy of <PICO_SDK_PATH>/external/pico_sdk_import.cmake
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If included, this file should have a copyright statement and SPDX identifier.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is that so? the build checks said it wasn't a requirement. That said i don't mind adding one; it is just a verbatim copy of an intended-use-is-copying-to-your-project file from the SDK which doesn't have a copyright notice


#include "FreeRTOS.h"

void vApplicationGetIdleTaskMemory( StaticTask_t **ppxIdleTaskTCBBuffer,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is supposed to be supplied by the application. Any specific reason of providing it as part of port?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We are providing it as an example/convenience.. it is just an easier way for the user to include it than copying/pasting.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is a stylistic decision for consistency with other Raspberry Pi Pico SDK software use

#define xPortSysTickHandler isr_systick
#endif

#define portCHECK_IF_IN_ISR() ({ \
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Other ports do it this way: https://github.com/FreeRTOS/FreeRTOS-Kernel/blob/main/portable/GCC/ARM_CM4F/portmacro.h#L172

You may want to do the same for consistency.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i think it is fine... achieves the same thing

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i can change it if you feel strongly.

#if ( ( configCHECK_FOR_STACK_OVERFLOW == 1 ) && ( portSTACK_GROWTH < 0 ) )

/* Only the current stack state is to be checked. */
#define taskCHECK_FOR_STACK_OVERFLOW() \
{ \
/* Is the currently saved stack pointer within the stack limit? */ \
if( pxCurrentTCB->pxTopOfStack <= pxCurrentTCB->pxStack ) \
if( pxCurrentTCB->pxTopOfStack <= pxCurrentTCB->pxStack + portSTACK_LIMIT_PADDING) \
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The PendSV handler does not save the SP with extra words 4 in TCB - so this check would not do detect the boundary overflow you are trying to detect? Therefore, I suggest that we remove this common change.

Copy link
Contributor Author

@kilograham kilograham Jun 30, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can you clarify why this doesn't detect anything?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i mean the point is that the value saved does not include the extra words, which is why it is checked here... if you save a different pointer in the TCB then it breaks the ability to debug with openocd etc.

Note that this is the only piece of code I found that actually cared whether there was something below pxTopOfStack

@n9wxu n9wxu merged commit 9af72db into FreeRTOS:main Jun 30, 2021
kilograham added a commit to kilograham/FreeRTOS-Kernel that referenced this pull request Jun 30, 2021
* Add RP2040 support

* remove spurious tab/spaces comments

* add .cmake to ignored kernel checks

* Apply suggestions from code review

Co-authored-by: Paul Bartell <[email protected]>

* license and end of file newline fixes

* Rename LICENSE.TXT to LICENSE.md

Co-authored-by: Paul Bartell <[email protected]>
Co-authored-by: Gaurav-Aggarwal-AWS <[email protected]>
aggarg added a commit that referenced this pull request Jul 6, 2021
* Add RP2040 support (#341)

* Add RP2040 support

* remove spurious tab/spaces comments

* add .cmake to ignored kernel checks

* Apply suggestions from code review

Co-authored-by: Paul Bartell <[email protected]>

* license and end of file newline fixes

* Rename LICENSE.TXT to LICENSE.md

Co-authored-by: Paul Bartell <[email protected]>
Co-authored-by: Gaurav-Aggarwal-AWS <[email protected]>

* RP2040 updates for SMP

* whitepsace fix

Co-authored-by: Gaurav-Aggarwal-AWS <[email protected]>

* whitespace fix

Co-authored-by: Gaurav-Aggarwal-AWS <[email protected]>

Co-authored-by: Paul Bartell <[email protected]>
Co-authored-by: Gaurav-Aggarwal-AWS <[email protected]>
laroche pushed a commit to laroche/FreeRTOS-Kernel that referenced this pull request Apr 18, 2024
* Port shadow demo from product 4

* Fix coding style and formating

* Change assert to configASSERT and fix comments.

* Delete the demo task when it finish

* Relocate the shadow demo code under AWS folder.

* Fix uncrustify.

* Update FreeRTOS-Plus/Demo/AWS/Device_Shadow_Windows_Simulator/Device_Shadow_Demo/DemoTasks/ShadowDemoMainExample.c

Co-authored-by: Oscar Michael Abrina <[email protected]>

* Update FreeRTOS-Plus/Demo/AWS/Device_Shadow_Windows_Simulator/Device_Shadow_Demo/DemoTasks/ShadowDemoMainExample.c

Co-authored-by: Oscar Michael Abrina <[email protected]>

* Fix comments

* Update from comments.

Co-authored-by: Oscar Michael Abrina <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants