Open5xxxECU.org
http://open5xxxecu.org/

O5E software design modularity and architecture
http://open5xxxecu.org/viewtopic.php?f=13&t=167
Page 1 of 1

Author:  apalrd [ Wed Dec 14, 2016 10:36 pm ]
Post subject:  O5E software design modularity and architecture

This is derived from a PM conversation I had with Mark about the direction of O5E.

One of the goals of O5E has always been a modular design. To me (and I know everyone has their own opinion on the direction in open-source projects), one advantage to an open-source ECU platform is the ability to tweak the code to suit my needs. However, just opening the code and saying 'have at it' will cause a lot of frustrated users. Most of the time, the code I want to implement is fairly simple, but not covered by 'generic output' functionality.

This brings the next point - How to design the code to be modular and allow easy tweaking, while protecting stability and code reliability. In industry, a tool like Simulink would be used to model the algorithm code, and then it would be auto-coded into C and compiled. This approach makes it much easier to interact with the algorithm code without getting far into the C programming, and greatly limits the damage that can be done to the whole system from that environment. I don't think O5E would ever attempt to develop our own modeling language like Simulink, but we might eventually want to look at integrating with an open-source option.

To implement a truly modular system, I see a need for the software to have a very hard line between the algorithmic functions and the foundation functions. Basically, instead of writing all of our engine code on top of a generic RTOS like and doing raw hardware IO calls like we are doing now, we would try provide a specific interface to the hardware that includes functions like configuring an IO as PWM or Injector or Ignition, requesting and updating pulses, etc.

After the foundation functions are written and tested (and this only requires a MPC56xx dev board, nothing more!), we will basically have a framework to write powertrain applications (not ruling out transmission or slave IO controls) with the foundation providing all of the eTPU, eQADC, eMIOS, etc. and tool interfaces abstracted away. Users could start with the example engine or slave IO module code, and write their small changes as they need using the remaining IO, or leave it as-is and run an engine with it. Somewhere down the road, this algorithm interface could be ported to something like Xcos or another graphical language to make it even easier for new users, but not yet.

The third (small) piece is a bootloader which runs on MPC56xx and allows S19s to be programmed over serial or CAN. This is an entirely separate executable, never modified by users.

What are everyone's thoughts on an architecture like this? I can slowly work through writing the foundation in my free time.

Author:  mk e [ Thu Dec 15, 2016 8:39 am ]
Post subject:  Re: O5E software design modularity and architecture

Modular was always the intent...but perhaps we didn't do a great job of implementing it. I'm all fo making stuff better. We trying to put all the control code in a c ouple files and there has a lot of talk about more canned functons to simplify what was in the onrtol files.

I think Sean wrote a boot loader....but I never did anyhitng more than look at it becaseu CW loaded what I readed to load without me doing anything othe than click the load button....which is abotu my limit.

Author:  apalrd [ Thu Dec 15, 2016 2:19 pm ]
Post subject:  Re: O5E software design modularity and architecture

It definitely took me more than a click to get OSJTAG debugging working properly, but a lot of that seems to be P&E's support of OSJTAG vs their own hardware. I have had much more pleasant experiences with a Cyclone Max and with Lauterbach Trace32 debuggers on these chips.

I'll start looking at the IO side of things.

Author:  mk e [ Thu Dec 15, 2016 3:36 pm ]
Post subject:  Re: O5E software design modularity and architecture

I have absolutley no idea how to use a debugger so that's not an issue for me :)

Author:  abecedarian [ Fri Dec 16, 2016 11:13 am ]
Post subject:  Re: O5E software design modularity and architecture

mk e wrote:
I have absolutley no idea how to use a debugger so that's not an issue for me :)

You don't know how to step through code and see how variables and I/O evolves over time...?

Author:  apalrd [ Fri Dec 16, 2016 12:28 pm ]
Post subject:  Re: O5E software design modularity and architecture

For testing the majority of the code, just looking at all of the inputs and outputs over the normal measurement protocol (TS or whatever) is fine, no debugger required.

If the code hits an exception, that's the only case where you would really need to step.

Author:  mk e [ Fri Dec 16, 2016 1:53 pm ]
Post subject:  Re: O5E software design modularity and architecture

abecedarian wrote:
mk e wrote:
I have absolutley no idea how to use a debugger so that's not an issue for me :)

You don't know how to step through code and see how variables and I/O evolves over time...?


Not with a debugger. When I have a problem I manually through flags of some kind in so know how far it got.....I am not a programmer.

Page 1 of 1 All times are UTC - 5 hours [ DST ]
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
http://www.phpbb.com/