View unanswered posts | View active topics It is currently Wed Oct 18, 2017 10:58 pm



Reply to topic  [ 7 posts ] 
SD Card and FAT FS for FreeEMS - COMMENTS 
Author Message
Moderator
User avatar

Joined: Tue Jan 15, 2008 2:31 pm
Posts: 14822
Location: Home sweet home!
Please post your comments on Spudmn's thread in this one. His thread, which you should not post in, is here:

Start: viewtopic.php?f=8&t=1073
Unread/Latest: viewtopic.php?f=8&t=1073&view=unread#unread

Fred.

_________________
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!


Fri Mar 11, 2011 11:08 am
Profile WWW
Moderator
User avatar

Joined: Tue Jan 15, 2008 2:31 pm
Posts: 14822
Location: Home sweet home!
Spudmn wrote:
The SPI pins MISO, MOSI, SCK are available on connector P71 but I still need a Chip select. <snip> I need to find CS from some where.

Is a GPIO pin sufficient, or does it need to be more than "bit on/bit off" ? If GPIO is fine, there are many spares on the header.

Image

Quote:
Do we want to worry about the Card detect switch and the write protect switch?

Card detect we can do by lack of response, right? And write protect will just yield errors if attempting to write, right? IE, write protect is a hardware thing isn't it?

Quote:
and if you have a card plugged into your Puma then I think that you should expect data to be written to it.

And that too! :-)

Quote:
It might be a good idea to be able to control the power to the SD card, so that may be another pin we will need.

I don't see the benefit in this. If the ignition is on, and we power it from that part of the supply (will be split later) then it's minimal draw, and if not being written to, it does no harm. Can you explain why you'd want to do that? I can't see it.

Fred.

_________________
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!


Fri Mar 11, 2011 11:30 am
Profile WWW
LQFP112 - Up with the play
User avatar

Joined: Thu Feb 10, 2011 12:27 am
Posts: 232
Location: Auckland, NZ
Fred wrote:
Is a GPIO pin sufficient, or does it need to be more than "bit on/bit off" ? If GPIO is fine, there are many spares on the header.


GPIO will be fine

Quote:
Card detect we can do by lack of response, right?


Yes, as long as the card doesn't lock up and need a power cycle. see below


Quote:
And write protect will just yield errors if attempting to write, right? IE, write protect is a hardware thing isn't it?


No. The write protect switch on the SD card has no electrical connection to the card itself. The electronics in the card doesn't know if the switch is on or off and therefore wont give an error. It is up to the host to check the switch on the card socket and implement write protection.


Quote:
I don't see the benefit in this. If the ignition is on, and we power it from that part of the supply (will be split later) then it's minimal draw, and if not being written to, it does no harm. Can you explain why you'd want to do that? I can't see it.


When the card starts up it waits for a bit patten before it will talk SPI mode. I was thinking that we could power cycle the card to get it in to a known state. In saying that, I don't control the power on my set up and it works fine.

Something else to think about. User interaction.

It would be nice if the user could tell the system to stop logging and close all the files as I going to pull the card out.

Do we use a button for this?
or
will it be, turn key off. CPU detects this and closes files. Then user can pull the card. Same for start up. Turn key on and you are logging to a new file.

Aaron


Fri Mar 11, 2011 7:41 pm
Profile
QFP80 - Contributor

Joined: Thu Oct 30, 2008 10:35 am
Posts: 62
Location: Benschop, Netherlands
I think using the SPI bus for this purpose is going to be easier, faster and less CPU intensive.
And SPI is a bus so you do not have to completely offer the SPI bus of the microcontroller, the only thing you would need is a GPIO chip select per SPI device

I also think that controlling the power for the SD card from the microcontroller is a good idea :)


Mon Mar 14, 2011 12:04 am
Profile
Moderator
User avatar

Joined: Tue Jan 15, 2008 2:31 pm
Posts: 14822
Location: Home sweet home!
Spudmn wrote:
Quote:
And write protect will just yield errors if attempting to write, right? IE, write protect is a hardware thing isn't it?


No. The write protect switch on the SD card has no electrical connection to the card itself. The electronics in the card doesn't know if the switch is on or off and therefore wont give an error. It is up to the host to check the switch on the card socket and implement write protection.

OK, then yes, I agree with your sentiments. If there is a card, and it is FAT formatted, and there is available space, then write to it. We shouldn't format cards, though, or even have that functionality in the firmware, nor should we erase or overwrite existing files (on purpose, bugs are acceptable for a while...).

Quote:
When the card starts up it waits for a bit patten before it will talk SPI mode. I was thinking that we could power cycle the card to get it in to a known state. In saying that, I don't control the power on my set up and it works fine.

Well, we can make this a generic IO pin option. Assign it to this function, and also have it optional from your code too, such taht your code knows if it has this pin or not. Such things can be hard coded for now, so wire up such a pin, and experiment, but later we won't have it.

I guess your code should have some resettable variable that says "failed to talk to card" such that if it has failed, it doesnt waste cpu time trying again without luck. you could use a byte and set the reason as a bit and just check the whole thing to see if you should try again...

[quote=Spudmn]Something else to think about. User interaction.

It would be nice if the user could tell the system to stop logging and close all the files as I going to pull the card out.

Do we use a button for this?
or
will it be, turn key off. CPU detects this and closes files. Then user can pull the card. Same for start up. Turn key on and you are logging to a new file.[/quote]
Yes, let people turn off the key to pull the card out, and, we can add a serial command to close files and/or start/stop logging to the card, and a configuration item in flash on whether to log to the card by default too.

Fred.

_________________
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!


Mon Mar 14, 2011 3:03 am
Profile WWW
Moderator
User avatar

Joined: Tue Jan 15, 2008 2:31 pm
Posts: 14822
Location: Home sweet home!
Maybe we could have formatting cards as an option but ONLY linked to a serial command, not autonomously, ever :-)

_________________
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!


Mon Mar 14, 2011 3:04 am
Profile WWW
LQFP112 - Up with the play
User avatar

Joined: Tue Jan 15, 2008 5:31 pm
Posts: 166
Any chance the SPI Slave Select expander could be put to use here? There is the /SS -pin (Slave Select) unused on the MCU sheet which is *the* pin for Chip Select but with just one you aren't going to do much.


Sun Apr 03, 2011 3:09 pm
Profile
Display posts from previous:  Sort by  
Reply to topic   [ 7 posts ] 

Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software for PTF. ColorizeIt.