[ell-i-developers] Re: PWM configuration

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

About counting there is no problem, as it can be simply adjusted
accordingly. About the problem of the garbage, is the default behaviour of
the linker / compiler to fill the empty elements with zeros?

With Warm Regards, Ivan Raul


On Fri, Jan 24, 2014 at 7:33 PM, Ivan Raul <supra.material@xxxxxxxxx> wrote:

> 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: