Hello from France - Project for an old british car and my own approach to HAL

Your chance to introduce yourself and your vehicle
Post Reply
User avatar
Fonzie
Posts: 13
Joined: Sun Jan 28, 2018 3:06 pm
Location: 39000 Lons-le-Saunier, France
Github Username: duparq
Contact:

Hello from France - Project for an old british car and my own approach to HAL

Post by Fonzie »

Hello !

I'm really pleased reading all the stuff you have put here. I was an electronics a long time ago when microcontrollers were not so affordable and I graduated in computer science. I am a supporter of free software and I personally use Linux based systems exclusively since 1998.

About ten years ago, I spent a few hundreds of hours developing a data recorder for the hill climbing March 82S of a friend powered by a 2L Mazda V6 developed by his father (http://duparq.free.fr/soft/carspy/index.html). Then came the project of an ignition controller, and perhaps a fuel injection controller (currently mechanical). Much thoughts but not much realized yet... This has been the starting point for my HWA project (http://duparq.free.fr/hwa/index.html): an object oriented HAL, probably very different of all you have seen before. That took me years to reach something that I really like and although a lot of work remains to be done I do not want to use anything else anymore! As I've seen you are concerned about the HAL, I would be proud to develop HWA further for the purpose of rusEfi if you want to use it.

Last year, I bought a 1968 Jaguar 3.8S that had remained ten years in its garage:
3.8S.jpg
3.8S.jpg (650.33 KiB) Viewed 12205 times
It really hit the road again this week after I repaired the brakes and the clutch command. On the engine side, I think it first needs a better ignition. I would like to use coil-on-plugs if I can arrange so that it is visually acceptable (the XK engine deserves something that looks good!). I have three AS5047P evaluation boards that are waiting for experiments. The datasheet looks very promising, that would be great these chips give accurate camshaft position despite the temperature under the hood (for the rev counter, the XK engine has a pulse generator located on the back of the RH cameshaft, the ideal place for the sensor). After that, I'll consider a WBO2, a fuel injection system (hidden in the carbs?) or motorize the carbs...

I know I'll find many interesting things to learn here and I hope I'll find enough time to experiment and give back if possible.
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: Hello from France - Project for an old british car and my own approach to HAL

Post by AndreyB »

Welcome to the forum!

Oh my god this thing is SO BEAUTIFUL! Probably a lot of work to baby it but still beautiful :)

AS5047P is a 14-bit magnetic rotary position sensor is designed for high speed (up to 28krpm) angle measurement over a full 360º range.
Why are things like that never used in OEM? Price? Reliability?

As for HAL, I should check it out but the biggest issue with my rusEfi life is lack of time, lack of time and lack of time :(
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
User avatar
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: Hello from France - Project for an old british car and my own approach to HAL

Post by kb1gtt »

Hello and welcome along to the forum. In a prior project I used a magnetic encoder. I posted about it here. http://www.jaredharvey.com/Files/projects/open-encoder/index.htm

Very nice Jag.

Can you provide an overview of why your HAL is different? It sounds like you have identified that we currently mostly use ChibiOS for the HAL, which is a bit generic, but also works. We have contemplated switching to other chips, but if they are not supported by ChibiOS HAL, then it become very difficult.
Welcome to the friendlier side of internet crazy :)
Lyonz
kit assembler
Posts: 56
Joined: Sat Apr 21, 2018 12:08 am
Location: Guadeloupe

Re: Hello from France - Project for an old british car and my own approach to HAL

Post by Lyonz »

Bienvenu à toi sur ce forum.
Superbe projet avec une voiture hors du commun :D
User avatar
Fonzie
Posts: 13
Joined: Sun Jan 28, 2018 3:06 pm
Location: 39000 Lons-le-Saunier, France
Github Username: duparq
Contact:

Re: Hello from France - Project for an old british car and my own approach to HAL

Post by Fonzie »

