[RFC] Multiple devices on BeagleBoard expansion bus

GoogleGroups
1

I'd like to propose having an additional address for the EEPROM that
describes the devices connected to the BeagleBoard expansion bus[1].
Today, we read that EEPROM at address 0x50 on I2C bus #2 (second one,
ie. "i2c dev 1" in u-boot, "i2c dev 2" in u-boot is actually the DVI-D
I2C port). I'd like to add a check at address 0x51 for an expansion
board that provides connections to existing expansion boards. Pins
requested by the EEPROM at 0x51 would override requests for pins from
the expansion board specified by the EEPROM at 0x50.

Of course, some combination of boards won't work or will result in
functionality being lost. Some error handling in u-boot or in the
kernel could be added to notify the user of such events, but that
should mostly be handled by the hardware documentation. The point of
doing this is so that boards that *could* work, will work. An example
of such a combination could be a BeagleBoard Showdog LCD board[2] and
a TinCanTools BeagleBoard Trainer[3]. Actually, looking at the
Showdog design, it (wisely) doesn't touch anything on the expansion
header so there wouldn't be any need to have this other EEPROM, but if
it did use a few pins to get a few GPIOs not otherwise available on
the LCD expansion header, imagine that it might want to configure the
mux a bit differently. :slight_smile:

What do you think?

[1] http://elinux.org/BeagleBoardPinMux#Vendor_and_Device_IDs
[2] http://elinux.org/BeagleBoard_Showdog
[2] http://elinux.org/BeagleBoard_Trainer

2

Jason,

0x57 might be a better choice. basically this means that for boards at
0x50, the last three bits are pulled low to ground, and with 0x57
means the last three bits are pulled high to Vcc.

most of the small sot23-5 i2c eeproms are fixed at 0x50, so for the
"overide" eeprom you will need to use one of the eeproms that has
address configuration options.

the code change i have suggested for u-boot would first look at 0x57
and then at 0x50 for configurations.

Dave

3

Quoting Jason Kridner <jkridner@beagleboard.org>:

I'd like to add a check at address 0x51 for an expansion
board that provides connections to existing expansion boards. Pins
requested by the EEPROM at 0x51 would override requests for pins from
the expansion board specified by the EEPROM at 0x50.

Something like that would remove all plug and play capabilites because you'd have to program an eeprom with your current hardware setup (and therefore you are able to place erroneous setups by accident). That would be a great step back in my opinion.

I think the main problem we face in the existing solution is, that there is no chance to either daisychain devices nor allocating adresses dynamically on I2C in an easy way. Maybe that point should be adressed somehow?

What about building an expansion board that works as an "Expansionboard multiplexer"? This would give you greater a flexibility and you can preserve the plug and play feature. It also does not force to place busdrivers or something on your expansion boards to make sure you can always resolve conflicts.

Of course, some combination of boards won't work or will result in
functionality being lost. Some error handling in u-boot or in the
kernel could be added to notify the user of such events, but that
should mostly be handled by the hardware documentation.

Actually the whole Expansionboard handling in kernel and u-boot is in my opinion somewhat broken. The whole discussion regarding this topic[1] drifted over to pure hardware, totally neglecting the software part. The OP stated correctly that putting all companion boards in board-omap3beagle.c file will not scale nor is it practical to use.

I have an idea to simplify the whole pinmux stuff, but I did not have the time yet to write it down. My thoughts go towards expanding the board info available in the eeprom by a several informations about pinmux requests from the expansion board. This would allow to do some generic code for pinmuxing in the kernel which all boards can benefit of => So there would be no need for modifying the kernel to get a new expansion board working.

In my opinion it should be avoided to bloat the kernel code with some sort of "conflict resolution". Automatic conflict resolution always shows, from the users point of view, some pseudo arbitrary behaviour. I will guarantee that every third user will not like the way the kernel solves conflicts and is therefore forced to change the code or the parameters passed to the kernel.

[1] http://groups.google.com/group/beagleboard/browse_thread/thread/36fea66b7585868d

4

Jason,

0x57 might be a better choice. basically this means that for boards at
0x50, the last three bits are pulled low to ground, and with 0x57
means the last three bits are pulled high to Vcc.

This seems arbitrary to me.

most of the small sot23-5 i2c eeproms are fixed at 0x50, so for the
"overide" eeprom you will need to use one of the eeproms that has
address configuration options.

Understood.

the code change i have suggested for u-boot would first look at 0x57
and then at 0x50 for configurations.

I can see either one making sense. Isn't it just as easy to change 1
pin as it is 3?

5

Quoting Jason Kridner <jkridner@beagleboard.org>:

I'd like to add a check at address 0x51 for an expansion
board that provides connections to existing expansion boards. Pins
requested by the EEPROM at 0x51 would override requests for pins from
the expansion board specified by the EEPROM at 0x50.

Something like that would remove all plug and play capabilites because you'd
have to program an eeprom with your current hardware setup (and therefore
you are able to place erroneous setups by accident). That would be a great
step back in my opinion.

Why would it break plug-and-play capabilities? Existing expansion
boards would use the 0x50 EEPROM--so nothing would change there. New
expansion boards that don't pass the expansion pins (termination
boards) to a new connector would similarly stick to 0x50. Only new
boards that utilize a few pins and then pass on connections to other
expansion boards (intermediate boards) would use this new 0x51 (or
perhaps 0x57) address. Currently, there'd be no way to reserve the
pins used by the intermediate board and still recognize the pin
requests of existing expansion boards. This proposal would fix that
and enable boards that could work in combination to work.

The EEPROMs would come programmed by the hardware vendor, just as they do today.

I think the main problem we face in the existing solution is, that there is
no chance to either daisychain devices nor allocating adresses dynamically
on I2C in an easy way. Maybe that point should be adressed somehow?

Intermediate boards would always use the new address. I doubt we want
to go many additional layers deep as signal integrity gets to be an
issue. The ability to go another level deep is part of why I was
suggesting 0x51 rather than 0x57. If we decide, we could just scan
from 0x57 down to 0x50 in the software to see what is connected to the
expansion bus.

Dynamically setting the EEPROM address based on topology sounds
intriguing, but I suspect that we'll have wanted to build boards that
were designed to attach to expansion boards "down stream" for anything
to ever work.

Do you think we need to deal with the possibility of boards that are
configured to be stacked as many as you might like, ie. true daisy
chaining of the boards? If this is the case, then we'd need some way
for the bus to tell us we are +1 down in the chain. I don't see an
easy way for the existing bus to provide that for us. Using EEPROMs,
I think we'll also be practically limited to 8 EEPROMs very quickly
due to addressing. If a board is designed to be daisy chained, is it
reasonable to request it be build with jumpers to specify the address
from 0 to 7? Is that enough? Is it at all practical to think of any
chain longer than that on this very limited bus?

What about building an expansion board that works as an "Expansionboard
multiplexer"? This would give you greater a flexibility and you can preserve
the plug and play feature. It also does not force to place busdrivers or
something on your expansion boards to make sure you can always resolve
conflicts.

That would add a lot of cost onto that board. If you are doing this,
you can deal with the software complexity as part of that board and in
higher levels of software, rather than putting it back on this simple
u-boot infrastructure.

Of course, some combination of boards won't work or will result in
functionality being lost. Some error handling in u-boot or in the
kernel could be added to notify the user of such events, but that
should mostly be handled by the hardware documentation.

Actually the whole Expansionboard handling in kernel and u-boot is in my
opinion somewhat broken. The whole discussion regarding this topic[1]
drifted over to pure hardware, totally neglecting the software part. The OP
stated correctly that putting all companion boards in board-omap3beagle.c
file will not scale nor is it practical to use.

Agreed. We'll eventually need to train u-boot to build up device tree
entries. It would have been nice to put more intelligence into the
EEPROM contents, but I expect we'll be able to codify in u-boot the
boards that are specified up to the time we can specify something more
complete to producing device tree entries.

I have an idea to simplify the whole pinmux stuff, but I did not have the
time yet to write it down. My thoughts go towards expanding the board info
available in the eeprom by a several informations about pinmux requests from
the expansion board. This would allow to do some generic code for pinmuxing
in the kernel which all boards can benefit of => So there would be no need
for modifying the kernel to get a new expansion board working.

Please include device tree in your considerations.

In my opinion it should be avoided to bloat the kernel code with some sort
of "conflict resolution". Automatic conflict resolution always shows, from
the users point of view, some pseudo arbitrary behaviour. I will guarantee
that every third user will not like the way the kernel solves conflicts and
is therefore forced to change the code or the parameters passed to the
kernel.

Again, check out device tree and see if you are aligned with the rest
of the community pushing for that to be the future solution. There
were some recent patches sent out for device tree on the BeagleBoard
and it would be great to have more users examine that approach.

6

On Fri, Jul 15, 2011 at 4:06 AM, Ueli Niederer

<SNIP>

>
> Actually the whole Expansionboard handling in kernel and
> u-boot is in my opinion somewhat broken. The whole
> discussion regarding this topic[1] drifted over to pure
> hardware, totally neglecting the software part. The OP
> stated correctly that putting all companion boards in
> board-omap3beagle.c file will not scale nor is it practical
> to use.

Agreed. We'll eventually need to train u-boot to build up
device tree entries. It would have been nice to put more
intelligence into the EEPROM contents, but I expect we'll be
able to codify in u-boot the boards that are specified up to
the time we can specify something more complete to producing
device tree entries.

> I have an idea to simplify the whole pinmux stuff, but I did
> not have the time yet to write it down. My thoughts go
> towards expanding the board info available in the eeprom by
> a several informations about pinmux requests from the
> expansion board. This would allow to do some generic code
> for pinmuxing in the kernel which all boards can benefit of
> => So there would be no need for modifying the kernel to get
> a new expansion board working.

Please include device tree in your considerations.

The whole idea that if a device is present, it must use a given
pinmux configuration is broken. The pinmux configuration needs to
be requested by the choice of drivers to attach. Consider the
following -
A touchscreen LCD combo board.
The most obvious pinmux setting for this is DSS output on all
lines, GPIO for the interrupts and the backlight and prehaps the
McSPI pins.

This is not the only pinmux configuration that is suitable or
desired.

Software might for some odd reason want some of the DSS lines
muxed as GPIO (i.e. provide a hardware assisted way of doing a
binary brightness control.) The GPIO for back light might not
muxed as GPIO - it might want to be setup as PWM for HW assisted
brightness control. Similarly, the McSPI pins might not want to
be McSPI; there is a bitbang SPI driver.

It all comes down to what the end user wants to do. Doing a 1:1
mapping between HW and pinmux configuration throws away too many
options.

Other reasons for the pinmux to be different could be power
management (drive or not drive during off mode) or a default
high/low (say, default the LCD backlight to on or off).

Another consideration regarding putting pinmux info into the
EEPROM is using the same expansion board for different boards.
There are minor difference between xM/class but what about other
boards like the Panda cousin where the pinmux mappings are just
plain different but can be configured for electrical and physical
compatiblity.

7

Hi,
  I expect you guys have been all over the I2c spec's but just as a
reminder
I would like to comment on some things.

  While impractical it seems Phillips NXP would like everyone wanting
to
utilize a I2c slave address to register and pay.
http://www.nxp.com/products/interface_control/i2c/support/requestform/support_tools/

I also find they won't divulge their existing I2c slave address list:
http://www.nxp.com/products/interface_control/i2c/faq/

