| View previous topic :: View next topic |
| Author |
Message |
crystal_lattice
Joined: 13 Jun 2006
Posts: 164
|
| SPI mode switch/ SPI HW ModeX + SPI SW ModeY- Best solution? |
 Posted: Thu Jan 29, 2009 2:14 am |
 |
|
I'm working on some 18F4620 design which requires various SPI peripherals, amongst them ENC28J60, SD Card, DS1305 and some external EEPROM and other devices.
Problem is the devices differ in the requirement for SPI mode, currently the most can work with Mode 0 but the RTC only with Mode 1&3.
I can see two solutions:
1. Same SPI bus, switch modes when accessing different devices.
2. HW SPI for devices with same mode (majority) + SW SPI for RTC
Question now: Which method better; Method1 could cause problems when switching modes??, metod 2 = resource hungry/ requires delays. |
|
 |
ckielstra
Joined: 18 Mar 2004
Posts: 3680
Location: The Netherlands
|
|
| Posted: Thu Jan 29, 2009 4:27 pm |
|
|
I'd go for method 1.
SPI mode switching takes only a few instruction cycles. Do the mode switching when all devices are disabled and it shouldn't create problems. |
|
|
asmallri
Joined: 12 Aug 2004
Posts: 1634
Location: Perth, Australia
|
| Re: SPI mode switch/ SPI HW ModeX + SPI SW ModeY- Best solut |
| Posted: Thu Jan 29, 2009 4:48 pm |
|
|
| crystal_lattice wrote: | I'm working on some 18F4620 design which requires various SPI peripherals, amongst them ENC28J60, SD Card, DS1305 and some external EEPROM and other devices.
Problem is the devices differ in the requirement for SPI mode, currently the most can work with Mode 0 but the RTC only with Mode 1&3.
I can see two solutions:
1. Same SPI bus, switch modes when accessing different devices.
2. HW SPI for devices with same mode (majority) + SW SPI for RTC
Question now: Which method better; Method1 could cause problems when switching modes??, metod 2 = resource hungry/ requires delays. |
Hmm. I did a post but it has gone walkabout.
I would, and do, use 1. When reconfiguring the SPI bus remember to disable any active CS, stop the SPI, do the changes, re-enable the SPI, and clear the SPI flags.
I also do another step when changing SPI modes which maybe completely unnecessary, I flush the SPI bus with no CS enables by performing a sequence of spi_read(0xff);
However, there are another couple of considerations, if for example, you want to read from Ethernet and write to the SD card or visa versa then a PIC with two SPI buses may be better suited. Similarly if you needed to access an SPI peripheral in an interrupt handler, such as a sensor, you would be better off having two SPI ports.
A PIC24 series is a good candidate with its dual SPI peripherals and remappable I/O pins even in a 28 pin package. It also simplifies the SD and ENC28J60 integration because they are all 3.3 volt devices however you would need a different RTC.
_________________
Regards, Andrew
http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!! |
|
|
crystal_lattice
Joined: 13 Jun 2006
Posts: 164
|
|
| Posted: Fri Jan 30, 2009 1:24 am |
|
|
| That sounds very positive for method 1. I would at some stage like to use the SD card and ethernet together (webserver), surely they can co-exist on the same bus without problems? The pic can't read AND write at the same time so I don't really see the problem. For the moment I want to stay with 18 series pics, so 24 series is not really an option. The DS1305 is 3.3v compatible. |
|
|
asmallri
Joined: 12 Aug 2004
Posts: 1634
Location: Perth, Australia
|
|
| Posted: Fri Jan 30, 2009 9:23 am |
|
|
| crystal_lattice wrote: | | That sounds very positive for method 1. I would at some stage like to use the SD card and ethernet together (webserver), surely they can co-exist on the same bus without problems? The pic can't read AND write at the same time so I don't really see the problem. For the moment I want to stay with 18 series pics, so 24 series is not really an option. The DS1305 is 3.3v compatible. |
You can have them co-exist. But the challenge, as always, with the 18F, Ethernet and SD cards is the large amount of RAM required. When using with an SD card you end up having to cache data to go one from the other as opposed to being able to trickle data between them.
_________________
Regards, Andrew
http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!! |
|
|
ckielstra
Joined: 18 Mar 2004
Posts: 3680
Location: The Netherlands
|
|
| Posted: Fri Jan 30, 2009 9:42 am |
|
|
| Quote: | | The pic can't read AND write at the same time so I don't really see the problem. |
Andrew has a point here and you should give this a good thought. Writing to the SD card (not reading) happens in blocks of minimum 512 bytes, do you have the time _and_ RAM to support this?
In one of my old projects we mixed several components on the same SPI bus and had problems with the small RAM capacity. An external FRAM chip solved this but we made the error of connecting the FRAM to the same SPI bus. Copying data from FRAM to SD required to use 512 bytes of precious internal RAM as a buffer. |
|
|
asmallri
Joined: 12 Aug 2004
Posts: 1634
Location: Perth, Australia
|
|
| Posted: Fri Jan 30, 2009 9:47 am |
|
|
[quote="ckielstra"] | Quote: | | In one of my old projects we mixed several components on the same SPI bus and had problems with the small RAM capacity. An external FRAM chip solved this but we made the error of connecting the FRAM to the same SPI bus. Copying data from FRAM to SD required to use 512 bytes of precious internal RAM as a buffer. |
I made the same mistake which made the FRAM virtually useless for my application.
_________________
Regards, Andrew
http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!! |
|
|
ckielstra
Joined: 18 Mar 2004
Posts: 3680
Location: The Netherlands
|
|
| Posted: Fri Jan 30, 2009 5:41 pm |
|
|
Hi Andrew,
Congratulations on your 1000th post!!! 
I'm glad to hear I wasn't the only one making the FRAM error...
Should have used I2C for FRAM and SPI for the other components. |
|
|
andrewg
Joined: 17 Aug 2005
Posts: 316
Location: Perth, Western Australia
|
|
| Posted: Sat Jan 31, 2009 1:58 am |
|
|
Another reason to switch modes is the maximum SPI bus speed supported by the various devices. The ENC28J60 has a max of 20MHz. I don't know about SD cards but presume they're just as fast, if not faster. EEPROMs are usually fairly quick too, say 10MHz+ (check datasheet).
The DS1305, however, stands out with a relatively slow top clock speed of 2MHz. For a recent project with an ENC28J60, EEPROM and DS1305, when I changed modes to handle the DS1305, I also dropped the bus speed.
_________________
Andrew |
|
|
crystal_lattice
Joined: 13 Jun 2006
Posts: 164
|
|
| Posted: Sun Feb 01, 2009 11:54 am |
|
|
Some very valid points. The 18F4620 has a very large amount of RAM, being a webserver, it won't need to do much writing but rather a lot of reading from the card.
The RTC is more of a luxury - because the time can be obtained from a time server instead and update a software RTC.
This is just my cheap version of an ethernet dev board. The final 'production product' would involve a 24 series pic which will solve the SPI bus problem.
I appreciate all the good tips - will save me lots of trouble later! |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
