OS free F4Light HAL

[night-ghost]

Rather simple OS-less HAL for almost any F4 board with easy portability and sub-quant scheduling accuracy.

Features:

• HAL don't uses any OS, it does OS functions itself
• separated CCM stacks for ISR and tasks
• 0.8uS context switch time (thanks ScmRtOS)
• ~1.5uS time from interrupt to resuming task that was waiting that interrupt
• all work with task list and semaphores occures in ISR level via SVC so there is (almost) no need to disable interrupts, and interrupts never disabled for more than 4 commands
• priority system allows to set up "relative speed" for tasks, high-priority task do not blocks out low-priority task but only slows it down
• overclocking support up to 240MHz (parameter), F4 is really faster than F7!
• ArduCopter loop at 1KHz without issues, mean scheduling error is only 10uS - 10 times less than task tick!
• SoftwareSerial driver based on ST appnote - almost any 2 pins can be used as UART
• Timer based SoftI2C driver that works in interrupts, allows to use any 2 pins as I2C bus
• waiting for SD-card answers does in ISR as finite state machine with no CPU load
• ability to prevent dumb waiting loops from stealing CPU

Also:

• Support for OSD on Omnibus boards
• support Ardupilot parameters on builtin OSD (still untested though)
• two RC inputs with automatic parsing of PPM, DSM, SUMD and SBUS (both inverted and non-inverted) on each, allows to use 2 RC receivers in diversity mode
• support for Clock Security System - if quartz fails in air then system will switch to use HSI instead
• EEPROM emulation provides reilable data storage even at power failures
• Parameters support for HAL to tune its functions
• Supported natively OneShot125 and OneShot42 with high precision
• failsafe on receiver's hangup - if no channel changes in 60 seconds (parameter)
• free configuration of unused pins
• USB virtual port can be connected to any UART - eg. for OSD or 3DR modems setup
• any UART can be connected to ESC for 4-way interface for ESC programming
• FlexiPort can be switched between UART and I2C (parameter)
• Compensated frequency error for the PWM outputs
• support for reading from SD card via USB (parameter), FC can be mounted deep in body.
• internal flash chip is formatted to FAT and allows access via USB too
• I2C_Mgr prevents creating of same device on same bus - to prevent autodetection misses like MS5611 (already initialized) detected as BMP_085, thus allows autodetection of all baro and compass types
• EEPROM save can be deferred up to disarm
• Prioritized SPI DMA transfers to prevent such issues
• no concurrent DMA2 usage to avoid chip bug
• ability to use PPMn input port as RX-only UARTs
• MAVlink messages about SD card errors
• DSM decoder sends rssi as last channel
• TimeZone HAL parameter - log times are localtime
• and many more

Sorry this PR don't follow rules and changes a lot of files, but it too hard to split it out. Moreover all changes outside HAL are small and straitforward.

[khancyr]

Hello,

Thanks for your work ! I will try to help you to split the commit in easier reviewable parts, if you agree.

[night-ghost]

Yes thanks, but HAL_Revomini folder should be whole

[hiro2233]

I vote fot this! merge it! The @night-ghost revo mini hal doesn't break the system and development. I don't know what is the problem to merge this hal.

[Pedals2Paddles]

@hiro2233, that is incorrect. Blindly merging a PR that adds 177,000 lines of code across multiple libraries and multiple vehicles in one single commit without even reviewing it is luidcrous. Please don't make reckless suggestions. That is improper and makes troubleshooting nearly impossible. It is also a violation of the PR and commit guidance/standards used by ArduPilot (and basically everyone else).

To clean this up into an acceptable and standard PR is not a big deal. It just needs to be broken up into several more logical commits. I think @night-ghost already gets what needs to be done, but for the benefit of @hiro2233 and anyone else... This is a lesson I learned when I first started doing PRs for ArduPilot.

• Each library needs to be its own commit (AP_Airspeed, AC_Fence, etc)
• Each vehicle directory (copter, plane, etc) should be its own commit.
• Other HAL directories that are modified should be their own commits.
• Then this new revo HAL directory or directories can probably be its own rather large commit, since it is all brand new and not changing existing code.

This sounds like a pretty cool addition to ArduPilot.

[khancyr]

@hiro2233 as all submission, it need to be consistant with other works so anybody can understand it, that is why we try to unforce code style and syntax a maximun. Otherwise the project will be split under each developpers playgrounds....

Moreover the review process also permit to limit bugs and mistasks

[lvale]

@night-ghost In a few hours we have the dev team weekly call. I've just added this PR as a topic to that meeting, so I believe it would be great if you could join us at http://ardupilot.org/dev/docs/ardupilot-mumble-server.html

I know the time might not be perfect to you, but would be great to have you there :)

Thanks,

and nice job :)

[hiro2233]

@khancyr @Pedals2Paddles yes i know that, i vote to make it splited, that was one thing that i did with URUS hal, but the diff do the work to study the changes too.

Spliting for each library is reasonable, but doing that maybe doesn't make sense at all, when i started studying the ardupilot code i cloned it and studied one by one library, i didn't see the diff commit's at all.

[Pedals2Paddles]

Definitely would be great to have you join the dev call this evening. I'm sure this will be a hot topic.

[hiro2233]

this hal uses CMSIS, so this is a good base rtos hal too.

[night-ghost]

anybody can understand it

sorry but no - hardly using the OS everyone understands its internal structure. And this HAL is the OS itself. So I'm fundamentally against the changes in the HAL code itself: today the last bug from the huge herd was fixed, everything works as it should, and I do not want to produce new bugs for the sake of formalities.

if you could join us

unfortunately, the time difference of 12 hours strongly interferes with direct communication. We have a night now.

[magicrub]

@night-ghost could you please look into this compiler error?

../../libraries/AP_Math/AP_Math.cpp:121:54: error: duplicate explicit instantiation of ‘decltype (wrap_180(angle, 1.0e+2f)) wrap_180_cd(T) [with T = long int; decltype (wrap_180(angle, 1.0e+2f)) = float]’ [-fpermissive]
 template auto wrap_180_cd<long>(const long angle) -> decltype(wrap_180(angle, 100.f));
                                                      ^
compilation terminated due to -Wfatal-errors.

[amilcarlucas]

Shouldn't this be called ScmRtOS HAL ?

[hiro2233]

@magicrub thats is a wiindows editors mistake encoding conversion, probably comming from a russian windows.

The standard for Ardupilot should be utf-8 and thats need be added on wiki dev rules too.

http://www.i18nqa.com/debug/bug-iso8859-1-vs-windows-1252.html

[Pedals2Paddles]

@night-ghost you do not need to alter your code to split it up into multiple logical commits as described. My reply above describes the logical manner in which commits are required to be structured. Your code doesn't need to change. It just can't be all in one single commit. It only takes a few minutes in GitHub and a force push to your branch to do it.

[davidbuzz]

Three issues:
I support the general addition of support for RevoMini board/s and similar, but as per Pedals, "multiple logical commits" is good.
Also, I'd like to point out that this is not really "OS Free" because it uses CMSIS.
Third: I'd like to point out that parts of this commit are NOT GPL licensed eg:
libraries/AP_HAL_REVOMINI/hardware/STM32F4xx_DSP_StdPeriph_Lib_V1.1.0/Libraries/CMSIS/Device/ST/STM32F4xx/Include/stm32f4xx.h

[davidbuzz]

pointer to the " MCD-ST Liberty SW License Agreement V2" for discussion.

[hiro2233]

ChibiOS use CMSIS and is present on the modules, use that or in separate module for revomini hal.

https://github.com/ArduPilot/ChibiOS/blob/fd01e98bc7aa657f883d0d0860d0b47f678ca098/os/common/ext/CMSIS/ST/STM32F4xx/system_stm32f4xx.h

[peterbarker]

On Mon, 22 Jan 2018, night-ghost wrote: Rather simple OS-less HAL for almost any F4 board with easy portability and sub-quant scheduling accuracy.

