Development using Arduino...

My sensor output is going to be pluses, so ill be using a timer to process them.

Also, any comments on the processor choice given all the additional info?

The 1284 board I showed uses FTDI based MIKROE-483 from Mouser for on-board USB, or an offboard FTDI module like FTDI Basic, CP2102 module, etc.

Is using an ftdi fairly straight forward? is it plug and play so to speak? I mean i know that you'd have to interface with it in code, but anything else beyond that?

I also need to store about 1000 float values on the EEPROM. The reading will range from 0 to 10,000. So if i'm storing float values, then would it be safe to assume that I'd need: 1000 x 4 = 4K size EEPROM?

Anyone?

Patience grasshopper. Some of us have day jobs.

maverickpilot:
Is using an ftdi fairly straight forward?

Yes.

is it plug and play so to speak?

Yes.

I mean i know that you'd have to interface with it in code, but anything else beyond that?

The board is presented to the computer as a standard serial port. Just like most other Arduino (and compatible) boards.

I also need to store about 1000 float values on the EEPROM. The reading will range from 0 to 10,000. So if i'm storing float values...

Have you considered storing fixed-point values instead?

...then would it be safe to assume that I'd need: 1000 x 4 = 4K size EEPROM?

Exactly.

Sorry Coding, got a little anxious there :slight_smile:

Thanks for your reply. Storing fixed point would mean that I'd have to multiply everything by 100, and my highest value would be 10,000. I'd have to get into storing doubles then. I also have to store the time of the reading taken.Don't know how i'm going to do that. I'm thinking 4K won't be enough, I might have to get a separate EEPROM IC.

Is there any other way to store fixed point and later convert to float?

maverickpilot:
Storing fixed point would mean that I'd have to multiply everything by 100, and my highest value would be 10,000. I'd have to get into storing doubles then.

Huh?

Is there any other way to store fixed point and later convert to float?

Yes. But you need to state how many decimals you want to store (bearing in mind 10,000 already gives you 4 significant digits and I'm going to make you prove you need any decimals).

I also have to store the time of the reading taken. Don't know how i'm going to do that.

Store offsets from the start time. What do you want the granularity and accuracy to be for the time?

I'm thinking 4K won't be enough, I might have to get a separate EEPROM IC.

They are certainly much cheaper than the time you will spend trying to squeeze the data into 4K.

[quote author=Coding Badly link=topic=152522.msg1147742#msg1147742 date=1362736812]
Huh?[/quote]
Well if I just divide everything by 100 (for two decimals) after retrieving the data then I can store everything as a whole number. I've never used this technique myself, I read about it somewhere.

Yes. But you need to state how many decimals you want to store (bearing in mind 10,000 already gives you 4 significant digits and I'm going to make you prove you need any decimals).

Ok:
0.01 to 9.99
10.0 to 99.9
no decimal from 100 to 10,000

Store offsets from the start time. What do you want the granularity and accuracy to be for the time?

Down to the second. So for example: reading = 10.15, time = 09:30:54 (hh:mm:ss) and date in dd-mm-yy. Does that answer your question?

They are certainly much cheaper than the time you will spend trying to squeeze the data into 4K.

Ok, so then I've got to add that to my project then.

Ok:
0.01 to 9.99
10.0 to 99.9
no decimal from 100 to 10,000

Which raises the question, what are you reading that gives you 0.01 accuracy over that range?

No negative values?

Which raises the question, what are you reading that gives you 0.01 accuracy over that range?

No negative values?

It's actually a range of the same sensor, but with different resolution levels.

So one sensor will give me a reading from 0.01 to 100, another from 0.1 to 1000, and then lastly 1 to 10,000.

Maybe I'd have to have 3 different versions?

EDIT: No negative values

Only two bytes are needed. Use two bits to indicate the range and the remaining 14 bits to store the value...

0.01 to 9.99 --> value * 100 is stored
10.0 to 99.9 --> value * 10 is stored
no decimal from 100 to 10,000 --> value * 1 is stored

The drawback is the value has to be decoded and you absolutely cannot try to store negative values or values over 16,385 (meaning you need to include the clamps).

This should get you started...

union
{
  typedef struct
  {
    uint16_t range:2;
    uint16_t value:14;
  };
  uint16_t storeThis;
}
cracker_t;

As long as you only write to range / value and only read from storeThis you should be OK with strict aliasing rules.

But what about time stamp?

Also, Why does the Arduino Mega not use FTDI? Is there a limitation there?

maverickpilot:
Also, Why does the Arduino Mega not use FTDI? Is there a limitation there?

It makes the board more versatile. You can reconfigure the board to be different USB devices (e.g. the board can be presented to the computer as a keyboard).

10,000 decimal is only 0x2710, could be stored as an INT.
1000 values only needs 2000 bytes to store.
Then add another INT with # of seconds since start, 65,535 = 1092 minutes = 18 hours. Is that enough?

Does this make the board native USB? So instead of a virtual com port the computer will recognize the board as a USB device? Like when you plug in a digital camera, it'll say "Sony DSCXXX" or when you plug in a phone it'll say the brand and model number?

Can I still use good old FTDI instead?

CrossRoads:
10,000 decimal is only 0x2710, could be stored as an INT.
1000 values only needs 2000 bytes to store.
Then add another INT with # of seconds since start, 65,535 = 1092 minutes = 18 hours. Is that enough?

Actually, no. I need a RTC, that'll display time and date info on the screen at all times. And at the click of a button the current reading should be stored along with the time and date info. It'll be rolling list, so when the user gets to reading number 1000, it would automatically start again from reading number 1.

I'd go with external SPI interface part then, either EEPROM or FRAM (ferro-electric RAM; has SRAM access speeds, EEPROM data retention but without the write limitations/byte. Mouser.com has a good variety of them). Store as much as you want per logged event.

I use FTDI in my projects. No messing with additional programming of 16U2 part for a USB interface.
I add a socket to plug one of these in and not mess with soldering the TSSOP package down:

MIKROE-483usb_uart.jpg

maverickpilot:
Does this make the board native USB?

"Native USB"? That's an odd phrase.

So instead of a virtual com port the computer will recognize the board as a USB device?

Virtual com ports are a particular type of USB device. But I understand what you mean.

Like when you plug in a digital camera, it'll say "Sony DSCXXX" or when you plug in a phone it'll say the brand and model number?

Exactly. On this forum, MIDI and HID (keyboard or mouse) seem to be the most commonly mentioned USB devices. It is possible to mimic any USB device (e.g. storage, camera, joystick).

And at the click of a button the current reading should be stored along with the time and date info.

A range of days with a granularity of one second. If two bytes is used the range is about 3/4 of a day. Three bytes gets a range of 194 days.

Two bytes for the value plus at least three bytes for the time-offset with at least 1000 values stored means you have exceeded the available EEPROM. It's time to shop for a FRAM.

...oh, wait... Are you going with the 2560 or the 1284?