Petit FatFS implementation

Go To Last Post
62 posts / 0 new

Pages

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

I guess I just need to ditch the 8515 and get something with debugging features.  The 162 appears to be pin compatible with 8515 and has JTAG so that might be something to try or I might just go back to the drawing board.

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

Rooney wrote:

That worked, sort of.  It didn't work at first but then I found disconnecting the AVR Dragon from SPI and power cycling (resetting doesn't work) the circuit allows the card to initialize and open a file... so maybe that was the issue all along, or maybe not.  Regardless, now it reads data but I think I'm getting unreliable results.  I will have to set up a better way to indicate results for debugging (and disconnecting SPI is a real nuisance!).  I'm certainly happy to see some progress though.

 

I'm glad you now can use the pfsample program.  It is rather nice to gain some experience with PetitFF.  I use an USBASP as a programmer and have never been able to leave it connected when I use the same pins for other SPI devices. I have not read the Atmel AVR042 application note (attached) thoroughly but it may show one possible solution.

 

Since you are using a software implementation of SPI, why not just move all the SPI outputs from PORTB to PORTA.  Then you should be able to leave the SPI leads connected while programming and the Dragon connected when running.  I did that with the ATtiny861's USI hardware and its alternate port (USIPP) capability.  All you have to do is change the #defines at the beginning of susi.S and move your wires over to PA0 through PA3.

; port and pin setup
#define DDR_CS		_SFR_IO_ADDR(DDRA), PA3		// Set CS pin Direction
#define	PORT_CS		_SFR_IO_ADDR(PORTA), PA3	// Set CS pin State
#define DDR_CK		_SFR_IO_ADDR(DDRA), PA2		// Set CLK pin Direction
#define	PORT_CK		_SFR_IO_ADDR(PORTA), PA2	// Set CLK pin State
#define DDR_DO		_SFR_IO_ADDR(DDRA), PA1		// Set DO pin Direction
#define	PORT_DO		_SFR_IO_ADDR(PORTA), PA1	// Set DO pin State
#define DDR_DI		_SFR_IO_ADDR(DDRA), PA0		// Set DI pin Direction
#define	PORT_DI		_SFR_IO_ADDR(PORTA), PA0	// Set DI pin State
#define	PORT_DI		_SFR_IO_ADDR(PORTA), PA0	// Apply pull-up resistors
#define PIN_DI		_SFR_IO_ADDR(PINA), PA0		// get DI input state

Have to move to another computer to attach the file.

Alan

Attachment(s): 

Last Edited: Mon. Apr 22, 2019 - 12:09 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Rooney wrote:
I found disconnecting the AVR Dragon from SPI

When you have SPI devices, you need to use a weak pull-down/pull-up to keep it de-selected during other activity on the SPI bus.  I've lost track but this includes ISP activity when the AVR is in reset.

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

allano wrote:
Since you are using a software implementation of SPI, why not just move all the SPI outputs from PORTB to PORTA.  Then you should be able to leave the SPI leads connected while programming and the Dragon connected when running.

 

All my IO lines are serving other purposes but for reasons of troubleshooting the SD-Card I could remove those connections to do as you suggest.

 

theusch wrote:
When you have SPI devices, you need to use a weak pull-down/pull-up to keep it de-selected during other activity on the SPI bus.  I've lost track but this includes ISP activity when the AVR is in reset.

 

Okay, so I have 1k resistors on the SD-Card adapter's MOSI, MISO, and CLK lines as per this thread which corrected my issue of SPI not working after adding the card reader.  I also at one point had a 10k pullup on the card adapter's MISO line as per this post in this thread.  I'll investigate what you mentioned, thank you.

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

Did you get the drift?-- the select line; not clock or data in or data out...

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

Yes, I understand, thank you for making sure.

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

I scrapped the 8515 and am reworking around the Atmega 3209.   I temporarily removed Petit FatFS and reworked my code to the different dialect (PORTX.DIR instead of DDRX, etc.) and it compiles.  Upon re-attaching Petit FatFS I receive compiler errors 'constant value required' in asmfunc.S regarding definitions for things like DDRB_CS and PORT_CS.

 

#define DDR_CS		_SFR_IO_ADDR(DDRB), PB4		// Set CS pin Direction
#define	PORT_CS		_SFR_IO_ADDR(PORTB), PB4	// Set CS pin State

I'm unsure how to rework these for the 3209.  Feeble attempts such as replacing DDRB with PORTB.DIR didn't pan out.  I have been researching it but so far haven't found what I'm after.  Some pointers would be very much appreciated.

 

Thanks!

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

Scratch that.  I picked up the scent of useful information in a Clawson reply to a five year old Xmega thread.  Got some good clues to work with for now.  Thanks Clawson.

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

Wow I must be psychic - answering questions without actually needing to be present ;-)

 

You're welcome!

 

PS If you do get an implementation working for AVR-0/AVR-1 you might want to email the mmc.c file (and .S if also used) back to E L Chan with a hope he includes it in future issues of ffexample.zip . It's always been sadly lacking any form of example for "X" architecture.

Last Edited: Wed. Jul 17, 2019 - 08:18 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well, I was able to get it to compile by changing thing like  "_SFR_IO_ADDR(DDRE), PB3" to "_SFR_IO_ADDR(VPORTE_DIR), 3" but I can't test it until my ICE arrives because of course I just learned was UPDI is and that my pet Dragon don't play that.

 

I'm not sure about the pull-ups though, I'm guessing something like this?

 

#define    PORT_DI        _SFR_IO_ADDR(VPORTE_PIN0CTRL), 0

Also I presume the virtual port won't just magically work and that I need to implement it somehow.

 

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


Rooney wrote:
Also I presume the virtual port won't just magically work and that I need to implement it somehow.
Yes that. The way the VPORTs work (well on most Xmega I am aware of anyway) there are four VPORTs so via config registers you get to choose which if your four favourite PORTs you want mapped into VPORT range.

 

EDIT: OK so I'm wrong. I just pulled the 3209 (well the AVR0 family) datasheet and see these new chips now have:

 

 

So it seems that there are always 6 VPORT remapping registers (for A,B,C,D,E and F) at fixed positions and whether they are active is simply down to the number of pins the device has. As the xx09 chips seem to have 48 pins I guess they have all 6.

 

So actually this is a development on from what traditional Xmega had.

Last Edited: Thu. Jul 18, 2019 - 08:31 AM

Pages