Would be interesting to see if we could reuse the hwdef.dat we're using in the ChibiOS port to support more than one board with this.

[night-ghost]

Shouldn't this be called ScmRtOS HAL ?

do you think that 9 assembly instructions imported from scmRTOS makes all HAL based on that OS?

compilation terminated

AP_Math.cpp can stay unchanged, I just added long versions for some templates like constrain_value

It only takes a few minutes in GitHub and a force push to your branch to do it.

I'm not a Git master and prefer diff/patch for internal work. So I need step-by-step instructions to do those changes.

Also, I'd like to point out that this is not really "OS Free" because it uses CMSIS

You are wrong, CMSIS is not an OS. ChibiOS uses CMSIS too, isn't it?

Would be interesting to see if we could reuse the hwdef.dat

I'm fundamentally against it because code generation is absolute evil. It's easier to fill the required tables and defines by hands than to understand why a super complex code generator did something wrong. For this HAL programmer should to know just Arduino's C++, without Python and generator's logic.

[magicrub]

I'm not a Git master

How do you use Git? Is it command-line or do you have a GUI tool? I recommend SourceTree for Windows/Mac.

[night-ghost]

ChibiOS use CMSIS and is present on the modules, use that or in separate module for revomini hal.

Modules are "dark forest" for me :(

[night-ghost]

How do you use Git?

command line tools scripted in .sh files for common needs.

[night-ghost]

And few words more about dev call. The last time I heard spoken English more than 30 years ago, it's unlikely that I will be able to understand anything now.

[peterbarker]

On Tue, 23 Jan 2018, night-ghost wrote: Would be interesting to see if we could reuse the hwdef.dat I'm fundamentally against it because code generation is absolute evil. It's easier to fill the required tables and defines by hands than to understand why a super complex code generator did something wrong. For this HAL programmer should to know just Arduino's C++, without Python and generator's logic.

Yes, code generation is usually evil. But while we *do* generate C++ code - the code being generated are static data structures. Having sarted work on a Sparky2 port for ChibiOS, I can say that the more we can generate from hwdef.dat the better; entering the same stuff in several different files sucked. I believe most of the work I did there is no longer relevant given we're sourcing more stuff from hwdef.dat There are other things counting for using a hwdef.dat. A lot of what the generation is avoiding is *very* knowledgeable people staring at DMA mapping tables and trying to do the resolution in their heads. The failures when this is done incorrectly are often surprisingly subtle. Also - the generator is a supplied tool. Like a compiler. And not *that* complicated :-) If it goes wrong, you can reasonably expect someone to help fix it....

[night-ghost]

could you please look into this compiler error?

Found. Upstream added instantiation for long too so now there is 2 long instantiations. Will fix it

[night-ghost]

There are other things counting for using a hwdef.dat. A lot of what the
generation is avoiding is very knowledgeable people staring at DMA
mapping tables and trying to do the resolution in their heads.

This is not the only way! I also don't need to remember details about DMA and so on because all CPU structure is encoded in few tables. So one should only to see a diagram and say

#define OSD_CS_PIN PB4

This is not much harder than your hwdef.dat but does not require superfluous entities like a generator.

Porting this HAL to Cl_Racing F4 board took near half a hour - but this time includes adding support for inverted buzzer to AP_Notify

[night-ghost]

Silence... so I think that this PR should be deleted too.

[magicrub]

dude.. it's 176971 lines of code. @nathantsoi joined the devcall yesterday to try and help get your branch into a mergable state because it's not even close right now.

[Pedals2Paddles]

Silence... so I think that this PR should be deleted too.

Even the dev team has to go to sleep at night...

This is a huge add, so please give people time to review and provide input. You have people interested in this trying to work with you. No need to demand it be deleted just because it hasn't been unilaterally accepted within hours.

[tridge]

I have merged the F4Light hal.
Many thanks to @night-ghost for your persistence with this!

[hiro2233]

finally. 👏 👏 👏

[auturgy]

Thanks to all involved, but particularly Tridge and night-ghost. It’s really pleasing that this is now in master. For night-ghost: I assume you’ll put a post in your rc groups thread? If so, can you link it here and in discuss.ardupilot.org? This is one of the biggest merges we’ve had, and was a massive individual contribution from you, so worthy of a blog post :) Regards, James

