| View previous topic :: View next topic |
| Author |
Message |
baltazar_aquino
Joined: 16 Mar 2008
Posts: 27
|
| MMC SPI and UART |
 Posted: Wed Dec 17, 2008 11:58 pm |
 |
|
Hello!
Has anyone here benchmarked the MMC over SPI transfer rate when using either FAT 16 or 32 ? Software SPI is quite slow but my application requires me to use the hardware pin for TX ( PIC18F4550) to give priority to the hardware UART. ( Unfortunately Microchip multiplexed the RC7 pin with RX(UART) and SDO(SPI) so I cannot use hardware SPI while using the same pin for hardware UART) I want to use the full UART for MIDI application and utilize software SPI. Will it introduce so much latency in the data transfer? Has someone tried it?
Regards |
|
 |
asmallri
Joined: 12 Aug 2004
Posts: 1634
Location: Perth, Australia
|
| Re: MMC SPI and UART |
| Posted: Thu Dec 18, 2008 12:41 am |
|
|
| baltazar_aquino wrote: | Hello!
Has anyone here benchmarked the MMC over SPI transfer rate when using either FAT 16 or 32 ? Software SPI is quite slow but my application requires me to use the hardware pin for TX ( PIC18F4550) to give priority to the hardware UART. ( Unfortunately Microchip multiplexed the RC7 pin with RX(UART) and SDO(SPI) so I cannot use hardware SPI while using the same pin for hardware UART) I want to use the full UART for MIDI application and utilize software SPI. Will it introduce so much latency in the data transfer? Has someone tried it?
Regards |
No I have not tried it but....
There can be large voltumes of traffic that must traverse the MMC SPI bus when reading or writing. For example assume you have finished with the current sector and need to access the next sector. If the next sector is in a different cluster then you need to perform a directory lookup, a fat lookup, then fetch the sector. Multiple sector fetches could be required at each step. Each sector fetch is 512 bytes (4096 bits).
The CCS software SPI driver will result in the rest of the application waiting on this serialization process. If this is not a problem then it is a simple solution. An alternative approach is to emulate the hardware SPI using a timer and an interrupt handler. This will enable you to treat the emulated SPI in the same way you treat the hardware SPI allowing either blocking or non blocking operation.
_________________
Regards, Andrew
http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!! |
|
|
baltazar_aquino
Joined: 16 Mar 2008
Posts: 27
|
|
| Posted: Thu Dec 18, 2008 7:40 am |
|
|
| Thanks Andrew. I am just thinking of spending few more dollars for another chip ( a PIC18F2550 perhaps) to perform the MMC controller funtion. This will free the 4550 for other tasks. The application is a MIDI sequencer hence it requires stable timing and I don't want the software SPI to clash with it. |
|
|
asmallri
Joined: 12 Aug 2004
Posts: 1634
Location: Perth, Australia
|
|
| Posted: Thu Dec 18, 2008 9:52 am |
|
|
| baltazar_aquino wrote: | | Thanks Andrew. I am just thinking of spending few more dollars for another chip ( a PIC18F2550 perhaps) to perform the MMC controller funtion. This will free the 4550 for other tasks. The application is a MIDI sequencer hence it requires stable timing and I don't want the software SPI to clash with it. |
The emulated SPI driver loading would be insignificant however loading required to support the MMC itself (hardware or emulated SPI) would have to be considered. You would only benefit from using a separate PIC to manage the MMC if the coding for the first PIC used non blocking techniques for reading an/or writing to the second PIC.
If you add another PIC to control the MMC then I suggest using a PIC18F2620 to handle the MMC - the PIC18F4550 family are poor candidates for using for SD/MMC cards if you also want to use the USB because limited RAM available to support SD/MMC card operations. The PIC18F2620 has far more RAM enabling it to manage more simultaneous open files which may not be of interest for this specific project but makes it reusable for other projects. If you were not tied to the PIC18F family for the second PIC then PIC24FJ64GA002 (same physical size as a PIC18F2550) would be a great candidate because it has two SPI busses, remappable I/O lots of RAM, high performance and is cheap.
_________________
Regards, Andrew
http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!! |
|
|
baltazar_aquino
Joined: 16 Mar 2008
Posts: 27
|
|
| Posted: Sun Dec 21, 2008 11:03 am |
|
|
sound advice andrew. thanks.  |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
