xmega microsd interface

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

Hi, does any one have a working example of interfacing MicroSD cards (fat file system) using xmega SPI interface?

I found one by Roland Riegel, but it was for mega chips, and I tried to modify it so it uses xmega spi interface, but it didn't work.

If anyone has done similar and would like to share code, it will be appreciated.

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

try fatfs,

you still need to do some rework to get it to work with the xmega spi bus, but if you have SPI running the rest is all on top of that so you then should up and runnign in no time.

There also is a very good tutorial writtenon this in the tutorials forum. Note however that this is for teh mega so read that and then adapt where needed for the Xmega.

regards

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

If you follow meslomp's suggestion of using "FatFs" then the ONLY hardware specific (tiny/mega) SPI references it makes are the following in a single file:

mmc.c:/* MMCv3/SDv1/SDv2 (in SPI mode) control module  (C)ChaN, 2007           *
/
mmc.c:#define   FCLK_SLOW()             (SPCR |= ((1<<SPR0)|(1<<SPR1) ))/* Set s
low clock (100k-400k) */
mmc.c:#define   FCLK_FAST()             (SPCR = 0b01010000)             /* Set f
ast clock (depends on the CSD) */
mmc.c:/* Transmit a byte to MMC via SPI  (Platform dependent)                  *
/
mmc.c:#define xmit_spi(dat)     SPDR=(dat); loop_until_bit_is_set(SPSR,SPIF)
mmc.c:/* Receive a byte from MMC via SPI  (Platform dependent)                 *
/
mmc.c:  SPDR = 0xFF;
mmc.c:  loop_until_bit_is_set(SPSR, SPIF);
mmc.c:  return SPDR;
mmc.c:#define rcvr_spi_m(dst)   SPDR=0xFF; loop_until_bit_is_set(SPSR,SPIF); *(d
st)=SPDR
mmc.c:/* Deselect the card and release SPI bus                                 *
/
mmc.c:  SPCR = 0b01010000;                      /* Initialize SPI port (Mode 0)
*/
mmc.c:  SPSR = 0b00000001;
mmc.c:  SPCR = 0;                               /* Disable SPI function */

It shouldn't be too difficult to port that to Xmega's SPI.

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

For an example of FatFs on the XMEGA, check my Xmegalab project.

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

Any results or do you still need help ?

1) Studio 4.18 build 716 (SP3)
2) WinAvr 20100110
3) PN, all on Doze XP... For Now
A) Avr Dragon ver. 1
B) Avr MKII ISP, 2009 model
C) MKII JTAGICE ver. 1

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

I think he is lost in FatFS or spittin through the tutorial, It has grown alot lately, so he will be reading for a while.

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

meslomp wrote:
I think he is lost in FatFS or spittin through the tutorial, It has grown alot lately, so he will be reading for a while.

As the kids say, "OMG!"

So I've been writing firmware on and off for quite a few years, but this is my first foray into atmel anything. I find myself with the need to design SD card into an existing xmega32 system. In the past I'd whip out the list of white papers provided by the mfg and start designing. Not in this case. You folks on avrfreaks appear to be a better source.

I did read the tutorial. I believe so much has changed and with diffs from atmega to xmega I might be better off focusing elsewhere. Gabotronics' nice effort appears closest to my goal, so I'm starting there. Opinions on right/wrong approach?

Since I have none of the peripherial hardware as on the gabotrnics board, I intend to remove all code that is not file system and SD related. I should be able to create a file on the SD, write arbitrary data, and then read it with a PC.

Wish me luck! I'm going to need it.

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

Quote:

I believe so much has changed and with diffs from atmega to xmega I might be better off focusing elsewhere.

Not if you are talking about using FatFs. As my grep above shows there's only about 10 lines of C to be changed to "port" it from Mega to Xmega and they are going to be virtually one-for-one change as I'm pretty sure Xmega SPI is very similar to Mega SPI. Maybe half an hour's work tops?

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

Another example is in the source code for my XMEGA dev board. It uses ChaN's files, with the platform dependent sections modified for the XMEGA. You can diff between the originals and my modifications to see the changes. I never implemented FCLK_SLOW(), but you should. An example of usage is included in the audio demo (not terribly easy to read). It uses a terminal emulator and arrow keys to navigate the filesystem to find a wav file for playback.

https://www.mattairtech.com/
ARM Cortex M and XMEGA development boards / Gentoo Linux

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

clawson wrote:
Quote:

I believe so much has changed and with diffs from atmega to xmega I might be better off focusing elsewhere.

Not if you are talking about using FatFs. As my grep above shows there's only about 10 lines of C to be changed to "port" it from Mega to Xmega and they are going to be virtually one-for-one change as I'm pretty sure Xmega SPI is very similar to Mega SPI. Maybe half an hour's work tops?

When folks say something like "half an hour's work tops" to me I usually end up pouring a lot more into it than half an hour. :-)

You are referring to the dharmanitech project, right? There are differences in the serial port pins as well, which made think your diff was incomplete.

Sorry if I sound skeptical! I'm completely new here and I don't intend to arrive on scene flinging insults. Maybe you were diffing only the FatFs? Being new to this I'm trying to minimuze biting off too much for a first go-round and I can't ignore the comm.

Thanks a lot fot the replies. I'll have another look at the dharmanitech tutorial.

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

Quote:

I can't ignore the comm.

But comm is comm--there is no direct relationship to FATFS. Either your comms work, or they don't. Either you use the FATFS example program that uses comms, or you don't. (I did my FATFS project using the example-with-comms as a base, but implemented the functionality without comms using buttons and LCD on my AVR app.)

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

garciasteve wrote:

I'll have another look at the dharmanitech tutorial.

Or maybe kubark's. Geez. Age is a evil mistress.

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

I as a hardware engineer only do coding for fun and am still learning. I got the FatFs up and running in one evening ( actually 2 as I wrote down on a seperate document what I have changed and that also takes time ).

Just take the FatFs and the example program. Then go to the tutorials section of this forum and go through the kubark tutorial step by step. And keep an eye on the parts that are processor specific, like the timer used, spi bus and uart. All the other stuff should be processor independant.
This does not mean that you have to check to what IO pins all the other hardware is connected, but even I think with the kubark tutorial it was a peace of cake.

regards

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

Quote:

You are referring to the dharmanitech project, right? There are differences in the serial port pins as well, which made think your diff was incomplete.

No I was talking about porting "FatFs" alone. It's ONLY interaction with the hardware is PORT pins and the SPI - both trivial interfaces and very little work to "port" from one architecture to another.

If you are talking about some more complex project then break it down into sections and make each work in isolation. Things like UART are, again, pretty trivial but like Lee says, surely getting the UART going on a new chip is one of the first things anyone does anyway so you have a debug channel where you can drive your test harnesses for the other modules you then implement?

Whatever the "dharmanitech project" means (I've no idea) it's a pretty fair bet that the only part of it that is so complex that it would take you weeks to rewrite is the FAT access to micoSD stuff. Other things like UART or LCD driving or whatever else it has are going to be completely trivial by comparison.

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

Hi, all,
I got the code from Roland (http://www.roland-riegel.de/sd-r...) working on XMEGA series, (A1 and A3). Its not that bad, just follow the source code instruction.
The code was written for old MEGA series so the SPI interface are a little different. Luckily the code for SPI interaction are very contained in one location so modifying it wont be hard.
Let me know if some one is looking for working source code.

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

I have edited http://www.roland-riegel.de/sd-r... to work with ATxmega32A4. I am still waiting for IO. If it will work i will provide you source code.