How to "Test" ?

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

Greetings Freaks -

 

I've been around a while, in the electronics business, and have done more than my share of testing. But, this one has me stumped. I have had to revisit 5 year old code that uses fatFS on microSD cards. And, I have had to make some architectural changes that I really don't want to, changes that effect error handling. fatFS provides a large number of error codes, many involving the internal working of SD cards. 

 

My question is about testing error cases. We have no access to the internal workings of the cards, so there is no "natural" way to have the errors happen to verify proper handling. If we hack the fatFS code to create errors, then you can't tell if fatFS, it self, will behave in an appropriate way, consistent with the test error.

 

What do folks do in cases like this, where you have no practical way to create errors for which you are trying to test the handling?

 

Thanks

Jim

 

 

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

Last Edited: Sat. Feb 27, 2021 - 04:52 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

that uses fatFS on microSD cards.

That may be the key item....fatFs & cards are not changing, correct?  So the errors it detects & reports are still the same?  If so, you should be able to simulate (force/fake) the errors it reports to your code.   So you are really testing your response to fatFS reporting of errors & treating fatFS like a black box.  Perhaps this is too simplistic a view, when any handshaking is required (beyond a simple reporting).   

 

You are still using the same fatFs---you haven't touched it at all.    If you want to test fatFS & its checking/generation of errors (that is, is fatFS really working properly), that would indeed be more cumbersome.  You might have to rig up a card with a simulated fault.  But can you assume fatFS has been thoroughly tested & "known good"  (dangerous words)?

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

Last Edited: Sat. Feb 27, 2021 - 05:35 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ka7ehk wrote:
What do folks do in cases like this, where you have no practical way to create errors for which you are trying to test the handling?
During the '80s, UART would have an attached analyzer to capture and replay data sequences; IIRC, that analyzer would run scripts (reasons : the attached items were expensive, only a few emulated items)

sigrok has SD protocol analyzers; consider a digital pattern generator.

Is there FOSS for SD memory cards?

 

sigrok.org Git - libsigrokdecode.git/tree - decoders/sdcard_spi/ due to Protocol decoders - sigrok

Using the Pattern Generator [Digilent Documentation]

 

"Dare to be naïve." - Buckminster Fuller

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

Well, part of the question involves the fact that fatFS is involved with the error responses, in some cases. Since the internal state of fatFS code is almost as inscrutable as the SD cards, themselves, how am I to know that fatFS will respond the same way after a hack-created error as it does with a real error?

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

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

Well in something like gtest the idea is that you do MOCK parts of the system such as deliberate error generation to make sure your error handling paths work. So I don't think the idea of faking errors is unheard of.

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

Generally I think one would test at the interface to the module under test - basically, lie to it, and see what it does.

 

So in this case, you'd probably want to replace FatFS with a stub with the same interfaces (at least, those you're using) and have that stub return the errors (or lack thereof) that you'd expect to see, and check that your software deals with them as you would expect. As above, you really have to assume that FatFS has been hammered to death, and if you haven't changed it, why would it suddenly stop working.

 

Neil

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

My concern is that simply returning a non-OK error code at the place where the OK state would return might not leave the file system objects representing the real error condition. Then, the response (lets say, doing an fClose) might not have the same internal behavior as when it is an actual error. It seems to require a higher level of knowledge about the fatFS software than I am willing (or able) to supply!

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

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

I assume you are using SPI.  One option would be to generate a SD emulator (e.g., using an AVR chip w/ SPI i/f) that can generate the errors codes you want, along with the internal SD state representing the error.  Hook up your AVR running the fatFS code and test it.  Maybe you get lucky and someone sells type of rig.

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

Not sure I understand, but I sense pain...

 

https://hackaday.io/project/19783-sd-card-emulation

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

It seems to require a higher level of knowledge about the fatFS software

I was wondering about that possibility.....for example upon an error, you might be required to send an error clear response to fatFS....but if you only simulated an error (and your code proceeded to send fatFS the clear error, like it should) fatFS might become confused, since it  didn't know of an error (maybe that would cause fatFS to generate a real error).   Jumping in between two software rail cars can be dangerous. 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

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

What I am partially frustrated about is lack of guidance. There are lots of projects and example code, out there, using AVRs and fatFS. But, who knows if they handle errors correctly? What I would really like to find is a list that says: if fWrite() returns fDISK_MISSING, then close the file system; if fWrite() returns fWRITE_ERR then try the write again, and so forth. 

 

But, on the matter of testing, fatFS maintains two "objects", one for the file system and one for the file, itself. These objects are modified as the code executes. If an error is detected, the code typically exits from a different place in the code than it does when the operation is successful. Thus, if I simply replace a returned error code of fOK with the code fDISK_MISSING, the state of either or both objects are likely NOT the same as when that error is detected in the way it would have been detected in the normal way. So, even if I write an error handler that does the correct thing, the code might very well not respond in the same way as it would with an actual error.

 

This state of affairs is a consequence of code that is ALMOST undecipherable and that deals with a black box that has no way to generate "true errors".

 

At this point, can only assume that there is no good (e.g. practical) solution. I was hoping that someone would show a way to deal with this. Perhaps there is none? Not quite ready to call this as the "unsolved solution".

 

Thanks

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

Last Edited: Sun. Feb 28, 2021 - 12:44 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

As MattRW said. Create an sd card simulator, basically simulate a sd-card using a raspberry pi or other hardware. Something that will pretend to be an sd-card. It will come in handy later. I have had to do similar things in the past. That methodology works and is a reliable testing process.

Last Edited: Sun. Feb 28, 2021 - 01:21 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ka7ehk wrote:
At this point, can only assume that there is no good (e.g. practical) solution.
Concur (not an easy problem to solve); IIRC, defect detection efficiency of rigorous testing is 40%.

Have to do some testing, coverage is usually enough, MCDA may be required.

ka7ehk wrote:
Perhaps there is none?
static analysis, formal methods

 


Quotes and Thoughts | The Embedded Muse 313

Come Join Us (MPLAB Now Supports AVRs) | Page 7 | AVR Freaks

...

Microchip also introduced MPLAB Code Coverage license, which determines parts of software that have or have not been executed with minimal impact to the application.

...

Gcov (Using the GNU Compiler Collection (GCC))

MCDA - Wiktionary

 

What is "Static Code Analysis"? | AVR Freaks

 

"Dare to be naïve." - Buckminster Fuller

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

For reference: the exFAT file system specification.

 

https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification

 

It was also encouraging to find SdFat has an MIT License now; last I looked, GPL.

 

https://github.com/greiman/SdFat/commit/e4190e50a4ed83c73fb046b7fce2694e8cfe2ddb

 

If something is not working, maybe it would be worth looking through the issues, and if nothing shows up, start a GitHub account and ask greiman, did you modify a current version.

 

https://github.com/greiman/SdFat/issues

 

 

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

No, it is not an issue of working vs not working. 

 

Instead, it is an issue of "reliability". My instruments are often unattended for weeks at a time. If something goes wrong, a whole research project could be rendered useless. In such situations, one has to deal with the statistically improbable but still possible. Fortunately, nothing like Explorer space craft or Mars Rovers. 

 

At this point, being forced to revisit 5 year old code, I marvel at how little attention I paid to matters of the statistically improbable. And, now I marvel at how inscrutable both SD cards and fatFS code are, and the implication that has for insuring that the code is "right". I can tell you that it does not create great waves of confidence!

 

It also does not instill much confidence that the changes I am making now will be free of hidden problems.

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

Last Edited: Sun. Feb 28, 2021 - 05:41 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That I can understand, I have been pondering data acquisition for flow meters for a while and was thinking that having an SD card at the point of acquisition plus an uplink to an SBC for networking might be a good idea. However, I have had some issues with SD cards; they are not inspiring confidence. I find networking services also to be inscrutable, so I want an SBC to do that for me. Maybe I should have enough local SRAM for the uplink to be down briefly and allow multiple hosts to interleave (hmm... redundant upload) but not introduce something that I am having problems with.

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

Hmmm. Ditch fatFS and replace it with a commercial product? It sounds like that route would be lower cost than writing an SD card emulator.

And if you write an emulator then how do you verify its behaviour?

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

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

Had not considered that option! Its not going to happen in this instance. Time. And I really DO need to consider other options, I guess, for the product redesign that has been slowly spinning up since last fall.

 

Thanks

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

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

Brian Fairchild wrote:
And if you write an emulator then how do you verify its behaviour?

 

Exactly my problem at the moment. Writing a simulator/emulator for an odd ECU protocol...

 

  • both ends talk - but are they right or both wrong the same way?
  • they don't talk - but which is wrong?

 

This is always going to be the problem with any emulator: if you can't test against the real thing, you can't prove it's happy. As I said earlier, you have to trust modules you didn't write. Ideally, they come with some sort of test documentation...

 

My own experience is that there are so many ways a file system can get it wrong that it's impossible to test - and that SD cards have all sorts of ways of misbehaving on their own. Even at the write-a-sector level, you're not writing a sector, you're asking another microcontroller to write a sector on your behalf. In high reliability requirement situations (logging data at high temperatures at the bottom of three miles of oil well) I've had to write my own file system to non-volatile memory so that I can show each stage is working and testable. (It turns out that the microcontrollers in SD cards fall over after a few hours at 150C+ - who'd have thought it?)

 

If you do have to rely on FatFS (or other file system) talking to a possibly unreliable medium, I would be inclined to:

  • segment the writes into multiple short files so you don't lose everything if one doesn't work
  • perform read after flush after write testing to check that what you wrote is what you think you wrote
  • perform media verification if you can get to it at low enough level (I don't recall if FatFS lets you do that; it's been a year or two since I used it)

 

Of these, the first is probably the easiest and cheapest on power.

 

Neil

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

Thanks for those ideas Neil -

 

Really worth paying attention to, I think!

 

Best wishes

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

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

Brian Fairchild wrote:
Ditch fatFS and replace it with a commercial product?
or not as FatFs has indirectly been through Coverity Scan (a FOSS advantage)

mcu | Coverity Scan - Static Analysis

Software Development Kit for Kinetis MCUs | NXP

[More, 1/4 page, right column]

  • High-quality software: all drivers and startup code are MISRA-C:2004 compliant and checked with Coverity® static analysis tools

...

  • FatFs, a FAT file system for embedded systems

...

 

"Dare to be naïve." - Buckminster Fuller

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

One thing that may have caused at least one of my problems was powering down while the SD was doing ware leveling. Maybe the power to the SD card can be measured, and then wait for it to be stable for some time before removing power. An LED to show SD power, brightness proportional to current. Maybe redundant SD cards, IOFF buffers might be used to enable one or the other data and clock. Add a checksum of the previous file to the current file as it is added, then make a checksum for the next file during the readback test. When the MCU has free time and enough power, it could verify the checksums between cards. That may also make data tampering detectable.  

Last Edited: Sun. Feb 28, 2021 - 06:26 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

barnacle wrote:
My own experience is that there are so many ways a file system can get it wrong that it's impossible to test ...
completely (pardon the pedantic); a file system has to be tested (a non-FOSS typical advantage in the presence of SQA though there's FOSS that's SQA'd)

barnacle wrote:
In high reliability requirement situations (logging data at high temperatures at the bottom of three miles of oil well) I've had to write my own file system to non-volatile memory so that I can show each stage is working and testable.
A MCU manufacturer may provide the low-level driver source code to which one can add the file system source code.

 

AN_6301 NAND Flash Support on AT91SAM7SE Microcontrollers

[page 21]

8. High Level File System Software Drivers

https://asf.microchip.com/docs/latest/search.html?search=flash (ASF3)

core_apps_sam_l21/apps/fs/nvm_fat at master · Microchip-MPLAB-Harmony/core_apps_sam_l21 · GitHub

Memory Products For High Temperature Harsh Environments - TT Semiconductor (TTZ2564) due to Overview of Hardware Components | EV-HT-200CDAQ1 User's Guide [Analog Devices Wiki]

 

"Dare to be naïve." - Buckminster Fuller

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

ron_sutherland wrote:
One thing that may have caused at least one of my problems was powering down while the SD was doing ware leveling.
Some SD cards have verified and validated power failure recovery.

ron_sutherland wrote:
Maybe redundant SD cards, ...
or journaling file system on one SD card.

 

edit : or no journaling (flash media lifetime)

exFAT File System: Everything You Need To Know (2021)

 

edit2 :

FatFs - f_sync

...

Performing f_sync function in certain interval can minimize the risk of data loss due to a sudden blackout, wrong media removal or unrecoverable disk error. 

...

"Dare to be naïve." - Buckminster Fuller

Last Edited: Sun. Feb 28, 2021 - 07:53 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Do you understand the SD card interface?

If so, test that without going through a file system.

Is what you want to do simple enough that you can dispense with

a file system and treat the card as basically an array of blocks?

Moderation in all things. -- ancient proverb

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

Skeeve -

 

What goes onto the SD card has to be readable easily by a computer and if not directly as a csv file, has to be convertible by the computer into a csv file. I don't know of any way with a desktop computer to access data on an SD card at the block level; none of the code development tools that I use has that capability, as far as I can tell. It could make things a LOT easier (and probably more reliable) if I could do that. USB memory card readers appear to identify themselves as mass storage devices and I would expect that to automatically pipe all of the access through the computer's file system manager. Instead, you would need to access the card reader's hardware level card interface.

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

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

Just expanding on the above... Might one approach be to write to the card, when in the field, as a simple block device and to build a desktop unit that converts block to a serial stream to be read by the desktop client.

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

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

Got that. My problem is figuring out how to convert blocks to a serial stream in various desktop operating systems. None of my dev tools have that capability. It would probably have to rely on various lower-level operating system function calls. That is a can of worms that is even more scary than fatFS!

 

<EDIT> Oh, just a minute - noticed you wrote "desktop device". That COULD be a micro that is able to do a low-level access, then spit it out as a serial stream. Got THAT! The economics are not favorable BUT I can see it happening. Another alternative would be to have the instrument, itself, do that function. Hmmmm, one drawback I can see is that users really like being able to carry the memory card to a desktop reader and get the data that way. A competitor's product behaves like a thumb drive and it is awfully slow compared to a desktop card reader. BUT, need to put that idea into the memory banks and let it simmer for a while!

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

Last Edited: Mon. Mar 1, 2021 - 02:32 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It is possible to read a raw sd card as though it was just a list of eeprom/flash values.  Here is an example (not my code, just some web slueuthing)...no guarantee, just a general

1 Private Sub Button3_Click(sender As System.Object, e As System.EventArgs) Handles Button3.Click
2 Dim contents() As Byte
3 Dim myStream As New RAW.DISK.streamer = RAW.DISK.CreateStream("C:", FileAccess.Read)
4 contents = RAW.DISK.ReadSector(0, 512, myStream)
5 'do whatever you want with these bytes
6 RAW.DISK.DropStream(myStream)
7 End Sub

 idea.

 

 

Some windoze programs can take a "raw sd" card & turn its files into something windows likes:

https://www.partitionwizard.com/...

 

 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

Last Edited: Mon. Mar 1, 2021 - 03:28 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

One technique is to create a filesystem with one file of fixed size full of 0xff. On startup your code has to find the current end of file by reading each sector (or you implement some other technique to store the current EOF). You then write a sector at a time. If you want to circulate the log file, then write the data then write the next sector with 0xff. Your errors then become: read fail, write fail, file full.

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

Great ideas.

 

Late for the current "issue" but worth high consideration in the coming redesign.

 

Thank you, both, very much!

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

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

gchapman wrote:

barnacle wrote:

My own experience is that there are so many ways a file system can get it wrong that it's impossible to test ...

completely (pardon the pedantic); a file system has to be tested (a non-FOSS typical advantage in the presence of SQA though there's FOSS that's SQA'd)

 

Yes, I'd agree a file system has to be tested - but my point was that the complexity of a file system, combined with the fact that it's very difficult to replicate the storage interface in such a way as to be able to provide credible errors on real hardware (particularly on SD or MicroSD) renders complete testing impossible in practical terms for a small business.

 

For example, sooner or later the (user side) file system code says 'here's a sector, write it at xxx' and assumes that if the controller responds 'ok' then it's done it. But does the controller know if what it wrote has actually been written to the hardware? It's that layer of hardware indirection that gets in the way: is the final processor lying to you (particularly with the huge number of fake storage products out there from USB sticks to 'hard' drives that aren't to flash that isn't actually the size you paid for...)?

 

The only practical ways of guaranteeing that are do do verify after write (but not perhaps immediately after write, to give buffers time to be cleared?) and at least make sure that what you wrote, stayed writ!

 

Neil

p.s. this is exactly why reel-to-reel tape machines have the replay head *after* the record head... you can always monitor what's being recorded.

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

ka7ehk wrote:
I don't know of any way with a desktop computer to access data on an SD card at the block level; none of the code development tools that I use has that capability, as far as I can tell.
Well obviously their is WinHex from XWays that is "FAT aware" and allows you to extract various blocks from a card but that is a manual/GUI process. If you just want to read a card "raw" in Windows I'd do exactly the same as you would in Linux and use dd. There are Win versions of dd.

 

Some good stuff in this thread:

 

https://superuser.com/questions/...

 

Actually I suppose the key thing in all that is the Windows syntax 

if="\\.\s:"

If "\\.\x:" allows you to open the whole of "drive x:" as a file then I guess this should also work in Windows C++ code with a call to CreateFile() ? (that API has always been a misnomer - it doesn't really mean "create a file" but "create a handle to a file so I can get access - whether that be read or write".

Last Edited: Mon. Mar 1, 2021 - 09:38 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The average microsd is around 16G these days - that's a mighty big file! Fat32 might choke!

 

As an aside, you can get high endurance microsd normally meant for use in dash cams etc. These are rated for much higher write operation. Probably not an issue for the current discussion.

 

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

Another thought that came to me whilst looking at a strip of 16MB serial flash devices on my desk is to use serial flash for your main storage and then only copy to the sd for transfer. Assuming the likes of 16MB is adequate for the task. Maybe a more robust solution with a better guarantee of working life as the manufacturer will spec something like 100,000 erase/write cycles per sector.

 

Then that might open up other options like bluetooth or wifi that can be dormant until you want to extract the data. Especially with WiFi, your device can serve up the webpage to extract and display the data on a mobile device. 

 

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

Kartman wrote:
The average microsd is around 16G these days - that's a mighty big file! Fat32 might choke!

 

Definitely will choke on a file that big unfortunately (https://en.wikipedia.org/wiki/Fi...) -

 

Quote:
The maximal possible size for a file on a FAT32 volume is 4 GiB minus 1 byte or 4,294,967,295 (232 − 1) bytes

 

 

Wayne

East London
South Africa

 

  • No, I am not an Electronics Engineer, just a 54 year old hobbyist/enthusiast
  • Yes, I am using Proteus to learn more about circuit design and electronics
  • No, I do not own a licensed copy of Proteus, I am evaluating it legitimately
  • No, I do not believe in software or intellectual property piracy or theft
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If I am going to write and read raw blocks without having to remove the storage, then maybe a common NAND flash might be a better choice than microSD?

 

8GB is a bit more than a year of data at the highest sampling rate for this device. Service has to be done in the 45 day range, just because of batteries. The next generation device will have provision for external power sources (such as solar) and that will allow longer data records. THEN, the sheer time to transfer data, out, becomes a significant issue.

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

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

How much is an 8GB standalone NAND going to cost compared to an SD/MMC of that (or probably much larger) size?

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

NAND will cost more, for sure, but not having a socket reduces the premium. Having one part instead of two will save a little. Reliability of soldered connections vs sliding contacts may justify the remainder of the premium. One thing appears pretty certain - microSD supply chain seems not very stable (spotty availability of specified parts) and you have little control over the electrical characteristics of what you get. NAND flash, on the other hand, seems to be well-characterized with defined write and read power consumption and active times. That has been a major problem with this product.

 

Not writing off microSD, just recognizing the usefulness of a careful comparison.

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

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

ka7ehk wrote:
If I am going to write and read raw blocks without having to remove the storage, then maybe a common NAND flash might be a better choice than microSD?
SD has

  • block addressing
  • bad block management
  • power failure recovery

https://github.com/sigrokproject/libsigrokdecode/blob/master/decoders/common/sdcard/mod.py#L47 (block write)

 

Conversely

NAND Flash Driver - µC/FS Documentation 4.07 - Micrium uC/ Documentation

 

File systems are in some (most?) RTOS.

 


Micrium µC/OS to be open source | AVR Freaks

 

edit :

MPLAB® Harmony v3 Libraries - Developer Help

 

"Dare to be naïve." - Buckminster Fuller

Last Edited: Mon. Mar 1, 2021 - 09:01 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you use ‘normal’ NAND devices, then you need to manage all the evil that it brings (and that the sd hides). There is emmc, but the packages are usually BGA which makes assembly more of a challenge.

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

ka7ehk wrote:
One thing appears pretty certain - microSD supply chain seems not very stable (spotty availability of specified parts) ...
Product Life Cycle Management at its best. Learn more. - Swissbit

20 week lead time per Mouser Electronics for one of nine industrial 8GB microSD cards by Swissbit.

 

"Dare to be naïve." - Buckminster Fuller

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

I'm not clear on the use case.

Is the sequence write write ... write read erase

Rinse and repeat?

I gather it's text.

 

Use the card as a tape.

To write a string as part of file 6,

write '\6' followed by the string.

To write mostly complete blocks,

you might want a buffer.

Linux, and I expect Windows, can open an SD card as a single file

and read it as an ordinary file.

Simple code on a PC should have no trouble doing the necessary conversion.

 

 

Moderation in all things. -- ancient proverb