Bus IO and UART definitions in processor file rather than in board file about adafruit_blinka HOT 9 CLOSED

its something we thought about but here's our reasoning:
each chip has specific pins that can do UART/I2C/SPI, etc. and those are fixed capabilities. each board may or may not have the DTO for that peripheral. we don't want to do DTO loading within Blinka, and people can change around the DTO. for example in raspi, there's a 2nd hardwaer SPI port, that most people don't enable, but we still have support for it in case they do. we use the special names in the board file 'SDA' 'MOSI' to hint the most popular hardware setups

thoughts?

from adafruit_blinka.

I agree that each chip has it's specified I/O, however they are almost always multiplexed and which of those is being used by a vendor or in a default Armbian configuration on a specific board is always different, The Tritium is using UART-1 on pins 8 and 10, the Orange Pi PC is UART-3 in that position, etc.

You get the same situation with Amlogic, the C2 and the "Le Potato" exposes UARTA on pins 8 and 10. NanoPi K2 exposes UARTC. Do you put both in the chip definition? And if you do, can those pins be used as normal GPIO at the same time? I haven't traced all the code, I'm just assuming defining the UART results in it being assigned a fixed function, meaning, to make sure the pin 8 and 10 uart is available on every pi-compatible allwinner board will result in boards like Tritium having 4 GPIO's tied up and blocking SPI1.

from adafruit_blinka.

ok now that i think of it - UART isnt actually something we'll be exposing thru blinka because we recommend people use pyserial because the names change a lot, even between distros. how about i2c/spi?

from adafruit_blinka.

I think for Allwinner/Rockchip you'll have SPI0 where you expect it. SPI1 is another matter, unless you just want to ignore it. Allwinner SPI1 lives on the same pins as UART3, so while the Tritium board can use the pin 8,10 UART and have 2 SPI ports available, the Orange can not. For Amlogic boards, SPI0 is often a software-defined port. I make them the same pins as RPi on my boards. I2C looks fairly uniform on the boards I have, the 1st I2C device is on pins 3,5, the second on 27,28. No one really cares much about the RPi standard to "reserve" that 2nd I2C channel, so it's your call to name it or not.

I'm not trying to shift your design strategy, just trying to point out any roadblocks. My interest always lies in more interesting embed-able designs like.

http://wiki.friendlyarm.com/wiki/images/3/30/Duo_pinout-02.jpg
or
http://wiki.friendlyarm.com/wiki/images/5/53/NEO_Core_pinout-02.jpg

Once some of the edges are smoothed I'll try one of those.

from adafruit_blinka.

yeah its one of those "ugh which decision is right? no way to know and both have downsides" type things :) we'll be thinking about it, part of adding support for a lot of linux boards is we're expecting to bump into all sorts of edge cases!

from adafruit_blinka.

well, that's sort of why I was asking this question: If you define all the pin names in the chip file, then define the "default" ports in the board file, each board can tell the library what is the preferred spi/i2c/etc. Then some kind of function to spit out "available resources".

On another note, this isn't new territory, a few other projects exist across Armbian boards, you guys just happened to pop up when I was getting my workshop/bench back in order, take a look around at the others and see what the approaches are. I'm hoping to consolidate all of the Armbian-targeted I/O projects into their own subforum.

from adafruit_blinka.

@tannewt any thoughts on how the split should go :)

from adafruit_blinka.

In CircuitPython the microcontroller.pin module has board-agnostic names like PA17 whereas the extra knowledge of assumed function (like labeled I2C) is done in board. board still is just friendlier names for pins. It doesn't encode peripheral to pin mappings.

Viability of I2C, for example, is determined dynamically by the I2C object and throws an exception if unsupported or the peripheral or pins are already in use.

Does that help? I'm not sure exactly what organization you are trying to organize.

from adafruit_blinka.

hihi ok so we thought about this a bunch and decided that we'd stick to the division we have now: even on complex chips, the i2c/spi peripherals are defined by the pin number itself, not the board layout. sometime all the pins are exposed on a board, but usually just a subset. which is the primary I2C should be set in board by naming that pin SDA or SCL - if there's a secondary I2C, those can be named SDA2 or SDA_ALT - if a pin isnt exposed on a board, it doesnt go into the board file so the enduser wouldnt be able to init that peripheral setup. and, if there's additional peripheral configs, they can use DTOs - something we'd like to stay away from in this library. UARTs are a different beast because they're accessed thru the /dev name and that name will vary a lot, but how to use it is documented, and our libraries are pyserial-compat.

we'll keep thinking about this as we make our way down the long list of of SBCs, but we think this is going to work better and will be easier for us to support :)

from adafruit_blinka.