[ell-i-developers] Emulating uint32_t -- not an option, will define preg32_t and preg16_t instead.
- From: Pekka Nikander <pekka.nikander@xxxxxx>
- To: "ell-i-developers@xxxxxxxxxxxxx" <ell-i-developers@xxxxxxxxxxxxx>
- Date: Mon, 17 Feb 2014 17:38:30 +0200
>> IIRC for the emulator you overload uint32_t to generate the output, or
>> something similar.
>
> Not yet, but that's the plan. Each uint32_t object would know its address,
> and also if it is a part of a peripheral, or what kind of memory it is.
Last night and today I tried to replace uint32_t with a class of the same name,
to be able to keep better track in the emulator who the program code writes
memory and peripherals.
Unfortunately that didn't work out, mainly due to complications created by
stm32f0xx.h defining uint32_t bitfields. I tried to work around them, but
couldn't find any clean and easy solution. Hence, at the moment I'm abandoning
the idea of emulating uint32_t.
Instead, my current plan is to introduce a couple of new data types, preg32_t
and preg16_t, for peripherial registers, 32 and 16 bits wide. On the real
hardware those would be simply volatile uint32_t and volatile uint16_t. On the
emulator, however, those would be objects that keep track of which register
there is. Hence, in the emulator a reference through a preg32_t would trigger
the emulator code, spitting out traces, so that we can better keep track of
what's going on also when the peripheral registers are accessed indirectly.
If anyone dislikes the names, now it is the time to propose alternative names.
If everything goes well I'll implement them tonight and push tomorrow.
After that I can continue with the SPI code with some more confidence, as I'll
see better what is going on.
--Pekka
Other related posts:
