Main Site Documentation

Additional Memory


#1

I am working on a application where I need high speed memory, faster than what I can write to either the microSD or USB drive.
Is there a way to add additional RAM or other high speed memory?


#2

You can switch to high end devices like EMX or ChipworkX.

If you give us an idea of what “high speed” means to you then we can give you a better answer…is “high speed” 1MB/sec or 100MB/sec?
What exactly are you trying to accomplish?


#3

Sure, I am trying to read all 6 analog ports and record the data to either the SD or USB drive. I can scan the analog ports quickly, but I can’t write to the memory fast enough. I would like to scan all 6 channels at a speed of at least 100Hz. I can only get about 20 Hz at most read and written into the card.

Also, there is not enoguh RAM to support writing to RAM for a couple minutes and then copying the data to the SD or USB drive.

Does this help?


#4

6 analog at 100 times a second, that is 600bytes/sec
You should have no problem writing this to SD or USB. You should be able to write thousands of bytes/sec on SD card. You need to find out what is the bottle neck in your design. Maye it is taking too long to convert data?
It will also be slow if you are writing single bytes…you need to send larger buffers…so, take the data from analog, store in a buffer (maybe 1000 bytes buffer) then send all data to SD card.


#5

It’s more than that each analog value is an integer so 4 bytes each not one. I write a string of data for all 6 channels at once to the SD card. There is not enough RAM to make use of a buffer since writing from the buffer to SD card may take longer than reading the next set of values.

I have tried various methods, but the bottom line is that I either need faster memory or more RAM.

Try setting up a Timer Interupt for 10ms and see how fast you can write to the SD card.


#6

We can write over 100,000Bytes/sec easily…last time we tested it! Maybe creating strings is what slowing it down.

Actually, it can be 500,000bytes/sec in some cases


#7

I’ll try writing bytes instead from each analog channel and see what happens.


#8

Writing bytes to the SD card and reading all 6 analog channels I was only able to get about 600 channels/sec or 100Hz sampling rate.

I noticed that the return value for Analog.Read is int. Since it’s going to be a positive value (0-3.3v) you might want to return a ushort instead of a signed int. I only save the 2 LSBytes on the SD card to save space and reduce the write time.

I use a Timer Interupt to control the scan rate so as to produce consistent results rather than a continuous WHILE loop. If I use an interval time of less than 10ms the sampling becomes skewed because the processing becomes to slow.


#9

NETMF isn’t a real-time operating system and so you can’t really control a fixed rate to do a certain task. For example, if GC kicks in then you will have a different delay than what you had expected.

This is similar to how Windows works. You click on something but sometimes it takes longer then expected for that action to take place.

This doesn’t mean the system is unstable, it just means that actions/events/delays can take longer then what you had planned for.


#10

Could you set a pwm to an interrupt pin and have it record at interrupt or would gc slow that down as well?


#11

You could also just use a timer to trigger an interrupt. I suspect that if in the interrupt routine you just read the input and stash the value in a buffer then you could write the contents of the buffer to the SD card a chunk at a time in a separate thread. Decoupling the reading, which is time critical, from then writing which is not should help.


#12

You can’t do that, see the FAQ where we explain what is “real time”


#13

You can’t do what? I’m not talking about doing anything in hard real time. But by separating the time critical operations and the not time critical it should help performance. You still won’t have a fixed scan rate, but if the data is timestamped it may not make a difference.


#14

Yes this depends on the end application and what is their real time needs


#15

I have the same problem. This is what I was trying to do:

  1. Sampling 9 analog channels on a custom designed sensor board equipped with a separate micro controller. Sampling rate is 50Hz
  2. After collecting all the data and creating a packet, handshaking with FEZ domino and sending all data (62 bytes) via SPI interface to FEZ.
  3. Writing to USB thumb drive after buffering packets for a second (total 3100 bytes).
  4. Packets missed as writing to USB is very slow. Even tried to use multiple threads to read packets using a high priority thread and writing to USB using a low priority one. Still didn’t work.

I just came across one comment stating that data can be written at 500,000Bps. I really don’t see this happening. Either I am missing something or misinterpreting this statement. What if I call the write function of FileStream to write 3100 bytes and after next 20 ms I am expecting data from my sensor board to be ready for transmission to FEZ. Will FileStream write these 3100 bytes in less then 20 ms.
Help/ suggestions will be appreciated.


#16

Fez will have no problem writing your 3k every second. The average write speed is much much more than what you need! You need to see where fez is not keeping up. Maybe you are processing every byte and that is the problem

Try to write the data you read from spi as is. You should have no problem

Not sure how your question is related to this thread so it maybe a good idea to start a new thread