russian wrote:
Sat Jul 06, 2019 10:54 pm
AS5047P is a 14-bit magnetic rotary position sensor is designed for high speed (up to 28krpm) angle measurement over a full 360º range. Why are things like that never used in OEM? Price? Reliability?
I bought them from Mouser, about $18 each. It took 6 months before they could dispatch them... I ask myself the same questions about why these are not widely used. We'll see...
russian wrote:
Sat Jul 06, 2019 10:54 pm
the biggest issue with my rusEfi life is lack of time, lack of time and lack of time :(
Same here ! ;)
kb1gtt wrote:
Sun Jul 07, 2019 12:12 am
In a prior project I used a magnetic encoder. I posted about it here. http://www.jaredharvey.com/Files/projects/open-encoder/index.htm
I've read it. Your conclusions?
kb1gtt wrote:
Sun Jul 07, 2019 12:12 am
Can you provide an overview of why your HAL is different? It sounds like you have identified that we currently mostly use ChibiOS for the HAL, which is a bit generic, but also works. We have contemplated switching to other chips, but if they are not supported by ChibiOS HAL, then it become very difficult.
  • HWA is designed for bare-metal programming. It is not a library. It is implemented mostly at the C preprocessor level (you include one header file) and the C code it expands is then optimized by the compiler so that only smart register accesses remain in the binary (that way, blinking a LED does not require a function call and 1 kB of code).
  • HWA lets you describe what you want, and it produces the code that does it. You do not bother with hardware registers (but you can still access them if you want, e.g. for debugging purpose) and you do not have lots of different functions and symbols with long and sometimes strange names to remember. You mostly use HWA through two generic "functions" (function-like macros in fact):
    • the hw(...) function is synchronous: it produces code that acts immediately on the hardware, e.g. 'hw(configure,pa0,mode,digital_output)' or hw(turn,irq(counter0,overflow),on)'.
    • the hwa(...) function is asynchronous: it produces code that acts on a temporary context so that multiple hwa(...) instructions can be used to describe a complex configuration. Then, 'hwa(commit)' translates the configuration (and tells you if it can not find a solution to what you want).
    • hw(...) and hwa(...) accept a variable number of arguments. Typically, the first one is an action name that tells what you want to do (configure, read, write...) on the hardware object whose name is the second argument, the others are key/value pairs. That makes the code very concise and readable.
  • HWA is object oriented but does not require a C++ compiler. It tries to provide a consistent interface to all the peripheral controllers of the same type without preventing the usage of specific features some offer. For example, if you only use basic features of a counter (timer), the code should be easily portable to any target device.
  • HWA recognizes object names such as 'counter0' or 'pb4' and object "paths" such as '(counter0,compare0)' or '(counter0,capture0)'.
  • HWA provides portable IRQ and ISR names that are easy to guess.
  • HWA tries to produce helpful error messages.
Several examples are provided with the documentation.
Lyonz wrote:
Sun Jul 07, 2019 2:22 am
Superbe projet avec une voiture hors du commun :D
Bonjour les Antilles ! Le fondateur de Jaguar s'appelait William Lyons, avec un S !
Last edited by Fonzie on Sun Jul 07, 2019 8:52 pm, edited 1 time in total.
User avatar
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: Hello from France - Project for an old british car and my own approach to HAL

Post by kb1gtt »

I think OEM's don't use them because there is lots of complication, and lots of things that need vetting before they can be considered to have a high MTBF. AKA expensive and more likely to fail than existing technologies. I'd also bet there are patent constraints as well.

Some key problems I had
-- getting the flux to the proper level. It was hard to get a high enough flux, as the right place. I did it with a center hole, but it would be more practical to do it with out a hole down the center of the magnet.
-- Alignment was key. It was semi-difficult to get the alignment just right. I was able to get it good enough by putting a hole in the PCB which guided the magnet, and then mounting the magnet from the bottom, not from the top. The solder would align the chip in one direction we'll call that the Y direction with the pads being more in the X direction. Then I just had to align the chip in the X direction on the pads. As long as I keep the chip centered on the pads, it was good.

