c - How to structure source code for embedded software -
in trying improve embedded software skills (in procedural c, using c++11 features), learn optimal ways structure/package source code embedded systems.
i working on building small scale systems (on single microcontollers 1-k4k ram memory) without rtos. in order able debug software outside target environment, emulate system on host computer.
i found out standard store information processor , internal devices (ram, rom, timers, etc.) in board support package.
but in embedded project use other external devices (push buttons, leds, lcd, servos, io multiplexer, etc.) connected using pcb microcontroller. what standard way/standard name source code abstraction layer on application specific pcb?
i have searched in books on real-time system engineering (david simon's an embedded software primer, jim cooling's software engineering real-time systems , laplante's real-time systems: design , analysis), unable find reference code structuring in embedded systems.
according wikipedia entry bsp, purpose provide board support (not micro) required specific os. same hardware, different os require different bsps, don't think that's term you're after.
what describe call hardware abstraction layer/hal, , believe quite common name. in principle, name include whole pcb, or mcu.
the important bit in hal abstraction. abstraction make easy replace, e.g. if want test code built on top of hal off-target. make easier port code different hardware platform.
i find many vendor-provided libraries fall short in regard: may call function instead of modifying or reading registers directly, function call corresponds directly registers. is, library may hide behind abstraction compiler extensions necessary interface chip, not else. because of this, tend not use vendor-provided library hal, may use implement 1 (or access registers directly instead)
the optimal structure hal depends on design goals. you've stated 1 goal of being able debug application off-target. you've stated don't plan run os. may planning support single mcu or mcu family, or multiple mcus different vendors. may planning single board design, or multiple bespoke boards based on common platform. these affect design choices in hal design.
i work on projects don't use rtos. typically hardware inherits aspects 1 or more older designs , has new stuff. new stuff can small or big changes (including different mcu or mcu families).
in context, approach hal has developed following:
define api each component in hal, (typically structs of pointers-to-function, such
adc_driver_api_t
,uart_driver_api_t
,i2c_driver_api_t
etc.). these apis not use chip/compiler extensions or includes, typically adhere language standard (c89/c99).the hal given platform provides implementations these, e.g.
msp430_adc12_driver
,msp430_adc10_driver
,pic18_adc12_driver
,avr_adc_driver
etc implementsadc_driver_api_t
interface using different peripherals available on respective platforms. each implementation expose const global instance of implemented driver in implementation header file, e.g. (using c)extern const adc_driver_api_t msp430_adc12_driver;
. these implementations use chip/compiler extensions or includes required.a component using hal adc readings initialised
const adc_driver_api_t *
implementation , else api requires (perhaps adc channel). component , adc driver implementation both initialised , connected in program initialisation, e.g. top ofmain()
i try keeping hal api lean. instance, peripherals may allow put 12-bit result in top 12 or bottom 12 bits of 16-bit register. not allow configuring via hal api, may provide function set directly in module implements hal api, in msp430_adc12_driver.h there may function
msp430_adc12_driver_set_result_alignment()
can called during system initialisation.
i find approach allows components built on top of hal in hardware-independent way, can reuse components on different platforms. allows components written, debugged , unit test components off-target, test doubles hal.
Comments
Post a Comment