Mixed SPI/Async use?

Go To Last Post
9 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Greetings -

 

This query is driven by a starting design using M4808/9 with multiple UARTs, but I think it is actually somewhat more general than that.

 

I am looking at a serial channel that supports both SPI and async serial since these UARTs are capable of working in either mode. That is, I am looking at a channel that might contain BOTH SPI slaves and async peripherals. 

 

I do understand that async does not have an explicit master/slave relationship. Thus, something would have to be done to provide the equivalent of a chip select and tri-state functionality at the peripheral. Thats not hard, it just takes some awareness that it is needed, or so it would appear. I also understand that some care may be needed when switching modes, to avoid false data or other undesired artifacts.

 

Given that caveat, are there any other impediments or gotchas that I might be overlooking that might come with mixing SPI and async on the same bus? Has anyone tried to do this?

 

Thanks

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Now that is an interresting question, mixing sync with async looks messy at best.

You would need to use a sync mode where the data line idles high, and verify that switching from one mode to the other does not change that.

At least the spi devices should have a CS signal so they ignore the async data, I guess you could implement something similar for async devices, something like a h/w handshake line(s) that clears any errors received while /CS.

Seems like it could work, is there no option to separate the two sets of devices onto there own bus?

 

Jim

 

Click Link: Get Free Stock: Retire early! PM for strategy

share.robinhood.com/jamesc3274
get $5 free gold/silver https://www.onegold.com/join/713...

 

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes, I think some use of  "Slave-Select" signals would be the way to go - when you select a slave (or group of slaves), that also defines which comms mode (SPI or Async) will be used...

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Part of this is driven by the desire to have plug-interchangeable peripherals, some of which might be async and some might be SPI. One example is a bus with (possibly) a precision temp sensor (SPI), a precision RTC (SPI), and a display (likely simultaneously). The latter might be a multi-LED controller (SPI) OR a mico-OLED display (which MIGHT be SPI or async).

 

The other use case is simpler in that there would only be one device on the bus, at any time, but which MIGHT be an RS232 interface, an RS522/485  interface, a BTLE module, a WiFi module, an IrDa module,  an NFC module, or a uSD card.

 

I have designed an ident mechanism so that the host knows what is present. Since the second bus has just one member at a time, it is pretty simple. The first bus MIGHT be tamed by making more definitive design choices up front, but I was hoping for a bit more flexibility and future proofing (ha, ha). Clearly, flexibility would come at a cost, and that is what I am going to have to juggle. The more I can push that cost onto the module, the easier it will be (though that will probably push up the board area). Also, increasing the bus pins to accommodate separate busses would push up cost and peripheral card area.

 

This is also driven by the limited number of ports. I need a dedicated sensor bus and also want to implement a permanent async debug port. So, with one SPI, one TWI, and 3 dual mode async/spi, I am close to the limit.

 

Cheers

Jim

 

 

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

Last Edited: Tue. Dec 31, 2019 - 08:36 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ka7ehk wrote:
Part of this is driven by the desire to have plug-interchangeable peripherals,

Ok, that eases the requirements a bit then, lets see you will need DO,DI,CLK,CS0,CS1,CS2,GND and maybe VCC as well making for either an 8 or 9 pin connector (DE9) on your external I/O port.

The CS lines could be used for h/w hand shack or data direction as needed for async comms.

Don't forget to make provisions for a pull up on DI if using 485.

Jim

 

Click Link: Get Free Stock: Retire early! PM for strategy

share.robinhood.com/jamesc3274
get $5 free gold/silver https://www.onegold.com/join/713...

 

 

 

 

Last Edited: Tue. Dec 31, 2019 - 08:53 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Point well taken re RS485.

 

Thanks

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sounds like you want i2c!  

 

Also consider if you go to BT or WiFi, the chip to do these is most likely more powerful than the AVR eg nRF52 - 64MHz Cortex M4 or ESP32 2x 160MHz Tensilica. It might be if you base your design around these, you get the BT/WiFi effectively for free rather than an add-on. Atmel/Microchip have similar offerings, but I don't think their software is at the same level as others.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The sensor has selectable I2C/SPI - that is an option, certainly.

 

I see, more and more, advertised "drop-in" BLE modules. WiFi is probably more complex, have not looked at that in detail. But, point is well taken.

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

WiFi is easier. Just connect and fire up a browser. Bluetooth requires specific apps.