There used to be a better write up about that at openservo.com. However that site has gone the way of bit rot.
Welcome to the friendlier side of internet crazy :)
User avatar
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: Hello from France - Project for an old british car and my own approach to HAL

Post by kb1gtt »

Does HWA support the STM32F4, or F7? My quick looks seems to show support for the F1, but I don't see it for newer version.
Welcome to the friendlier side of internet crazy :)
User avatar
Fonzie
Posts: 13
Joined: Sun Jan 28, 2018 3:06 pm
Location: 39000 Lons-le-Saunier, France
Github Username: duparq
Contact:

Re: Hello from France - Project for an old british car and my own approach to HAL

Post by Fonzie »

Support for STM32F103 is barely started: you can configure the clocks (rcc), pll, systick, gpios, nvic (partially). I had started to work on the general purpose counters when I pushed the last commit.

I would start the porting to STM32F4 if there is interest (I have a STM32F411E-DISCO for testing). Porting to different STM32 should not be a big challenge since the same controllers seem to be used across all the STM32 family. Then once a class is written for a type of controller for one device, porting it on a different device is just a matter of address declarations (mainly copy-and-paste work).

The most time consuming work when writing a new HWA class is the definition of a nice syntax to use it.
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: Hello from France - Project for an old british car and my own approach to HAL

Post by AndreyB »

What chip is supported best?

Is this just a HAL without any OS? How do you deal with concurrency/threads/etc if no OS or what OS do you use?

stm32 seems to have few different versions of some of peripheral see https://github.com/ChibiOS/ChibiOS/tree/master/os/hal/ports/STM32/LLD it could be that something is shared between F1 F4 and F7 I really do not know, I just use it out of the box and it just works :)

@andreika is the guy here with most HAL experience - he is currently working on ChibiOS HAL for 5v kitetis and looks like some drivers were different from 3v kinetis.

There is just no motivation for us to move from one HAL to another while we stay on the same platform :(

Could your approach be an OOP facede for existing ChibiOS HAL drivers?
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
User avatar
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: Hello from France - Project for an old british car and my own approach to HAL

Post by kb1gtt »

Currently we are not running into performance issues with the semi-bloated compiler process. There is a project which uses the 5v kitetis chip. This effort does have some memory constraints, and this HAL would likely be helpful for that effort. However I think that's even harder to implement.
Welcome to the friendlier side of internet crazy :)
User avatar
Fonzie
Posts: 13
Joined: Sun Jan 28, 2018 3:06 pm
Location: 39000 Lons-le-Saunier, France
Github Username: duparq
Contact:

Re: Hello from France - Project for an old british car and my own approach to HAL

Post by Fonzie »

russian wrote:
Sun Jul 07, 2019 9:35 pm
What chip is supported best?
I'd say none of the STM32, Sir! Support is barely started. ATtinys and ATmegas are much better supported.
russian wrote:
Sun Jul 07, 2019 9:35 pm
Is this just a HAL without any OS? How do you deal with concurrency/threads/etc if no OS or what OS do you use?
HWA is totally independent of an OS. It is just an interface for hardware programming, it is not involved in multitasking.

So far, I've avoided using OSes because of memory requirements incompatible with 8-bit AVR microcontrollers. I've used interrupts and cooperative multitasking instead (state machines, coroutines).
russian wrote:
Sun Jul 07, 2019 9:35 pm
Could your approach be an OOP facede for existing ChibiOS HAL drivers?
I'm not sure I understand. If you mean using HWA to interface the ChibiOS HAL drivers, I'd say yes, it should be doable.
kb1gtt wrote:
Mon Jul 08, 2019 12:44 am
There is a project which uses the 5v kitetis chip. This effort does have some memory constraints, and this HAL would likely be helpful for that effort. However I think that's even harder to implement.
I know nothing about these chips, but I'm curious why HWA could not drive them.
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: Hello from France - Project for an old british car and my own approach to HAL

