|Auto-Identify expansion boards||Dirk||4/17/09 11:50 AM|
It seems we get more and more expansion boards connected to Beagle's
expansion connector. Different expansion boards might need different
pin mux and other configuration changes in SW, e.g. in U-Boot and/or
From the discussion at this list and at IRC we learned that
But for this we need a way to make SW able to detect which expansion
Idea was now to have something like an I2C EEPROM on *each* expansion
What do you think?
If you like this, what do we have to standardize to make this work?
|Re: [beagleboard] Auto-Identify expansion boards||Gerald Coley||4/17/09 11:56 AM|
I think this is a good idea. I will work to come up with a standard on this from a HW perspective. It will be an I2C based EEPROM of the lowest cost I can find. Once I come up with that and the addressing, I will let everyone know.
We will need someone in the community to own the data format and how we format the data in the EEPROM.
|Re: [beagleboard] Re: Auto-Identify expansion boards||Hunyue Yau||4/17/09 12:12 PM|
Are there common, easy to source 1.8V I2C EEPROMs in reasonable packages
(SOT-23 or something leaded with a pitch >= 0.5mm)? I would hate have to
put level converters on a board just for the id ROMs. Otherwise, prehaps
a SPI EEPROM as level conversion for SPI is a lot simplier, but does burn
an additional pin. 1wire would be the fewest pins but that puts us back
into less then trivial level conversions.
|Re: [beagleboard] Re: Auto-Identify expansion boards||Gerald Coley||4/17/09 12:28 PM|
Using the SPI is out of the question as that would rule out using those signals for their other functions.
A 1 wire interface is not brought out to the expansion header so that rules that out.
So, the solution that does not burn any pins is the I2C. As you say they are easy to source and I will keep them at 1.8V. This does not preclude others from level shifting the downstream I2C, but it also does not force the addition of level shifters for the EEPROM.
|Re: [beagleboard] Re: Auto-Identify expansion boards||Dirk||4/17/09 12:34 PM|
Gerald Coley wrote:Do we need a "Beagle ready" logo for expansion boards which comply
with this standard, then? ;)
|Re: [beagleboard] Re: Auto-Identify expansion boards||Boris Houndleroy||4/17/09 12:34 PM|
Instead of making some new approach, why not just use the Bug Labs approach?
|Re: [beagleboard] Re: Auto-Identify expansion boards||Gerald Coley||4/17/09 12:36 PM|
Well, that may not be an bad idea, but I don't know if I can handle that. I just used up my last of 8 arms doing the EEPROM piece. Octo Man is all booked up!
|Re: [beagleboard] Re: Auto-Identify expansion boards||Gerald Coley||4/17/09 12:38 PM|
|Re: Auto-Identify expansion boards||Preston Wilson||4/17/09 12:40 PM|
How will this work with multiple (stacked) cards? Or is that off
I hate throwing this out there, as I have to leave, and I won't be
able to participate again until much later.
I think it is a good idea, and I have built two expansion cards, so I
have an interest in what is chosen.
> On Fri, Apr 17, 2009 at 2:34 PM, Dirk Behme <dirk.be...@googlemail.com>wrote:> > > On Fri, Apr 17, 2009 at 1:50 PM, Dirk Behme <dirk.be...@googlemail.com
|Re: [beagleboard] Re: Auto-Identify expansion boards||Gerald Coley||4/17/09 12:44 PM|
Nice way to keep the conversation going! I would like to be able to handle this. The rub here is the addressing. Let me think on ths and see how we can manage it. I know a way, but I need to see how it flows in a practical implementation. Can we set a limit of two stacks?
|Re: [beagleboard] Re: Auto-Identify expansion boards||Gerald Coley||4/17/09 12:57 PM|
I have a suggestion. We come up with 8 classes of boards, one for each address. Such as LCD, communications, IO, etc. Each class will have its own address. The restriction would be that only one board form each class of board could be plugged in at any one time, but all classes could have at least one plugged in at a time. I honestly don't see us having eight boards at a time.
Inside the EEPROM will be kept the resources each board needs. That way we know how to configure the expansion pins on the processor. We could, if we wanted to go this far, also have in there, the functions the board provides, such as serial ports, LCD size, SD/MMC. WLAN, etc.
On Fri, Apr 17, 2009 at 2:40 PM, Preston Wilson <rpwil...@gmail.com> wrote:
|Re: [beagleboard] Re: Auto-Identify expansion boards||Nishanth Menon||4/17/09 1:33 PM|
On Fri, Apr 17, 2009 at 2:57 PM, Gerald Coley <ger...@beagleboard.org> wrote:
FYI - we did something like this with SDP (from SDP2430 onwards) to
IMHO, great idea -> but maintenance is more important than the data structures..
|Re: [beagleboard] Re: Auto-Identify expansion boards||Gerald Coley||4/17/09 1:43 PM|
Yes, I know. That is exactly why I did not volunteer to keep up with it. But, nonetheless, I think we can limit this a lot more than the SDP did. Where the SDP had 3 or 4 boards, we just have the Beagle. So, this is limited to I/O boards.
Another way to do this, is to have each board contain the settings for the Expansion header. The UBoot reads it and sets the pins as required. It does not care about what is on the expansion board or what it is doing. With a common document, anyone can program their EEPROM as needed to work with the common UBoot. If someone wants to use two or three cards, it is up to them to set the information as needed into the EEPROM. This could then remove the need for keeping track of everything. We just have a function in UBoot that allows the user to program the EEPROM. We could then also include as well, the functions on the boards for the higher level OS functions, such as the driver loading.
The more flexible you make it, the complicated it gets.
|Re: [beagleboard] Re: Auto-Identify expansion boards||Boris Houndleroy||4/17/09 2:05 PM|
|Re: [beagleboard] Re: Auto-Identify expansion boards||Gerald Coley||4/17/09 2:12 PM|
The problem is that BugLabs has a dedicated I2C per slot. We only have one I2C port. Plus, the BugLabs bus is not configurable. The pinout of the Beagle bus calls for the functions of the pins to change complete functions based on the muxing options needed. It might be possible to use the BugLabs interface, but I would think the contents and the way we use that information would need to change. .
|Re: [beagleboard] Re: Auto-Identify expansion boards||Dirk||4/17/09 11:39 PM|
Gerald Coley wrote:I vote for Nishanth's KISS rule. Just an ID, everything else can be
done in SW (e.g. tables indexed by this ID). Even the board revision
proposed by Nishanth I would omit. New board revision which needs an
other configuration? -> New ID.
But I would add a magic to be sure that the device is identified
1) Bytes 0 - 3: Magic (e.g. 'BEAG' or 'EXID')
2) Bytes 4 - 8: ID
3) Bytes 9 - ..: Vendor specific
|Re: Auto-Identify expansion boards||Preston Wilson||4/18/09 5:59 AM|
I like this variation, but I am not the one that will keep track of
the IDs. Probably obvious, but setting aside a small set of IDs for
testing/private use would be nice.
I also like the I2C address per board class to solve the multiple card