attiny412 support #26
Comments
|
Yes,
I don't see a problem with that, it should work just fine. Are you interested in taking a stab at adding the support yourself? I can guide you through it if you want. Word of caution if you don't yet have the avr-rust toolchain set up: There's quite a few pitfalls still, you need the |
|
Perfect, thank you. At the moment I'm to busy, but I'll give it a try in a month. I think your "instruction" is quite self-explaining, but if I get trouble I'll ask you :) |
|
Sounds good, thanks a lot! :) |
|
I'm at the moment trying to include the attiny412. However, on compiling atdf2svd fails: The new tiny series has completely different peripherals (and thus also pin descriptions). My changes to |
|
It looks like this chip does not follow the standard register layout for IO ports. We'll have to fix |
I think this affects all chips with the avrxmega3 core, in special the chips I wanted to port of the tinyAVR 1-series & tinyAVR 0-series. |
|
I see ... So, it's failing in the Now, I don't know much about the MCUs you're referencing, so maybe you can give some insight: Do we need to apply this 'post-processing' (in some modified form) as well, or does the ATDF file correctly name all pin fields already? Additionally, these two messages: probably relate to Rahix/atdf2svd#4, so you'll also need this issue resolved I guess ... |
|
I think its necessary. If I look at the atdf of the bigger AVR128DA28 (the ATtiny412 has only one port, spi, twi, ...), it seems that there is one module including the different PORTn: And then one with the registers of the PORT: |
|
Okay, I'd say the best way to deal with this is a whitelist approach. So the patch should only touch registers named
What do you think? |
|
Yes, I think this should work (but not 100% sure if this is the only place were the scheme differs). For the 'new' scheme: These registers are listened only once in the atdf, but each port has them. So basically it is needed that each port gets a "copy" of all those registers. Maybe an additional atdf2svd flag can be set for the avrxmega3 architecture and in the Makefile the targets could be split in two groups (traditional and avrxmega3), where the avrxmega3 uses atdf2svd with the flag set. In this way the whitelist has not to be in the atdf2svd. Or atdf2svd automatically recognizes which family the atdf belongs to (if it finds DIR, DIRSER, ... use 'new' scheme). |
If I'm not mistaken, this is already working. But we'll have to check, of course.
IMO it would really cool if atdf2svd can figure this out on its own so you can't accidentally forget the flag. But if that's not reliably possible, your idea is the way to go, I'd say. |
|
Very cool to see people working on support for the newer series of AVR. I have been looking at adding support for these newer chips too. For detecting version I think it might be possible to use the Another attribute that might work is the There is also an issue that module list contain the |
Would adding a fall-back for the other tag fix this, or is a more elaborate distinction needed? |
Yes a fall-back does seem to be sufficient. So I don't think something more elaborate is necessary at least for now. |
|
Are there any updates to this? |
|
Let's make a list of necessary work in
For minimal support, fixing just the first one should be a good start. For supporting more peripherals, the rest (especially the 3rd one) are needed. |
Rahix
added
mcu-support
|
I now released version 0.2.0 of |
Hi
I would like to have support for the attiny412. As it is a MCU of the new AVR-1 series, will it work with your tool?
Also am I understanding correctly, that this crate is providing something similar to the "PAC" crates for the different cortex-m MCUs?
Best,
trembel
The text was updated successfully, but these errors were encountered: