Re: `Software controlled SPI slave select?
From: Tim Wescott (tim_at_wescottnospamdesign.com)
Date: 08/08/04
- Next message: John Woodgate: "Re: Hi, I'm Jim!"
- Previous message: Jim Thompson: "Re: Hi, I'm Jim!"
- In reply to: Stefan Arentz: "`Software controlled SPI slave select?"
- Messages sorted by: [ date ] [ thread ]
Date: Sun, 08 Aug 2004 10:03:54 -0700
Stefan Arentz wrote:
> (This is my first real electronics/microcontroller project so please forgive
> me if i say stupid things. I've been a software-only person for the last 20
> years and am just getting my feet wet with electronics :-)
>
> I am looking into a project where I want to do connect several devices to a
> controller. The devices and the controller are physical units, and I need to
> run a 2m cable between them. Because the devices will be powered by an AVR the
> SPI bus seems a logical choice.
>
> SPI looks pretty simple, but what I don't like is that I need to have a
> seperate slave select line for each connected device. It would make the
> design more complicated.
>
> What I am thinking of now is to use SPI as a broadcast medium and let
> the software in the devices figure out the right thing to do. I have no
> idea if this is common practice, so I would like to explain my idea here
> and see what people think of it.
>
> So, what you normally do is use the slave select line to select the slave
> that needs to pay attention. You can then throw data to the slave, one byte
> at a time. When your slave is not programmable this is the only way to do
> it, but when you are talking to another CPU then you can encapsulate the
> slave select in the data itself by abusing some bits.
>
> This is what I mean:
>
> Say you want to send 0x42 to slave device #2 (the slaves have to know which
> number they are, but that can be stored in the AVR's eeprom or even done
> manually with jumpers).
>
> Then you send the following 2 bytes on the bus:
>
> 0 1 0 0 0 1 0 0 0 1 0 1 0 0 1 0
> ----- - ------- ----- - -------
> i s d i s d
>
> Where:
>
> i = slave id (2 in this case, 3 bits means 8 slaves max)
> s = start/stop bit (0 = first nibble, 1 = second nibble)
> d = data (one halve of the data)
>
> So when the controllers receive data on the bus they first look at the
> first three bits and decide wether this data is for them. If so then they store
> it in memory. When the second halve of the data is received you can complete
> the data and process it. The start/stop bit (bad name probably) specifies which
> part of the data this is.
>
> It is a transport protocol, so there is no checksum involved. That could be
> something implemented on top of this.
>
> This effectively halves the throughput, but for my application that is probably
> acceptable; i need to be able to send about 256 bytes per second to each device
> for a total of 1K per second if I connect 4. So that would double to 2K per
> second that is broadcasted on the bus in the worst case scenario.
>
> I am pretty new to this area, but that throughput is not very difficult to
> process with something like a cheap AVR AT90SXXXX right?
>
> It sounds obvious but there must be something that I overlook :-)
>
> S.
You want to use asynchronous serial (your AVR either calls it the UART
or the SCI port). Most micros, the AVR included, will allow you to send
9 bits of data with the 9th bit being an address flag -- you can set up
your slave devices to wake up on 9th bit signaling and take a look at
the encapsulated address.
You can either use this to manage a number of slaves on RS-422, or you
can make a half-duplex peer-peer connection on RS-485 (it's only a bit
more software, he says with an evil grin).
-- Tim Wescott Wescott Design Services http://www.wescottdesign.com
- Next message: John Woodgate: "Re: Hi, I'm Jim!"
- Previous message: Jim Thompson: "Re: Hi, I'm Jim!"
- In reply to: Stefan Arentz: "`Software controlled SPI slave select?"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
