> On 13 Jun 2015, at 21:29, Peter Crosthwaite <peter.crosthwa...@xilinx.com>
> wrote:
>
>
> ... As all the information
> you need to construct the object is constant per-concrete class, the
> information can be added to the class to resolve.
the one-instance-per-class might be true for MCUs, but generally it isn't, for
example the LED object, you can have several LEDs in a machine, all having a
common class, but different instances. similarly for GPIOs.
so, no, the class structure is not suitable for multi-instances objects, and
even for singletons I think that using it for passing such configuration data
is generally abusive.
>> static STM32Capabilities stm32f103rb_capabilities = {
>> .cortexm = {
>> .device_name = TYPE_STM32F103RB,
>
> Why is the capabilities struct aware of its container type?
ah, just for having the information available for verbosity. here is a typical
run for a simple blinky application:
GNU ARM Eclipse 64-bits QEMU v2.3.50 (qemu-system-gnuarmeclipse).
Board: 'STM32-H103' (Olimex Header Board for STM32F103RBT6 (Experimental)).
Device: 'STM32F103RB' (Cortex-M3, MPU), Flash: 128 KB, RAM: 20 KB.
Image: '/Users/ilg/My Files/MacBookPro Projects/GNU ARM Eclipse/Eclipse
Workspaces/qemu-images-44-osx/f1-h103-blink-sh-shd/Debug/f1-h103-blink-sh-shd.elf'.
Command line: 'cm3 4' (5 bytes).
Cortex-M3 core initialised.
Cortex-M core reset.
main(argc=2, argv=["cm3", "4"]);
Hello ARM World!
Standard output message.
Standard error message.
System clock: 72000000 Hz.
[Green LED Off]
[Green LED On]
[Green LED Off]
Second 1
[Green LED On]
[Green LED Off]
Second 2
[Green LED On]
[Green LED Off]
Second 3
[Green LED On]
[Green LED Off]
Second 4
QEMU exit(0)
> Why do you need to make it one giant struct with its own inheritance
> hierarchy? With the class idea, you would just split this to two
> structs for cortexm and stm32.
sure, this can be done, but when using constructors, this requires passing two
pointers instead of one.
regards,
Liviu
