Design Help

Discovery

I am sketching out the design for an event monitor that will detect eight channels of analog and sixteen channels of digital signals.
A real-time clock will be needed to mark the events.
A USB-2 or -3 jump drive memory will be needed for writing, reading, and erasing data.
An LCD display will be used to show that the unit is armed and operating.
The USB memory will be removable and readable by a laptop computer for extensive data analysis.
I would like to build the monitor using a Propeller Multicore processor.

Has the Propeller been used to interface with USB memory...if so, how would I proceed with the design?
Has an accurate real-time clock been implemented in a COG...if so how?

Sincerely.

Discovery

Rayman

I'd recommend using SD card instead of USB memory stick...
It's easy to connect Propeller directly to SD card using four pins.
Look for FSRW in forum or OBEX for details.

You can use a COG as RTC and it would be pretty accurate.
But, you'd have to reset the time if you cycled power.
There is a link to a Prop only RTC here:
http://www.rayslogic.com/propeller/Programming/Programming.htm

ksltd

The SD card software requires about 23% of available memory. An alternative is to use the VINC1L to support USB memory sticks. A reasonable VINC1L driver is about half that size. In both cases, you'll be severely limited in terms of sustainable logged data rates. For example, while the VINC1L can sustain about 30KB per second, I see single 2kb writes that take as long as 300ms on a 2GB stick and as long as 3000ms on a 32GB stick. Those long writes requires that you either have massive buffering (not possible due to lack of memory) or very low requirements for logging bandwidth. And by low, we're talking around 5KB/S and being very, very thoughtful about how your memory stick is formatted and ensuring there's no fragmentation.

You don't mention your bandwidth requirements for logging, but I'd strongly suggest you start there in terms of your per-channel datum size, samples per second and file format overhead and determine the aggregate bandwidth you need to sustain to lay down your file.

Good luck.

Mike Green

The VINC1L does work with USB memory sticks and the delays that ksltd describes can occur with SD cards as well because of the wear-levelling software built-in in both cases and its interaction with space allocation. Pre-allocating space for your log files does help.

It's not possible to use USB-2 or USB-3 directly with the Propeller. There has been some code posted here that uses some shortcuts with USB-1.1 to interface directly with HID and memory devices, but it's not standard USB-1.1 protocol and it's fairly slow.

Tracy Allen

A salient question has already been asked: the rate at which you need to collect and log the data?

The newer VDRIVE3 uses a more recent, more powerful Vinculum chip, the VNC2 rather than the older VINC1L. It has a larger buffer, faster processor and therefore higher throughput. It is by and large backward compatible at the communications layer. The VDRIVE3 is a very nice option for mechanical integration onto a front panel.

The footprint of the original SD card driver, FSRW, is 1005 longs, a bit more than 3% of Prop memory. That is the base, before you start integrating it into a project. I use bst, which does not compile unused methods into the footprint. In that case the footprint increases as you build your application. Wayne, I'm wondering where you came up with the 23% figure?

Discovery

Oh...sorry about the data rate. I have a truck that, for some reason, applies a 2-ohm load to the 12-volt battery after the vehicle has sat for ten to fourteen days. The truck will not start due to low voltage and after three or four of these events the battery will no longer take a charge and must be replaced.

Figure less than 5KB/s for data rate. The device will be armed for a transition on an analog channel or digital channel and once triggered...all channels will be read along with the real-time clock and stored in memory.

I figure that with this Propeller based monitor...I can instrument the vehicle and eventually determine the cause of the problem.

I could use the SD card since it has driver software developed for use on the Propeller Activity Board. Good call.

I would like to change the real-time clock design requirement to be stand-alone and be kept alive with a battery on the PC Board. What would you recommend?

What about the LCD Display...will that be a problem?

Sincerely,

Discovery

Ariba

Tracy Allen wrote: »

.....

The footprint of the original SD card driver, FSRW, is 1005 longs, a bit more than 3% of Prop memory. That is the base, before you start integrating it into a project. I use bst, which does not compile unused methods into the footprint. In that case the footprint increases as you build your application. Wayne, I'm wondering where you came up with the 23% figure?

Tracy 1000 longs is not 3% of 32kByte memory, more like 12%. But this is still a lot lower than the 23% or 25% that ksltd mentoined several times here and in other posts. Perhaps he uses the FAT-Engine which is much bigger than FSRW.
You can do optimized versions for read only or with smaller SPI drivers (even slow Spin SPI) then it goes down to something like 600..650 longs (8%).
And it's also possible to access the SD sectors without a FAT filesystem then I guess it is more like 400 longs but I have no real numbers for that.

Andy

Tracy Allen

Quite right, I mixed up my bytes and my longs.
Results reported by the FSRW speed test program:
Block write 895 kb/s
Block read 440 kb/s
Buffer write 523 kb/s
Buffer read 438 kb/s
Putchar 14 kb/s
Getchar 17 kb/s

ksltd

Yup - I was quoting from the FAT engine, which is 1888 longs.

Peter Jakacki

Interesting speed figures. I am just using single sector reads and writes using a relatively slow SPI read/write of around 4MHz although I am looking at dedicating a cog and counters for faster transfers. However the Tachyon bytecode that handles the higher levels is quite fast and performing a 1M byte buffer write to sectors takes 6.981 seconds or an average write speed of over 1.2Mbits/sec. I'd like to see what a faster SPI will result in then and also multiple block writes.

The complete SD card drivers, the virtual memory layer, and the FAT32 drivers and utilities (dir ls append print save/load rom etc) take up around 4,800 bytes or 1200 longs.