-
Notifications
You must be signed in to change notification settings - Fork 17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
for any user requests for board support (pins_arduino.h) #7
Comments
I've generated pins_arduino.h and boards.txt entry for 128A4U. Not 100% tested yet, but so far, code doing digitalWrites and TWI on port C works as expected. |
Thanks, I'll have a look at it. I'm already working on board support for a 128A4U by the way, but the pin assignments have to be re-arranged properly because of the 2 USB pins on PORT D. I'll see what you've done and consider whether I should assign a different name to it [rather than the generic implementation], or give mine a different name. The main thing here is how to deal with the USB pins (PORT D 6 and 7 if I remember correctly) and how to map digital I/O to them, if at all. The best thing about 128A4U is that it is has a TQFP with a layout that matches the 64D4. And, were it not for the two USB pins, you could actually use the same pins_arduino.h file. Anyway, there also needs to be a reasonable level of compatibility to "Genuino" Arduino layouts and shields. So all of that goes into the analysis too. Anyway I haven't looked at yours yet but I wanted to mention all of this up front. |
one more thing, do you you already have hardware that uses that pins_arduino.h file in the layout? if so I can name the variant according to your board design. |
Yes, I do have a board (I've seen your initial work, but it did not go far enough for me, I needed one to work now). I won't be using shields, so I made the pins file following the order in which the resources appear in the datasheet (USARTC0 is the default Serial, USARTC1 is Serial1, USARTD0 is Serial2...) USB shares pins with SPI1... I am with you on boards with generic names. If it is for community use, it needs to be compatible with shields, and mine is certainly not that; weve started a clean-slate one, and without the need for shields, numbered things from the top... So, sure, if you want to keep mine in (works with what I tested - digital in/out, TWI, SPI), name the variant DFE XMEGA128A4. The bootloader, I forgot to mention, is the Atmel's one. Mine is there for completeness and for user-side firmware update, but I have not find out how to use it to upload code from Arduino IDE :) Will probably switch to yours once it's ready. |
OK thanks - I'll probably wait a bit to finalize my own version of the 128A4U and add both of them at the same time. The variant directory name would probably be 'DFE-XMEGA128A4' (no embedded spaces, they cause WAY too much trouble, especially on POSIX systems when you live in the command line like me) though I'd prefer to use something that isn't all upper case like that, maybe DFE-XMega128A4, and maybe use a '_' or '.' rather than a dash, where you had a white space in the name (that kind of thing). Embedded spaces can go in the 'boards.txt' file of course, to describe the variant, but not in the directory names. Names with spaces in them - that's a "windows thing" that should've never been born. |
This is an open issue to which you can submit requests for board support, in the form of a pins_aduino.h file within a particular directory in 'variants'. At a minimum I will need to know what the correct pin mapping should be, i.e. digital 0 maps to PORTD pin 2 (for example), in some easily readable format.
You can post text descriptions here.
[at some point I may create a mapping generator to create the header file based on a particular format]
The text was updated successfully, but these errors were encountered: