[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.


Other related posts: