Skip to content
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

[chibios] Add support for a full ChibiOS arch #1699

Merged
merged 14 commits into from
Jun 7, 2016
Merged

Conversation

gautierhattenberger
Copy link
Member

This is replacing the previous mix chibios/libopencm3:

  • all drivers are ported to the new arch
  • it was hard to go forward and take advantages of the RTOS, now it is much easier
  • switch to v3 of ChibiOS
  • for now, it is functionaly the same than before
  • the previous variable length array mechanism used internaly by the
    sdlog is replaced by a more efficient library called TLSF (allow
    constant time malloc/free)

It also comes as a replacement of the rt_chibios branch (https://github.com/paparazzi/paparazzi/tree/rt_chibios) and the pull request #1504 (although the approach is different)

This is replacing the previous mix chibios/libopencm3:
- all drivers are ported to the new arch
- it was hard to go forward and take advantages of the RTOS, now it is much easier
- switch to v3 of ChibiOS
- for now, it is functionaly the same than before
- the previous variable length array mechanism used internaly by the
  sdlog is replaced by a more efficient library called TLSF (allow
  constant time malloc/free)
@podhrmic
Copy link
Member

podhrmic commented Jun 2, 2016

Cool, that is exciting! From looking at it the commit, it doesn't add the arch/chibios dir - is that something that you don't need for the sdlogger?

@gautierhattenberger
Copy link
Member Author

@podhrmic Thanks, I didn't even realized that all the new files were missing from the commit

@podhrmic
Copy link
Member

podhrmic commented Jun 2, 2016

@gautierhattenberger looking at the driver implementation - you have threads for IO, and then running the whole autopilot in one thread (which is the different approach). But this would mean locking us to using ChibiOS this hybrid way, instead of using the full potential of multithreading (or haivng a choice):-/ I still think there is a better solution - are you willing to wait with this?

@gautierhattenberger
Copy link
Member Author

As mentioned, it mostly provides the same functionality than the current code, but allow to move forward, whatever the direction.
For instance, it is easy to make payload modules running their own threads.
Regarding the implementation of the drivers, I have modified the UART driver so that when it is used to send messages, the mutex are only needed once per message instead of once per character in the previous implementation. So it is much more efficient, and the other ones (SPI, I2C) were already working like this thanks to the transactions queues.
In the end, the regular FW autopilot only needs 6% of the MCU on Apogee.
I also would like to make AP and FBW parts running in separated thread soon, since the design was made for that purpose.
With the time, more elements could be split into threads, but making it nicely compatible with older bare-metal code is not so obvious to me.
So, except for the issue of which ChibiOS Git repository we should follow, I really think getting rid of the mixed chibios/locm3 is a necessary step.

@podhrmic
Copy link
Member

podhrmic commented Jun 2, 2016

I definitely agree with removing the chibios-libopecm3 stuff.
So I guess as long as you are open to slowly improving the drivers/threading over time I am cool with that.
Also, what is the github issue? Isn't this the repo we want? https://github.com/ChibiOS/ChibiOS/tree/stable_16.1.x

@gautierhattenberger
Copy link
Member Author

Yes, but since they apply a AUTHORS file to change the "svn" name to a full name+email git format, this tree is not compatible anymore with the one we are currently using in master (https://github.com/mabl/ChibiOS). So the command git submodule sync needs to be applied at some point for the new tree to be fetched, otherwise the submodule checkout fails.
It's fine for new users, not for people updating from an older branch. This is also why the CI servers are failing. Hopefully @flixr as an idea about how to sort this properly, I'm not really good with git submodules.

@podhrmic
Copy link
Member

podhrmic commented Jun 2, 2016

I see. Well I guess since this is in the development branch, it shouldn't be a problem for users to just do a fresh git clone (in case it turns out to be too complicated to fix)

@flixr
Copy link
Member

flixr commented Jun 2, 2016

added the git submodule sync to semaphore, shouldn't be needed for travis as it does a fresh git clone...
The tests are failing because of e.g. duplicated AC_IDs...

@podhrmic
Copy link
Member

podhrmic commented Jun 2, 2016

The ID's are fixed in the master - git rebase?

@flixr
Copy link
Member

flixr commented Jun 3, 2016

Currently no idea what's up with the semaphore build, investigating that...
But there is e.g. logger_sd_chibios.makefile missing as can be seen in the travis builds

@gautierhattenberger
Copy link
Member Author

@flixr thanks for fixing CI config!
@podhrmic @flixr do you see something else to fix/improve here ?

@@ -95,6 +105,16 @@ ifeq ($(USE_LINK_GC),)
USE_LINK_GC = yes
endif

# Linker extra options here.
ifeq ($(USE_LDOPT),)
USE_LDOPT =
Copy link
Member

Choose a reason for hiding this comment

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

minor, but I think that writing USE_LDOPT ?= is easier to understand than using ifeq...

Copy link
Member Author

Choose a reason for hiding this comment

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

This is because it is based on original ChibiOS examples, makes it easier to upgrade afterwards. Should I still change it ?

Copy link
Member

Choose a reason for hiding this comment

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

Probably better to make it consistent with the original ChibiOS examples, at least for now

@podhrmic
Copy link
Member

podhrmic commented Jun 3, 2016

I ll look through it in detail over the weekend.

CHIBIOS = $(PAPARAZZI_SRC)/sw/ext/chibios

# directory with board defines for chibios platforms (board specific)
BOARD_DIR ?= $(BOARD)/chibios
Copy link
Member

Choose a reason for hiding this comment

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

here you set BOARD_DIR to $(BOARD)/chibios, but for apogee you use BOARD_DIR=$(BOARD)/v$(BOARD_VERSION)...
Maybe we should stick to one schema?

Copy link
Member Author

Choose a reason for hiding this comment

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

I choose not to use BOARD_VERSION since it may not be provided or wanted to separate config files by default.

@flixr
Copy link
Member

flixr commented Jun 3, 2016

Haven't looked at the drivers in detail, but I would be very happy if we can merge this as it is a lot cleaner than the chibios-locm3 mix... :-)

Then when we have this in master we can continue and pull in the separate main threads that @podhrmic already uses in his chibios branch.

Or maybe even better: we should try to abstract threads and mutexes and build a main that we can use for both Linux OS and ChibiOS (and ...?)

CHIBIOS_BOARD_DIR = $(PAPARAZZI_SRC)/sw/airborne/boards/$(BOARD_DIR)

# directory with board and OS configuration (project specific)
PROJECT_DIR ?= demo
Copy link
Member

Choose a reason for hiding this comment

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

I am not sure about the project directory - it is demo by default, but in the board makefile we set it to (empty string), right?

Maybe we can get rid of it / streamline it?

# MODEM_PORT
# MODEM_BAUD
#
PERIODIC_FREQUENCY ?= 500
Copy link
Member

Choose a reason for hiding this comment

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

I would add RTOS_DEBUG = 1 so the tests always compile with full debug suite.

@podhrmic
Copy link
Member

podhrmic commented Jun 6, 2016

OK, so I finally have time to look over it in more detail - looks good, just few minor things I would recommend changing (see my comments).

Or maybe even better: we should try to abstract threads and mutexes and build a main that we can use for both Linux OS and ChibiOS (and ...?)

Sounds like a good idea. Although I am not very familiar with Linux threads so hard to say how much different it would be. But I definitely support multithreaded solution:)

@gautierhattenberger
Copy link
Member Author

I think this should cover most of the comments. Thanks.

@podhrmic
Copy link
Member

podhrmic commented Jun 6, 2016

Looks good to me!

@gautierhattenberger gautierhattenberger merged commit 73e93b0 into master Jun 7, 2016
@gautierhattenberger gautierhattenberger deleted the chibios_arch branch June 7, 2016 07:44
@flixr flixr mentioned this pull request Mar 4, 2017
4 tasks
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.

3 participants