Hey,

On Fri, 2013-12-27 at 18:52 +0100, Niklas Hauser wrote:

I have updated the Device File Generator and it yields much better results now. With the exception of the newest devices (like the new ATmega88 or the STM32F429) all AVR and STM32 devices are now available.

This looks really promising.

Since I only want to include tested Device Files in xpcc, I will not check them all in, but make them available via Dropbox: https://www.dropbox.com/s/mocxy5jbrth68ad/xml.zip

I downloaded these files and checked some of the STM32 Files. Some of the STM32 files seem to be a little bit too redundant.

Let's have a look at the STM32F0:

diff stm32f051-c_k_r-4.xml stm32f051-c_k_r-6.xml ================================================

7,8c7,8 < <device platform="stm32" family="f0" name="051" pin_id="c|k|r" size_id="4"> < <flash>16384</flash> ---

<device platform="stm32" family="f0" name="051" pin_id="c|k|r"

size_id="6">

<flash>32768</flash>

10c10 < <linkerscript>stm32f0xx_4.ld</linkerscript> ---

<linkerscript>stm32f0xx_6.ld</linkerscript>

29a30

    <af id="1" peripheral="Uart2" name="Cts" type="in"/>

34a36

    <af id="1" peripheral="Uart2" name="Rts" type="out"/>

39a42,43

    <af id="1" peripheral="Uart2" name="Tx" type="out"/>
    <af id="1" peripheral="UartSpiMaster2" name="Mosi"

type="out"/> 44a49,50

    <af id="1" peripheral="Uart2" name="Rx" type="in"/>
    <af id="1" peripheral="UartSpiMaster2" name="Miso" type="in"/>

50a57,58

    <af id="1" peripheral="Uart2" name="Ck" type="out"/>
    <af id="1" peripheral="UartSpiMaster2" name="Sck" type="out"/>

105c113,116 < <gpio port="A" id="14"/> ---

  <gpio port="A" id="14">
    <af id="1" peripheral="Uart2" name="Tx" type="out"/>
    <af id="1" peripheral="UartSpiMaster2" name="Mosi"

type="out"/>

  </gpio>

108a120,121

    <af id="1" peripheral="Uart2" name="Rx" type="in"/>
    <af id="1" peripheral="UartSpiMaster2" name="Miso" type="in"/>

As you see most of the file is actually the same.

Even the STM32F050 and the STM32F051 files share a lot of common lines. (check the files with meld or something similar which shows much better than diff how much of the file is similar).

I think for the sake of disk space and readability it might be a good idea to try and improve the merging algorithm before we check in these files. For the STM32F0 I think a common file for STM32F050 and STM32F051 should be possible. This should still be easy for humans to read.

But thank you very much for the work you have done with the device file generator so far.

Kevin

So,

...

As you see most of the file is actually the same.

Even the STM32F050 and the STM32F051 files share a lot of common lines. (check the files with meld or something similar which shows much better than diff how much of the file is similar).

Currently, the algorithm only works on an entire GPIO, so even small differences in AF are seen as a completely different GPIO. Having a "second layer" of differences within one GPIO, will require some changes to the way the generator stores the differences.

It might be interesting to create a generic solution for this problem, but for now it is simpler to merge this by hand. The DFG is supposed to be a starting point for further manual optimisation, not a finished solution.

Scratch that, after a good night’s sleep and a brainwave in the morning, differences in AF can now be automatically described as well. The solution required placing the GPIOs and AFs into two separate flat lists and then bringing them together while writing, using existing code for generating the device id filters.

See this commit.

Now excuse me while I bask in the adulation of my numerous companions.*

Cheers. Niklas

*: I may have been watching Rango…