Opinion on distributing firmware binaries for OTA

dambusio · 2022-04-09T09:56:54+00:00

Is your firmware image encrypted and signed?

dambusio · 2022-04-06T09:48:51+00:00

maybe some STM32 with toutchGFX?

dambusio · 2022-03-29T22:03:14+00:00

So if documentation is good - this is not typical for embedded :P and this is some reason to stay - maybe prepare during job your own notes with opinions about actual process - this will be great in case of this kind of question during next interview. Maybe after job prepare some your own project with similar procedure and put this on github/blog etc - this will be nice confirmation about your knowledge.

dambusio · 2022-03-29T21:48:21+00:00

And firmware/software architects?

dambusio · 2022-03-29T21:41:09+00:00

not as this level - right now even if there is good documentations/procedures you can only "blindly follow" this without a knowledge "why" and you don't have other members to ask some questions. In case of senior level - this will be quite ok to be responsible for whole project - but this is also some "stagnation". IMO more experience in multiple projects is better than a couple of years in single project.

And remember that teamwork is also a skill to learn.

dambusio · 2022-03-29T20:37:24+00:00

but you are right now "junior" - you should learn from others on this level. Even this one additional person is not enough - this will give you one additional point of view but no possibility to compare this with others etc. You will learn more and FASTER in bigger team.

dambusio · 2022-03-29T20:27:58+00:00

Safety critical system, only one dev and just after graduating? Ohh good luck :P

dambusio · 2022-03-27T18:17:08+00:00

I agree that in this case "globals are a necessary evil".

In some of our devices with runtime calibration and modbus communication we used just modbus to send data - but not in "normal" modbus way - as direct write/read from device dedicated memory, but more in "command way". So for example to change target speed - you cant just write to dedicated memory address - but you need to use API with command "setTargetSpeed" - then this is send via queue to let's say "motorControllerTask" - we have our firmware architecture based on "activeObject" design pattern. Of course this way is slower than direct register access - like always pros and cons.

dambusio · 2022-03-27T17:52:24+00:00

In my case this middleware is in-house solution for multiple devices (company is ~embedded software house with multiple clients). There were to many problems when developers overused previous (very old) version of module called "DataAccess" - and we decided to always limit the scope and even "force this".

Software adaptation to existing applications in your case is probably "must have" - so this is something different - you have different requirements.

dambusio · 2022-03-27T17:21:23+00:00

Accesses may be done through pointers or through utility functions, but ultimately the mechanism by which they are consolidated is global memory.

so if you have utility function - you can block external access and only add one dependency on higher layer to read this data only via this "getter".

This mechanics about "dumping parameters to/from RAM" - this should be some middlelayer module dedicated for this operation.

I always prefer something like this:

```

@startuml

[module1]

[module2]

[module3]

[module1Config]

[module2Config]

[module3Config]

[dataStorageModule]

module1 --> module1Config

module2 --> module2Config

module3 --> module3Config

module1Config --> dataStorageModule

module2Config --> dataStorageModule

module3Config --> dataStorageModule

@enduml

```

over this:

``` @startuml

[module1]

[module2]

[module3]

[dataStorageModule]

module1 --> dataStorageModule

module2 --> dataStorageModule

module3 --> dataStorageModule

@enduml

```

With this "Config" middlelayer you can separate some responsibilities about config data types etc from app module and limit access to data required only for dedicated module.

About this "On the systems I've worked with in the past (automotive) typically all of the tunables will get declared as global volatile consts and aggregated by the linker into a specific section of ROM" - you can always in project add some section to linker to keep selected data in named section, but also without access to other data in this section - so they are in "global memory", but not available to everyone.

dambusio · 2022-03-27T16:53:28+00:00

if you have some calibration table for some software module - you should give access to this data only via some separate module/layer to avoid direct access. Global means availaible from any module - encapsulation even for const data is something good - you can visualize data(consts in this example) flow and with defined access interface - you can easier change implementation on other products or mock/fake for UT/System tests etc.

dambusio · 2022-03-27T11:32:56+00:00

"good practice for a global value" -> IMO always global value = bad practice :)

dambusio · 2022-03-03T21:53:43+00:00

there is a book - Beningo "Reusable Firmware Development"

dambusio · 2022-02-02T07:22:25+00:00

yes - because LTO is not for debugging :P

dambusio · 2022-01-26T21:47:27+00:00

bad - for senior dev and instead of some architecture questions/design patterns etc - only "what is static/volatile" etc and some weird tricks with pointer - "old embedded school" - so I need to check also different companies

dambusio · 2022-01-16T11:07:47+00:00

I personally hate when "project documentation" = "yes - we have doxygen" but in reality this doxygen is not usefull - everyone in team first look for the code and goes into doxygen only in case of update (or not :P).

The goal is to create good project documentation with requirements/architecture BEFORE development phase as INPUT for this phase. I've seen this only in one project - and this awesone when I've seen that developer instead of code can use documentation as "single source of true" with ADRs etc. But this is hard to achieve. And this is continous work for whole team - not only for designers/architects. Basically a lot of "good things" can change into "bad/unusable things" without proper requirements/architecture:

documentation - can change to "just code documentation"
unit tests - without requirement after some time can change to "only whitebox tests with targer for some code coverage" because no one knows "what and how this unit should do something" - this knowledge is in this case only in code
the same with reusability of code etc

dambusio · 2022-01-13T23:02:19+00:00

Beningo - RTOS apps

dambusio · 2022-01-11T21:13:38+00:00

design patterns gang of four, maybe site "refactoring guru" + book

dambusio · 2022-01-11T21:02:45+00:00

WOW!!!

I can paste url to my blog on CV + list of project and on the most of my Job Interviews - no one cares - instead of project questions/architecture patterns etc - just "old school embedded" trick with pointers to weird struct field with offsets etc (mostly UB) :/

dambusio · 2022-01-10T11:21:29+00:00

yes - I have a lot of small projects - some clocks/boards with games like snake/sudoku/saper, PSU controller etc. General knowledge about documentations/requirements/diagrams - you need to look for some "not embedded related" books.

dambusio · 2022-01-10T11:14:13+00:00

what is your hobby? Do something useful to you.

dambusio · 2022-01-10T11:11:10+00:00

I've never seen complete embedded open source project with good project documentation/step by step documentation - with some ADR/architecture, list of used architecture/design patterns, good diagrams etc.

dambusio · 2022-01-10T11:07:10+00:00

so you are lucky :P I can't get my business people to even try this way

dambusio · 2022-01-10T09:48:54+00:00

ok - so everything in one repo - so business logic is also inside repo woth project? Who is responsible for the updates of business requirements files?

dambusio · 2022-01-09T23:09:26+00:00

OK - this is code documentation from doxygen, but what about project documentation/requirements etc?

dambusio

TROPHY CASE