Post by AndreyB »

Fonzie wrote:
Mon Jul 08, 2019 8:57 am
If you mean using HWA to interface the ChibiOS HAL drivers, I'd say yes, it should be doable.
Exactly. ChibiOS HAL is great for C -style development and if I understand the idea of HWA right - if that's a more object-oriented API for HAL, would it make sense to simply wrap the existing tested lower-level HAL with a nicer API facade?

ChibiOS HAL is tied to OS which is not great I guess but understandable - the part where HAL starts to touch OS is things like callbacks / wait / queues etc.

I am not an expert in any of this obviously, I am just a java developer :) I love using existing APIs and do not enjoy diffing into implementation details when I do not have to.

HAL as many other pieces of the cake is just a piece. At the moment we are genially happy with ChibiOS - it had a bit enough following to be extremely reliable and supported and documented enough. We are kind of not exactly happy with stm32 - but happy enough to tolerate the minor inconveniences, unless one day someone hands us a better solution maybe based on TMS570 maybe S32K148 maybe something else.
.
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
User avatar
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: Hello from France - Project for an old british car and my own approach to HAL

Post by kb1gtt »

Could HWA also be used as a kind of GRC add-on?
https://wiki.gnuradio.org/index.php/Main_Page

Granted we are not a radio, but the idea of these blocks all linked together with a graphical display. I could see how a GRC style of display could be useful in connecting bare metal type code.
Welcome to the friendlier side of internet crazy :)
User avatar
Fonzie
Posts: 13
Joined: Sun Jan 28, 2018 3:06 pm
Location: 39000 Lons-le-Saunier, France
Github Username: duparq
Contact:

Re: Hello from France - Project for an old british car and my own approach to HAL

Post by Fonzie »

I do not know. Could you provide an example of what you'd like to achieve?
mck1117
running engine in first post
running engine in first post
Posts: 1493
Joined: Mon Jan 30, 2017 2:05 am
Location: Seattle-ish

Re: Hello from France - Project for an old british car and my own approach to HAL

Post by mck1117 »

Welcome! That car is fantastic. It'd be a shame if you ruined it with rusEfi... :P

I've seen some pretty convincing fake Weber DCOE carbs that covertly contain a pair of fuel injectors... I think Jenvey in the UK makes some, but they're something like 600 GBP each (2 cylinders worth - so you'd need 3 of them).

On the topic of alternative HALs:

HWA is a pretty awesome concept that I wish there was more of in rusEfi. The compiler is very smart - so we should use it as much as we can! HWA does it the "C way" using macros, and I've been pushing for more of it in rusEfi in the "C++ way", like this recent change I made to automagically infer and check the sizes of interpolation tables using C++ templates, all at compile time: https://github.com/rusefi/rusefi/pull/878

The ChibiOS HAL + our layers on top of it have been plenty performant for our needs. Remember that the MCUs we're working with here are 168-216MHz, several hundred KB of RAM, 1-2MB of flash, branch prediction, flash prefetch, and even a pair of 16kb D+I caches on the F7. We can afford to blow cycles and memory on stuff simply because the CPU is such a big hammer.

When he started the project, russian made the intentional philosophical decision to use a big, fast CPU that allowed for deep layers of abstraction, with very little reliance on the hardware to provide functionality. For example, all of our inputs and outputs are scheduled in software - no timers. A single timer is used to schedule events from a big priority queue that manages all future events we have scheduled (all injectors, ignition, . At the cost of a slight bit of jitter (in reality, generally sub-5 us for things like ignition and injection), we get an infinite number of 1us precision timers for free, on any pin. There are few restrictions about which pins have to be used for particular functions in rusEfi (barring obvious ones like ADC inputs), because our software doesn't care which pins you use.

The ChibiOS HAL has less overhead than you might think it does - the compiler does a good job with optimization, ARMv7e has a rich and dense instruction set, and the ChibiOS HAL is light to begin with. We're compiling with recent GCC which does a good job of optimization, and because we have so much flash, we can make speed-space tradeoffs in the speed direction.

For example, our generic "OutputPin::setValue" (which does things like ensure a valid configuration, and inverted modes at runtime) is 76 bytes compiled, and the hot path (no faults - actually sets the pin) is about 22 instructions long - under 100 nanoseconds. A 16mhz AVR takes 63 nanoseconds to execute a single instruction, and twice (or 3x - depending on chip) that for memory access.
kb1gtt wrote:
Sun Jul 07, 2019 12:12 am
we currently mostly use ChibiOS for the HAL, which is a bit generic, but also works
This is absolutely a feature - not a drawback. Because it's generic, once you implement the base set of functions for a particular port, you don't have to change any of your "application code" to support a new chip. All of the complication that looks like is there gets compiled away - it's all preprocessor defines, so it's mostly all 2-3 instructions once compiled.
Fonzie wrote:
Sun Jul 07, 2019 1:44 pm
the hwa(...) function is asynchronous: it produces code that acts on a temporary context so that multiple hwa(...) instructions can be used to describe a complex configuration. Then, 'hwa(commit)' translates the configuration (and tells you if it can not find a solution to what you want).
I think you mean transactional, not asynchronous. Transactional means that you prepare some set of operations together, then apply them atomically together, or not at all. Asynchronous means that they're applied at a later time, not blocking the current thread of execution. That's super awesome that this works all with macros! You're a braver man than I.
Fonzie wrote:
Sat Jul 06, 2019 11:37 am
As I've seen you are concerned about the HAL
@russian, are there any real, non-theoretical concerns about the existing HAL? I'm not concerned about the existing HAL.
russian wrote:
Mon Jul 08, 2019 9:53 am
ChibiOS HAL is tied to OS which is not great I guess but understandable - the part where HAL starts to touch OS is things like callbacks / wait / queues etc.
That's not the case - you can a subset of it without an OS, or use the optional OSAL (OS abstraction layer) to plug it in to an OS, as we do with ChibiOS/RT.
russian wrote:
Mon Jul 08, 2019 9:53 am
existing tested lower-level HAL with a nicer API facade?
You already wrote this :) It's the OutputPin class and friends, as discussed above.
kb1gtt wrote:
Mon Jul 08, 2019 12:44 am
semi-bloated compiler process
up for debate about whether it's bloated - see above

tl;dr: HWA is an awesome library. I'm a big fan of header only, compile-time-checked, easy to use stuff like this. However - the design philosophies behind HWA and the rusEfi firmware aren't very compatible. If we were running on an AVR, it would be a fantastic fit!
User avatar
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: Hello from France - Project for an old british car and my own approach to HAL

Post by kb1gtt »

mck1117 wrote:
Thu Jul 11, 2019 7:59 am
kb1gtt wrote:
Mon Jul 08, 2019 12:44 am
semi-bloated compiler process
up for debate about whether it's bloated - see above
I understand it's lite in terms of C compiler projects, which have many useful checks and balances. However it's bloated compared to bare metal hand written assembly.
Fonzie wrote:
Tue Jul 09, 2019 9:34 am
I do not know. Could you provide an example of what you'd like to achieve?
This snippet is from a OEM manual. You can see how the software is linked together with a graphical flow diagram. This is similar to how GRC links bits of code together.
Attachments
boost_controller_snippet.png
boost_controller_snippet.png (78.93 KiB) Viewed 12070 times
Welcome to the friendlier side of internet crazy :)
mck1117
running engine in first post
running engine in first post
Posts: 1493
Joined: Mon Jan 30, 2017 2:05 am
Location: Seattle-ish

Re: Hello from France - Project for an old british car and my own approach to HAL

Post by mck1117 »