I am not advocating registration here. What point I would like to make
is
that it is easy to trample on others selected I2c slave addresses.
Somehow
address 0x50 was chosen for Beagleboard to use to identify addon
boards. This seems
fine on the surface. Now Jason is polling for more address space
usage. This
too seems reasonable. However, we are getting into a "who's on first"
situation. I have no idea what all addresses are in use and registered
nor those
that go unregistered. I do know that a project I did recently with
Nintendo I2c
devices utilize 0x52 - 0x54. Now if we had access to all three I2c
buses this
"who's on first" thing could simply be moved to another buss. As I
read the
SRM we only get I2c on the expansion header. And I know the
TrainerBoard
already uses it for its friendly expansion.
   The Nintendo devices are regarded highly for their inexpensive use
of
joystick, button, accelerometer, gyro, drums, guitar and turntables.
While I realize this might not be motivation for further consideration
of
I2c slave address trampling I just felt it important to bring up for
thought.

Don Lewis

8

Quoting djlewis <djlewis@tcworks.net>:

  I expect you guys have been all over the I2c spec's but just as a
reminder
I would like to comment on some things.

  While impractical it seems Phillips NXP would like everyone wanting
to
utilize a I2c slave address to register and pay.

As far as I know, this is only true if you want to build your very own device and write I2C on it. (That's the reason why Atmel calls it TWI (Two Wire Interface) ) But you don't have to pay if you are just using a device that complies the I2C standard.

I am not advocating registration here. What point I would like to make
is that it is easy to trample on others selected I2c slave addresses.
Somehow address 0x50 was chosen for Beagleboard to use to identify addon
boards.

Well I think "somehow" in this case means 0x50 was chosen due to the fact the proposed Atmel EEPROM (AT24C01B has exactly this preamble for it's device address, leaving the last 3 bits of the address to be configured by user what results in the address bandwith of 0x50 to 0x57 where we can freely chose as long as we use the Atmel EEPROM (or any other eeprom with 0x50 präamble) as identifier storage.

regards
Ueli

9

Quoting Hunyue Yau <ybeagle@rehut.com>:

The whole idea that if a device is present, it must use a given
pinmux configuration is broken.

That was not my proposal.

The pinmux configuration needs to be requested by the choice of drivers to attach. [...]
The most obvious pinmux setting for this is DSS output on all
lines, GPIO for the interrupts and the backlight and prehaps the
McSPI pins.

Yes you are right and due to the fact the driver can do something really nasty to the pinmuxing it has to be checked through a low level instance.

Software might for some odd reason want some of the DSS lines
muxed as GPIO (i.e. provide a hardware assisted way of doing a
binary brightness control.)

What ever the software wants to do is limited to the capabilities the hardware can offer. Whenever the Software wants to do something "odd" it should be doublechecked if the hardware could afford that.

It all comes down to what the end user wants to do. Doing a 1:1
mapping between HW and pinmux configuration throws away too many
options.

That was not my proposal either. I was rather thinking of some "Pinmux capabilites adertisement" in the EEPROM. So the Hardwaredesigner is able to tell the Software what he designed the board for and if he's happy if the software uses DSS lines as GPIO. The point is: We are talking about dynamic interfaces here but they are still interfaces. And I think the hardware should tell it's limitations regarding the interface to the software.

But you are right. Choosing from the advertised pinmux in the board init would not be the best solution either. But doing it elsewhere would result in creating sort of a subsystem presenting pinmux capabilities to dependent board drivers but still checking if a requested pinmux is allowed.

Actually this part of kernel hacking is new for me and I'm confused because there is no guideline how to do or who does pinmuxing. In Kernel 2.6.32 for example some pinmux is done in board init, some other pinmux seems to be done if you request GPIOs but I did not find any document describing the _correct_ way doing this.

Another consideration regarding putting pinmux info into the
EEPROM is using the same expansion board for different boards.
There are minor difference between xM/class but what about other
boards like the Panda cousin where the pinmux mappings are just
plain different but can be configured for electrical and physical
compatiblity.

Who said, we should put the pinmux register`settings suitable for DM3730 or any other processor in the EEPROM?
Of course my plan was not to include the register settings in the EEPROM for copy them right out of the EEPROM into the Pinmux register. This should be done in a more abstract way so the "interface standard" could be reused in another context. As you stated there can be other boards using the same interface standard but not the same processor maybe not even OMAP.

Regards
Ueli

10

Hi Jason

Sorry for answering you as the last though you were the first one replying to my e-mail, but I wanted to answer in order of the length of my reply. And yours was the longest :slight_smile:

Quoting Jason Kridner <jkridner@beagleboard.org>:

Quoting Jason Kridner <jkridner@beagleboard.org>:

I'd like to add a check at address 0x51 for an expansion
board that provides connections to existing expansion boards. Pins
requested by the EEPROM at 0x51 would override requests for pins from
the expansion board specified by the EEPROM at 0x50.

Something like that would remove all plug and play capabilites because you'd
have to program an eeprom with your current hardware setup (and therefore
you are able to place erroneous setups by accident). That would be a great
step back in my opinion.

Why would it break plug-and-play capabilities? Existing expansion
boards would use the 0x50 EEPROM--so nothing would change there. New
expansion boards that don't pass the expansion pins (termination
boards) to a new connector would similarly stick to 0x50. Only new
boards that utilize a few pins and then pass on connections to other
expansion boards (intermediate boards) would use this new 0x51 (or
perhaps 0x57) address.
[...]
The EEPROMs would come programmed by the hardware vendor, just as they do today.

Ok, I think I misunderstood. I thought you were propagating to put a "Board Stack descriptor" on address 0x51. But obviously that was not your proposal.

If I got you right this time, you are simply propagating the idea of another board identification address for boards not using the whole interface you call "intermediate board".
Well maybe I overlooked something else or did not get the whole picture, but wouldn't this approach lead to two new limitations? In fact you can only have ONE board with Adress 0x51 and ONE with Address 0x50. Everything else leads to collisions. So the result is a maximum of two boards stacked up and this is only possible if you have .

[...] This proposal would fix that
and enable boards that could work in combination to work.

As I said above: If I got this right, the only way to combine boards is combining "Termination"-Boards with intermediate boards. I think that's too short-sighted, sorry.

I think the main problem we face in the existing solution is, that there is
no chance to either daisychain devices nor allocating adresses dynamically
on I2C in an easy way. Maybe that point should be adressed somehow?

Intermediate boards would always use the new address. I doubt we want
to go many additional layers deep as signal integrity gets to be an
issue. The ability to go another level deep is part of why I was
suggesting 0x51 rather than 0x57. If we decide, we could just scan
from 0x57 down to 0x50 in the software to see what is connected to the
expansion bus.

And here is your problem: who decides if a board responds to 0x57, 0x51 or any other 0x5X address?
The vendor? With my luck I'll get the need for stacking two boards with the same address. :slight_smile:
The user? Ok, we could do jumpering and expect the user to do the jumpering right. Maybe that's an option.

Dynamically setting the EEPROM address based on topology sounds
intriguing, but I suspect that we'll have wanted to build boards that
were designed to attach to expansion boards "down stream" for anything
to ever work.

Unfortunately I don't see possibility either. In fact you could only do this if you daisychain something through the connectors. As daisychaining I2C would lead to the need of placing an I2C I2C master on each intermediate board, I think that's not a good option.
What we could do is passing the adressing through an extra 4-pin header connector (something similar to the McBSP header on the xM) to the next one, placing some incrementer circuty in between e.g. based on a 74 283 4-bit adder or something ... but I'm not sure if it's worth the effort.

Do you think we need to deal with the possibility of boards that are
configured to be stacked as many as you might like, ie. true daisy
chaining of the boards?

I think keep it simple is a good approach. And I think if it's possible to avoid limitations created by a *too simple* solution with little extra brainwork, we should do that.
Too many systems I've seen have limitations just because someone could not imagine a reason at designtime why one should do something that goes over the limits just created. The result was always that one stumbled over these limitations sooner or later. This might work for software where you can patch almost everything everytime. But in my opinion it never works for interfaces in hardware.

Using EEPROMs,
I think we'll also be practically limited to 8 EEPROMs very quickly
due to addressing. If a board is designed to be daisy chained, is it
reasonable to request it be build with jumpers to specify the address
from 0 to 7? Is that enough? Is it at all practical to think of any
chain longer than that on this very limited bus?

I think you are asking the right questions. Unfornutately I have no answers :slight_smile: But I think if we now make a step away from "single expansion board" towards "multiple expansion boards" we should at least do further than only a one to two transition and open the space currently available. In my opinion it is legal to say: We are able to address 8 boards right now. If we want to expand, we have either to find a device with another präamble than 0x50 or have to redesign the bus.

What about building an expansion board that works as an "Expansionboard
multiplexer"? [...]

That would add a lot of cost onto that board.

I see the point "extra cost" but why "a lot"?

If you are doing this,
you can deal with the software complexity as part of that board and in
higher levels of software, rather than putting it back on this simple
u-boot infrastructure.

You'll have to deal with more than u-boot infrastructure anyway see the post of Hunyue Yau. He even claims that drivers should be able to do pinmux settings. So the u-boot approach is ok for immediatly needed pinmux but in my opinion it's the wrong place for system setup. It should do what it's designed to do: Providing an environment for the kernel to live in. The kernel should provide an environment for the drivers to live in and the drivers... ah I think you know what I mean: I don't want to change the lowest level piece of software just because there is a new expansion board I'd like to use. In my opinion there is no need to do that.

We'll eventually need to train u-boot to build up device tree
entries.

Why u-boot? I don't understand what u-boot can do better here than the OS?

It would have been nice to put more intelligence into the
EEPROM contents, but I expect we'll be able to codify in u-boot the
boards that are specified up to the time we can specify something more
complete to producing device tree entries.

Which always leads to the need of changing the _bootloader_ if you plug another board in or you buy another board and want to use it. I don't think that's practical. It would be better to have some higher level drivers.

I have an idea to simplify the whole pinmux stuff, but I did not have the
time yet to write it down. My thoughts go towards expanding the board info
available in the eeprom by a several informations about pinmux requests from
the expansion board. [...]

Please include device tree in your considerations.

I don't understand the relevance of the device tree. Even if the expansion boards are not hot-pluggable, they are still pluggable. So why don't just use sort of plug and play mechanism at OS level? I'd apreciate if you could explain me more here...

regards
Ueli

11

Linux can't handle re initializing the i2c devices multiple times, so you need to decide at boot time which device is plugged in. My favourite example are the camera sensor boards, they all use the same i2c address but you can load only one driver. In uboot you can just read the ID register and pass the appropriate DT entry to linux.

12

Jason,

just the way the layout is on most of the i2c eeproms it is easier to
do all three pins the same, either pull up or pull down.

plus it gives the space from 0x51 to 0x56 for custom eeprom values on
accessories with the top value of 0x57 as being the "master" data.

Dave

13

Ueli,

addresses 0x50 to 0x57 have been allocated for i2c eeproms, and almost
all sot23-5 i2c eeproms are fixed 0x50. this is primarily done as a
cost saving item so that devices using EDID can purchase a
"preconfigured" eeprom for the purpose.

from that starting point the eeproms have variations of one, two and
three additional address configuration lines.

i suspect that Gerald decided to use the 0x50 simply because it was
the most accepted value such as on the sot23-5 based packages.

Dave

14

Yes, I chose it because it was simple, straight forward, a standard, and easy to interface to. I had no idea it would cause so much confusion! The address is built into the EEPROMs and cannot be changed other than on those devices that have additional address pins resulting in a maximum of 8 address 0x50 to 0x57.

What we have is an LCD board that connects to the expansion header. It uses 2 pins on that expansion header. It also has a header that allows and additional board, such as a Zippy, to be installed. That makes two boards. Using the same address for both will no doubt result in an issue with the data as two devices will try to drive the I2C bus. This means we need two addresses. So, as we need more than one, why not just go ahead and take it to all 8? No need to change it in the future.

Eight boards you say? Well, yes. You can have eight boards all connected to the bus and just using I2c. Each could have a series of I2c devices all occupying different addresses as they are different devices. I2C expander, RAM, A/D or D/A. They all will get along just fine and, Oh, no need to even change the pin muxing at all as I2C is not under pin mux control. As to other boards, as long as they do not use the same pins for different functions, they can coexist as well.

I see two options. Add switches or jumpers to expansion board to allow the user to change the address for each to prevent conflict. Or create classes of cards where more than one class could not exist at one time. The latter seems a little restrictive to me and open for a lot more discussion and debate. So, I prefer the fist one.

Allow UBoot to scan all eight addresses and have each EEPROM loaded with a pin mode map that sets the pin mux mode of each and every pin as needed by that board. A setting of 7 will indicate that the pin is not used at all by that particular board. The SW can then build a table from the data provided by all eight addresses and set the mux modes accordingly. In the case where two boards have different pin mux modes required for the same pin, a tie is declared and the pin mode is set to 7, the safe mode. A message can be sent out to indicate a conflict. It will be up to the user to remedy the situation. As to the legacy boards, they should be able to be reprogrammed by the user with updated map information. This should be able to be handled by a script.

Well, that is my 2 cents worth from the HW side of the topic.

Gerald

15

hai
sir
amdng project onbeaglebook
how toinstall text file,pdf in sd card
and how todisply and interface
could some body helpme

16

hai
sir
amdng project onbeaglebook
how toinstall text file,pdf in sd card
and how todisply and interface
could some body helpme

How is that related to expansionboards?

17

Jason,

i've created a page on elinux.org to document this discussion. i've
added some notes and an example schematic for a multi-expansion design
that can be easily implement on backplane boards such as the LCD board
you and gerald have discussed:

http://elinux.org/Animal_Boards_Multi_Expansion

the example schematic implementation is for the use of 4 expansion
slots, but could be expanded to as many 12.

Dave

18

Good idea, but I don’t see it working. There are too many loads for the processor to handle, especially at 12. You really need to add buffering here. Then things get complicated with bidirectional pins. Then you have the case where one card wants a pin as an output and the other wants it as an input. Then there is the issue where one slot wants a pin as an input and the other wants it as an output.

To me, the best way around this is to fix the pin functions on the expansion bus.

Center it on SPI, X number of inputs, X number of outputs, I2C, and Serial. By using the SPI CS expander method, you can expand the CS to 3 or 4 per slot. Set the UART lines to a serial bus, not exactly 485, but maybe a transmit tri-state function per slot. Or, just make it RS485, no additional pins, and be done with it, allowing smart cards to be created. If we set the limit to 8 slots, we can have unique addresses per slot by adding three pins to the connectors. That way the address will change automatically based on the slot that the board is plugged into.

Setting these functions will allow us to buffer a drive a lot more cards. Plus, we can even go to 3.3V or even 5V, and get away from the 1.8V limitations.

One drawback is legacy cards, but there aren’t that many anyway. One benefit will allow a lot more cards to be created that can complement each other, like A/D, D/A, motor, etc. Lower cost on the cards, no buffers per card, simple functions, or more complicated functions. There is a lot of flexibility here. Oh, and the pin mux can be fixed. The slot ID will be used to identify functions available.

Gerald

19

Just my two cents.
How about using both SPI and I2C.
SPI can cover some expansion cards.
I2C can cover the rest.
Although, i think I2C can handle them all. With its system.
SPI would need extra chip selects for each layer.

20

Hijacking threads is discouraged on this list. I've disabled this
accounts posting ability. Please contact me directly if it needs to
be reinstated for a valid reason.