[ell-i-developers] Re: PWM configuration

  • From: Ivan Raul <supra.material@xxxxxxxxx>
  • To: ell-i-developers@xxxxxxxxxxxxx
  • Date: Fri, 24 Jan 2014 19:33:37 +0200

You are right, that would save a lot of memory space, as the offsets are
small enough for 8 bits. Then, I assume that for using the current data16
no address approach, one should write all the registers in serial fashion,
with their reset values for preventing the initialization routine to write
trash to the registers in between. Still another problem is the array
count. The system right now counts all the elements, because the macros
save in a sparse array.

With Warm Regards, Ivan Raul


On Fri, Jan 24, 2014 at 7:27 PM, Pekka Nikander <pekka.nikander@xxxxxx>wrote:

> > Still, what do you suggest to do with the large array that is generated
> right now, do you suggest to change to adding the offset to the struct of
> the SystemInitRecordData16NoAddress, the problem with the current
> implementation is that if the first two 16b registers are written, as there
> is one 16b register reserved in between, the array turns to be 3 elements,
> instead of 2. It just gets worse when the registers are very far from each
> other.
>
> Yes, you are right.  Your proposed data16 + offset is also good, for
> sparse arrays.  It should be implemented as a new subtype, perhaps
> data16_and_offset or something like that.
>
> It might even be better to have the data and offsets not intermixed but in
> separate memory arrays, like this:
>
> 0      +-----------+
>        |   data0   |
> 2      +-----------+
>        |   data1   |
> 4      +-----------+
>        .           .
>        .           .
> 2n-2   +-----------+
>        |   datan-1 |
> 2n     +-----+-----+
>        | a0  |  a1 |
> 2n+2   +-----+-----+
>        | a2  |  a3 |
> 2n+4   +-----+-----+
>        .           .
>        .           .
> 3n-2   +-----+-----+
>        | an-2|an-1 |
> 3n     +-----+-----+
>
> That would save n bytes compared to the implementation where the data and
> offsets are next to each other, as that would pad the 8-bits offset with
> another 8 bits.
>
> Though it would be quite tricky to write the initialisation macros for
> such an approach...
>
> --Pekka
>
>
>

Other related posts: