File read/write in NETMF vs ALFAT

Hi All:
I am looking for some general advice on building a robust means of data storage including configuration parameter storage. This is for a data logger/ controller application. It will likely be done with a Raptor or similar. On power up I need to read configuration parameters, update information like the time/date it was last started, During operation, performance data will be logged at <10 frames per second, and < 150 bytes per frame.
Each time the system is powered up, it will start recording to a new file.
This will be a battery powered product. It is likely to be powered from external sources, and accidental disconnect of power is likely to occur, at least sometimes.
So my question is if I should expect better results by off loading the storage requirements to an ALFAT subsystem, at least as it should conduct file operations for shorter periods of time? And perhaps it has better built in functionality to protect data/file structure integrity?
In looking at the support forum I did not see much in the way of combinations of ALFAT and NETMF, and did not see any ALFAT Gadgeteer modules, so should I take it as a sign that these products are not used together much?
If ALFAT+NETMF is a good way to go, is there any example code, or is it just so easy that examples are not needed?

Thanks for any ideas.

1 Like

I when ahead and ordered an alfat module, but have searched high and low for some code examples that take the command set and impliment it in NETMF, but was unsuccessful.

The command set from GHI is somewhat primitive compared to either the NETMF or Tiny File System commands, so a driver that creates more friendly code will have to be created and tested (several days work, for me).

@ GHI - are there really no code examples for GHI NETMF boards? I would think you folks would be the experts on how to put ALFAT on NETMF in a user friendly way.

Correct there is no example but the commands are very simple. Most alfat users are not netmf users.

@ Gus - I was looking for the C# examples that used the Alfat-mini (f20-usd) board.

But GHI has none? Sure, the protocol is simple, but I just assumed that someone would have used one of these file system boards from .netmf.

A tinyclr c# namespace with a tiny stack of convenience functions would go a long way

I think the question is more about speed as @ mtylerjr is looking at putting an object in space. :open_mouth:

@ Sprigo - Lol, not quite space. I am aiming for 1KM altitude this first try.

But I am trying to open a file on a microSD card on an F20-uSD module ([url][/url]) , from a G80TH board ([url][/url])

The simplest way seems to be to just wire up the RX/TX/Busy pins on the F20-uSD module to Com1TX/Com1RX and some other pin to pull high for the “Busy” on the G80TH (the F20-uSD module wont send data back unless that pin is pulled high, from what I can gather from documents) + power/ground.

So, I was expecting to have to send the alfat file system commands ([url][/url]) over the com port.

From other comments it would appear I need to do this the “Windows UWP” way, which I have not done before, and which seems to rely on enumerating the serial com ports (devices) into a collection of device objects… and going from there. Trying to find examples of this wasn’t going too well during the brief amount of time I had to look at it yesterday.

I was just hoping that someone, somewhere had an example of interfacing with an alfat device (F40-uSD or F20-uSD) from any .net device (C#), netMF or UWP. Or even a similar ascii command/response device with a different protocol. So I could write something using the TinyCLR OS, which I am trying to use on the G80TH.

I might not even be able to use the F20-uSD now though- I accidentally applied 7.4v to it last night for a few moments. I saw the tiny +5v in the top corner of the f20-usd schematic, but I also see the " communicates over UART with the host system and only needs 3.3V, GND, TX, and RX to operate." - either way, 7.4v was too much and the microSD card burnt out (tiny little heat bubble) but I can’t yet tell if I zapped the F20-uSD itself.

So maybe this is all moot and I need to use my sparkfun OpenLogger ([url][/url]) instead. Which would make me a little sad, because I wanted to use as much GHI stuff as possible. But even if I use that, from TinyCLR, I’m going to need to find a decent example of communicating via the com port using the UWP style,

I’d suggest that you take all conversations about TinyCLR OS out of threads like this - especially since it’s started by someone else. Ask specific things around serial ports for TinyCLR OS in that thread.

As far as looking at other ASCII protocols, look at ESP8266 implementations. But the ALFAT example code is nowhere near as challenging as AT style responses.