(oops - I was typing this response when you replied - but we're on the same page here)
kb1gtt wrote:
Mon Jul 08, 2019 9:42 pm
Could HWA also be used as a kind of GRC add-on?
Nope - something GRC-like is very high level, and HWA (or ChibiOS/HAL that we use) are for the very lowest level of hardware interaction.
kb1gtt wrote:
Mon Jul 08, 2019 9:42 pm
but the idea of these blocks all linked together with a graphical display. I could see how a GRC style of display could be useful in connecting bare metal type code.
This is an idea I like - doesn't even necessarily need a graphical display. There are two paradigms in programming called declarative and functional programming.

Declarative programming strives to declare how something operates - but not provide instructions like "run this then do this", and instead describe what the program does instead of what of the program should do.

Functional programming is a flavor of declarative programming that expresses computation as pure functions. Basic functions (in the discrete math sense) are composed to form the operations you want. Things like GRC, Simulink (to an extent) and LabView (to an extent) are effectively quasi-functional languages.

Today rusEfi has more duplication and boilerplate code than I'd like - it's not very declarative. I'd love to refactor towards a world where things are defined declaratively/functionally, which would eventually enable awesome stuff like defining the algorithms your ECU uses to control various functions with data, instead of compiled-in code. The logical next step is then a drag-n-drop GUI (think GRC, Simulink, or LabVIEW).

I've been prototyping some stuff for this on the side, but that's a topic for another thread.

nb: this is what "real" OEM and motorsport ECUs do - they have a model, usually written in Simulink/MATLAB, which generates the algorithms that the ECU uses at run time. This idea is less foreign than you might think...
mck1117
running engine in first post
running engine in first post
Posts: 1493
Joined: Mon Jan 30, 2017 2:05 am
Location: Seattle-ish

Re: Hello from France - Project for an old british car and my own approach to HAL

Post by mck1117 »

kb1gtt wrote:
Thu Jul 11, 2019 8:47 am
I understand it's lite in terms of C compiler projects, which have many useful checks and balances. However it's bloated compared to bare metal hand written assembly.
Absolutely - but I think that's a feature, not a bug. I'd have a hard time beating GCC at most of the stuff our firmware does. I could maybe beat it on speed, but I certainly couldn't beat it on safety and catching edge cases.
User avatar
Fonzie
Posts: 13
Joined: Sun Jan 28, 2018 3:06 pm
Location: 39000 Lons-le-Saunier, France
Github Username: duparq
Contact:

Re: Hello from France - Project for an old british car and my own approach to HAL

Post by Fonzie »

mck1117 wrote:
Thu Jul 11, 2019 7:59 am
That car is fantastic. It'd be a shame if you ruined it with rusEfi... :P

I've seen some pretty convincing fake Weber DCOE carbs that covertly contain a pair of fuel injectors... I think Jenvey in the UK makes some, but they're something like 600 GBP each (2 cylinders worth - so you'd need 3 of them).
I intend to use this car as a laboratory for experiments on ignition and fuel injection and I won't make definitive modifications. Jaguar used Weber carbs only on racing XK engines to replace the standard SUs. I think I could better spend 1800 GBP for fixing many things such as the door sills!
mck1117 wrote:
Thu Jul 11, 2019 7:59 am
Fonzie wrote:
Sun Jul 07, 2019 1:44 pm
the hwa(...) function is asynchronous: it produces code that acts on a temporary context so that multiple hwa(...) instructions can be used to describe a complex configuration. Then, 'hwa(commit)' translates the configuration (and tells you if it can not find a solution to what you want).
I think you mean transactional, not asynchronous.
You're right. I should change this in the description.
mck1117 wrote:
Thu Jul 11, 2019 7:59 am
That's super awesome that this works all with macros!
Macros are necessary to provide generic functions and named arguments. They also help catching errors and building meaningful error messages (otherwise the macros naturally tend to insult you!). The rest is implemented through inlined C code.
Post Reply