…

On 10 Feb 2018, at 9:15 am, Andrew Tridgell ***@***.***> wrote: I have merged the F4Light hal. Many thanks to @night-ghost for your persistence with this! — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[night-ghost]

now the time to massive changes in my fork.

I assume you’ll put a post in your rc groups thread?

it already done without me

[anbello]

Thanks to @night-ghost and @tridge, I think this HAL will contribute to spread Ardupilot in low budget DIY projects and to increase the number of users a lot.

[lvale]

@night-ghost @tridge
Great work from both of you. Thanks.

@night-ghost or @anbello Would be great if any of you could create a blog post on discuss.ardupilot.org, describing the compatible boards and connections, so that we could have a wider audience that might be looking for low budget modern boards, and at the moment look for the older APM's.

[anbello]

@lvale if for @night-ghost is OK I will try to do asap (even if I have problems with English language), in the meantime there is the wiki in night-ghost fork:
https://github.com/night-ghost/ardupilot/wiki

[night-ghost]

@anbello Andrea, it would be excellent!

[anbello]

If I clone ardupilot master and I try to build for f4light I obtain:

andrea@galileo:~/src/ardupilot/ArduCopter$ make f4light ../mk/board_F4Light.mk:72: /home/andrea/src/ardupilot/ArduCopter/../libraries/AP_HAL_F4Light/boards/f4light_Revolution/target-config.mk: No such file or directory /home/andrea/src/ardupilot/ArduCopter/../libraries/AP_HAL_F4Light/wirish/rules.mk:6: /home/andrea/src/ardupilot/ArduCopter/../libraries/AP_HAL_F4Light/boards/f4light_Revolution/rules.mk: No such file or directory make: *** No rule to make target '/home/andrea/src/ardupilot/ArduCopter/../libraries/AP_HAL_F4Light/boards/f4light_Revolution/rules.mk'. Stop.

the problem is that in ../libraries/AP_HAL_F4Light/boards there is no dir named f4light_Revolution but there is:

revo_cl_racing revomini_Airbot revo_MiniF4_OSD revo_MatekF405_OSD revomini_AirbotV2 revomini_Revolution

if I rename revomini_Revolution in f4light_Revolution it builds.

[anbello]

I created the blog post:
https://discuss.ardupilot.org/t/new-os-free-f4light-hal/25723

Please correct my English and also eventual technical errors.

It will expanded in the future also, I hope, with other members contributions.

[lvale]

@anbello Thanks Andrea :)
I would suggest that in time the specific wiki entries could be merged to the general ardupilot wiki.

Also, would be good to point to some specific boards, known/tested to work.

[anbello]

Also, would be good to point to some specific boards, known/tested to work.

do you intend more the this:

I built and flight with success three quadcopter, one for each of the aforementioned boards. @vierfuffzig built and flight plane with Revolution Mini, He can explain us in more details.

[OlivierJB]

@anbello Great blog post, thanks!
I made a few minor (English related) edits.

https://discuss.ardupilot.org/t/new-os-free-f4light-hal/25723

Please correct my English and also eventual technical errors._

[rmackay9]

ideally we should also add this board to our "Autopilot hardware Options" wiki page.
http://ardupilot.org/copter/docs/common-autopilots.html

[anbello]

@OlivierJB thanks for correcting my English.

@rmackay9 I agree with you but I think we should wait for an official version that can be installed from the GCS. Moreover it should be explained that for some of this board is necessary a minimum soldering skill to add break out boards with baro and mag and to remove some 0 ohm resistor (jumper) in some cases. This process could be documented with a series of photos and descriptions step by step. If only I had taken some shots during the building of my quads now I would have the material for this documentation.