Hi, 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. 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 Please test them, and check them in, if you are satisfied with it. Cheers, Niklas PS: If you want to generate some device files as well, here are the source files: https://www.dropbox.com/s/6nnph5pm9h3c9cm/STM_devices.zip https://www.dropbox.com/s/3xg3qgfjs6ds4y1/AVR_devices.zip
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
Hi,
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. I have committed a hand-optimized file for the 050/051 combination.
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.
Hm, currently the devices are not even merged by name. For example the 405 and 407 are also not merged. This was probably because the previous algorithm messed up there, I will have a look at it. Cheers, Niklas
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…
Hi,
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.
So, I adapted the merging code and now all STM32F devices are encoded in these 11 files: You can them it via this link: https://www.dropbox.com/s/mocxy5jbrth68ad/xml.zip Cheers, Niklas
participants (2)
-
eKiwi -
Niklas Hauser