LDV_Due_2:59: error: 'REQ_PIOC_PDSR' was not declared in this scope
'REQ_PIOC_PDSR' was not declared in this scope
If the error statement is a cut and paste, then there is a typo in your code.
REG not REQ.
LDV_Due_2:59: error: 'REQ_PIOC_PDSR' was not declared in this scope
'REQ_PIOC_PDSR' was not declared in this scope
If the error statement is a cut and paste, then there is a typo in your code.
REG not REQ.
Dang, you got me... It's working! Binary data now! thanks!!
Any idea on the baud rate and why I can't hit 921600 baud without funky data?
See what you can do with
Serial.write((REG_PIOC_PDSR);
I lack knowledge of the Due and the 32 bit architecture.
Serial.write() in the 8 bit ATmega 328 architecture sends bytes instead of the number representation as a string of chars. If things are similar with the Due, Serial.println((REG_PIOC_PDSR, BIN) will send 32 bytes as chars and Serial.write(REG_PIOC_PDSR) should send 4 bytes but the value may need to be broken down.
EDIT: I think this is the syntax to send the full 32 bits of the port as 4 bytes. There may be endian issues.
Serial.write((byte*)®_PIOC_PDSR, 4);
Serial.write('\n');//comment out the separator for increased speed if you don't need it
I'm not sure what the options are in RealTerm to display or save it when sent as bytes.
Any idea on the baud rate and why I can't hit 921600 baud without funky data?
If now you are sending 32 characters with the full Port, you may be able to mask off half of it and only send 16. Alternatively, your idea to send the decimal equivalent with Serial.println((REG_PIOC_PDSR, DEC) should send fewer characters.
What do you mean by this question? Like the RS232 command from the original manufacturer software (FIND) to control the signal processor?
Does this device continually output data to the (missing) ISA card or only when you send a command to measure flow?
If it's outputting data continually then how many samples do you need to determine the flow rate?
If it only outputs data when you send a command to measure flow then how much data (samples) does it send back (dataset)?
I tried this:
Serial.write((REG_PIOC_PDSR);
But in my exported text file, I'm getting junk data (goes on forever):
ÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀ
I also tried:
Serial.write((byte*)®_PIOC_PDSR, 4);
Serial.write('\n');//comment out the separator for increased speed if you don't need it
But similarly, getting this in my exported text file:
ÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
ÀÿÀÿÿ
ÀÿÿÀÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
ÀÿÿÿÀÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
À
À
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
ÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
Àÿÿ
More dummy junk data?
I'm not sure what the options are in RealTerm to display or save it when sent as bytes.
On the Display tab in RealTerm it shows the options of which the data can be displayed in the terminal window (but this doesn't change the format of what gets stored in the output text file). Is that what you're curious about?
If now you are sending 32 characters with the full Port, you may be able to mask off half of it and only send 16. Alternatively, your idea to send the decimal equivalent with Serial.println((REG_PIOC_PDSR, DEC) should send fewer characters.
I tested that, and got this:
2147483584
2147483584
2147483584
2147483584
2147483584
2147483584
2147483584
2147483584
2147483584
2147483584
2147483584
2147483584
2147483584
2147483584
2147483584
2147483584
2147483584
2147483584
2147483584
2147483584
2147483584
2147483584
2147483584
2147483584
2147483584
2147483584
2147483584
2147483584
2147483584
2147483584
2147483584
2147483584
2147483584
2147483584
2147483584
2147483584
2147483584
2147483584
What are these numbers, the decimal version of what we were getting before? And I thought the DEC values were "1" since all I got previously were rows of "1"... if this is the DEC value, then is "1" not DEC values?
Also, when I use Serial.println(REG_PIOC_PDSR, BIN); I get rows of:
1111111111111111111111111000000
1111111111111111111111111000000
1111111111111111111111111000000
1111111111111111111111111000000
1111111111111111111111111000000
1111111111111111111111111000000
1111111111111111111111111000000
1111111111111111111111111000000
1111111111111111111111111000000
1111111111111111111111111000000
This is more like what I'm looking for, the binary values of each pin. However, there are 31 binary values per row. And according to the port pin mapping here, port C only has 24 pins. What's your take on what's going on here?
I haven't masked any pins yet, currently trying that now. In the meantime, what do you make of all this? Are the previous case with rows of "1", are they not DEC values? And how is it possible to get 31 binary values when port C only has 24 pins?
I know this is a lot to work with, but I really appreciate your help!!!!
Riva:
Does this device continually output data to the (missing) ISA card or only when you send a command to measure flow?If it's outputting data continually then how many samples do you need to determine the flow rate?
If it only outputs data when you send a command to measure flow then how much data (samples) does it send back (dataset)?
Once the signal processor is initiated (via manufacturer software, FIND), and the CPU_READY pin on the (missing) ISA card is activated, then it "stands by" until particles/flow is introduced. The device begins to output data to the ISA card when particles passing through the measurement volume reflects light back to the probe and the signal processor outputs data to be sent to the ISA card. So technically, there's no command to measure flow, but rather setting the CPU_READY pin allows it to be "ready" to capture any flow data when available.
We have another LDV system in the lab where 10s of thousands of samples per second were collected for a few seconds to acquire the velocity of the flow. So it's not too far-fetched to hope at least several thousands of samples per second (but presumably varies with different LDV systems).
There's no command to be sent to measure the flow, except initializing the signal processor through the software (just turns it on and ready), and setting the CPU_READY pin. It should collect however much particles that pass through the measurement volume in the flow for however long the flow is introduced. Generally several seconds is more than enough to collect enough samples to validate the velocity at that point in the flow. The maximum rate the (missing) ISA card was spec'd to collect at was 287,000 words/sec (word = 16 bits). If in reality it collects 100,000 words/sec (arbitrary number, we don't really know what this true rate is), then given say 4 seconds of collection, we're talking 400,000 words total over 4 seconds. This number would change based on how many words are actually collected (unknown, we only know the max is 287,000/sec) and how many seconds to run the flow for.
Does this explanation help? What are your thoughts?
Quick question. Is it showing up with 31 binary values because of the numbers in the pin mappings for port C? I notice that port C will start at C1 (no C0 listed but other ports have A0 and D0) and end up at C30 (while missing some numbers in between). I suspect port C also has pin C0 (just not available), thereby having a total of 31 possible pins from C0 to C30. Is that why I get rows of 31 binary values?
This is my current code (without an interrupt yet, just reading data pins in a loop):
const int PULSE_PIN = 2; //aka CYCLE_REQUEST
//const int CPU_READY = 38; // directly hooked to 5volt, need to set all the time
const int DATA_HOLD = 51;
void setup()
{
Serial.begin(460800);
pinMode(33, INPUT); // DB00 C1
pinMode(34, INPUT); // DB01 C2
pinMode(35, INPUT); // DB02 C3
pinMode(36, INPUT); // DB03 C4
pinMode(37, INPUT); // DB04 C5
pinMode(38, INPUT); // DB05 C6
pinMode(39, INPUT); // DB06 C7
pinMode(40, INPUT); // DB07 C8
pinMode(41, INPUT); // DB08 C9
pinMode(44, INPUT); // DB09 C19
pinMode(45, INPUT); // DB10 C18
pinMode(46, INPUT); // DB11 C17
pinMode(47, INPUT); // DB12 C16
pinMode(48, INPUT); // DB13 C15
pinMode(49, INPUT); // DB14 C14
pinMode(50, INPUT); // DB15 C13
pinMode(DATA_HOLD, OUTPUT); // DATA_HOLD
pinMode(PULSE_PIN, INPUT); // CYCLE_REQ
}
void loop()
{
digitalWrite(DATA_HOLD, LOW); // DATA_HOLD holds data
Serial.println(REG_PIOC_PDSR, BIN);
digitalWrite(DATA_HOLD, HIGH); // DATA_HOLD done and reset for next data set
}
waynewayne:
The maximum rate the (missing) ISA card was spec'd to collect at was 287,000 words/sec (word = 16 bits). This number would change based on how many words are actually collected (unknown, we only know the max is 287,000/sec) and how many seconds to run the flow for.Does this explanation help? What are your thoughts?
I think trying to increase the serial baud rate any more is a dead end as your never going to achieve the rate you need if this device is clocking out data at 287K words per second.
A good starting point now would be to find out exactly how much data would be transferred in 4 seconds not just the theoretical max. To do this you write a sketch that sets the CPU_READY pin and then counts and reads data for 4 seconds but discards the values, at the end of 4 seconds print the count. Do this several (tens, hundreds, thousands of) times with different flow rates to get an idea of the maximum data rate your expecting. Once we know this then we will know if Arduino is the tool you need or if you have to change to a different hardware platform.
Here is some code to pull the 16 bits of data out of the 31 bits of port C. It uses masking and bit shifting to select and eliminate bits. It's somewhat confusing, so I have left the Serial debug prints in place.
First, I would recommend that you pull the Data Hold line from D51 and move it to a different pin not on PortC. Then Pin51 can be used for data transfer, and it places the two useful data bytes on consecutive pins.
Second, I think that to debug the process, it will help to set up known data patterns on the Due pins instead of having them all high or low. You should be able to set up a bread board with 3.3v and ground lines so that the Due input pins can connected either high or low. The connections will create a HIGH and LOW byte of data. The layout is somewhat confusing because the port registers the pin numbers are arranged differently in the two bytes. When you call for the register value REG_PIOC_PDSR the compiler will know which pin is going to which register slot.
The values I selected for HIGH byte value will be B01001111 and the LOW B01001011. This is the test pattern I used for the posted code and will create the characters "O" (ascii 79) and "K" (ascii 75).
//these 8 pins will hold the low byte data B01001011.
pinMode(34, INPUT); // C2 connect to 3.3v
pinMode(35, INPUT); // C3 connect to 3.3v
pinMode(36, INPUT); // C4 connect to GND
pinMode(37, INPUT); // C5 connect to 3.3v
pinMode(38, INPUT); // C6 connect to GND
pinMode(39, INPUT); // C7 connect to GND
pinMode(40, INPUT); // C8 connect to 3.3v
pinMode(41, INPUT); // C9 connect to GND
//these 8 pins will hold the high byte data B01001111
pinMode(44, INPUT); // C19 connect to GND
pinMode(45, INPUT); // C18 connect to 3.3v
pinMode(46, INPUT); // C17 connect to GND
pinMode(47, INPUT); // C16 connect to GND
pinMode(48, INPUT); // C15 connect to 3.3v
pinMode(49, INPUT); // C14 connect to 3.3v
pinMode(50, INPUT); // C13 connect to 3.3v
pinMode(51, INPUT); // C12 connect to 3.3v
Here's the test sketch. I have shown some different serial output, and demonstrates some endian issues with a two byte write.
//emulate 16 bit data extraction from 32 bit
//using masking and bit shifting to select and eliminate bits
//31 bits to portC 11junk/8data/2junk/8data/2junk
//11+8+2+8+2
//the 2 bytes of valid data are B01001111 and B01001011
//decimal 79 and decimal 75 ascii char "O" ascii char "K"
//embed these values in 31 bits of complete PortC
//we don't care about the actual value of bits not used
//111 1111 1111 (0100 1111) 11 (0100 1011) 11
//xxx xxxx xxxx 0100 1111 xx 0100 1011 xx
const int PULSE_PIN = 2; //aka CYCLE_REQUEST
//const int CPU_READY = 38; // directly hooked to 5volt, need to set all the time
//const int DATA_HOLD = 51; //move DATA_HOLD to a different pin not on PortC
void setup() {
//these 8 pins will hold the low byte data B01001011.
pinMode(34, INPUT); // C2 connect to 3.3v
pinMode(35, INPUT); // C3 connect to 3.3v
pinMode(36, INPUT); // C4 connect to GND
pinMode(37, INPUT); // C5 connect to 3.3v
pinMode(38, INPUT); // C6 connect to GND
pinMode(39, INPUT); // C7 connect to GND
pinMode(40, INPUT); // C8 connect to 3.3v
pinMode(41, INPUT); // C9 connect to GND
//these 8 pins will hold the high byte data B01001111
pinMode(44, INPUT); // C19 connect to GND
pinMode(45, INPUT); // C18 connect to 3.3v
pinMode(46, INPUT); // C17 connect to GND
pinMode(47, INPUT); // C16 connect to GND
pinMode(48, INPUT); // C15 connect to 3.3v
pinMode(49, INPUT); // C14 connect to 3.3v
pinMode(50, INPUT); // C13 connect to 3.3v
pinMode(51, INPUT); // C12 connect to 3.3v
pinMode(DATA_HOLD, OUTPUT); // DATA_HOLD
pinMode(PULSE_PIN, INPUT); // CYCLE_REQ
Serial.begin(9600);//whatever
Serial.println("starting...");
//emulate PIOC with 31 bit value
//test value when not reading Due POIC
//111 1111 1111 (0100 1111) 11 (0100 1011) 11
long value = 0x7ff4fd2f;//31 bits of data with embedded "OK"
//long value = REG_PIOC_PDSR;//uncomment this for use with Due
Serial.println(value, BIN);
value = value & 0xffffc; //clear top 11 and bottom 2 bits with mask
Serial.println(value, BIN);
value = value >> 2; //shift away the lower 2 cleared bits
Serial.println(value, BIN);
//remove the two junk bits from center of data
int lo8 = value & 0xff; //mask and save lower 8 bits
Serial.println(lo8, BIN); //low byte
value = value >> 10; //shift away the lower 10 bits to clear middlel two
Serial.println(value, BIN); //high byte
value = value << 8 | lo8; //reposition the top 8 bits and add lo8
Serial.println("selected 16 bits from 32");
Serial.println(value, BIN);
//demonstate transmission as bytes and endian issues
Serial.println("Alternate Serial Transmission Options");
Serial.println(value);//send number as decimal 16 bits > 5
//send bytes and demonstrate endian issues
Serial.write(highByte(value));
Serial.write(lowByte(value));
Serial.write('\n');
// Serial.write((byte*)&value, 4);
Serial.write((byte*)&value, 2);
}
void loop() {}
EDIT: Correct byte count error in last line of code.
// Serial.write((byte*)&value, 4);
Serial.write((byte*)&value, 2);
waynewayne:
This SD card option isn't such a bad idea. I did come across it previously but held back to explore this .txt format option. Since you mentioned it, do you have any inputs on how fast it can run at? Would a SD card option enable me to, bottom line, store incoming data with rates up to 287000 or 240000 words/sec?
I did a simple benchmark, and it looks like the fastest serial baud rate I could get to work (on my Uno-compatible Arduino and RealTerm on Windows) - 230400 baud - is slightly faster than writing to the SD card.
Here's the code:
/*
* SD card vs. Serial speed test
* a very simple benchmark, to give some idea of the comparative speeds
* of serial and SD card
*
*/
#include <SPI.h>
#include <SD.h>
const long serialBaud = 230400; // serial baud rate, comparable to SD card speed
const int SDChipSelect = 8; // my SD card's chip select is connected to pin 8
const int numK = 500; // how many K's of data to write
File logFile; // make a file object
void setup()
{
Serial.begin(serialBaud);
Serial.println("Serial vs. SD card: who wins?\n");
Serial.println("Starting serial test...");
unsigned long time = millis();
for (int i = 0; i < 16 * numK; i++)
{
for (int j = 0; j < 63; j++)
{
Serial.write('x');
}
Serial.write('\n');
}
Serial.flush(); // wait for writes to finish
time = millis() - time;
Serial.print("Done! Baud rate: ");
Serial.println(serialBaud);
Serial.print("Elapsed milliseconds: ");
Serial.println(time);
Serial.println("\nNow the SD card...");
SD.begin(SDChipSelect);
logFile = SD.open("LOGFILE.TXT", FILE_WRITE);
time = millis();
for (int i = 0; i < 16 * numK; i++)
{
for (int j = 0; j < 63; j++)
{
logFile.write('x');
}
logFile.write('\n');
}
logFile.flush(); // wait for writes to finish
time = millis() - time;
Serial.print("Done! Elapsed milliseconds: ");
Serial.println(time);
}
void loop()
{
}
And here's the output:
...tons of 'x' characters, then...
Done! Baud rate: 230400
Elapsed milliseconds: 23042
Now the SD card...
Done! Elapsed milliseconds: 23809
I don't know if this is valid info for you, because there may be tricks to speed up either benchmark. I'm just trying to see for myself if there's a large difference between these two naive benchmarks.
If it were me, I'd try replacing SD.h with SdFat.h.
In fact, let me try that! It's easy!
Make this change to the code:
//#include <SD.h>
#include <SdFat.h>
SdFat SD;
and this happens:
Done! Baud rate: 230400
Elapsed milliseconds: 23042
Now the SD card...
Done! Elapsed milliseconds: 18784
So, there you go. Hope this helps.
Thanks for the responses! I just wanted to let you know I didn't forget your suggestions, I just haven't been able to try it yet but won't forget to! I appreciate it and I'll try those suggestions next, I just got caught up looking at this problem from a different angle, not that I'm neglecting your help
Here's a quick question for y'all. If a pin is designated to be an input, can it put out voltage?
In this LDV system, per the manual, it states that CPU_READY and DATA_HOLD are driven by the original board (hence it would be an output on the original board and this arduino, but would be an input on the LDV signal processor). However, when I connected a multimeter directly to the lines on the ribbon cable coming from the LDV signal processor, without the arduino connected, I'm getting 2.56 volts on both the CPU_READY and DATA_HOLD lines. Is something wrong? I presumed there should be no voltage on these lines on the ribbon cable since it's directly from the signal processor and should be input only (per the manual).
If I connect back the arduino and write LOW to the CPU_READY pin, then the multimeter still connected to the ribbon cable would read 0.01 volt. Didn't bother writing HIGH because CPU_READY needed to be at LOW to tell the signal processor it's ready to send data.
If I write LOW to the DATA_HOLD pin, the multimeter reading on the ribbon cable for this line would read 0.02 volt. If I write HIGH to this DATA_HOLD pin, the pin would read 3.30 volt. Both the 0.02 and 3.30v makes sense because that's LOW/HIGH on the arduino Due. But if I remove the wire between the arduino and the breadboard this ribbon cable interfaces to (i.e. multimeter reading only the ribbon cable) the voltage reads 2.56 volts.
Can there be voltage coming out of a pin from the signal processor when this pin should be an input? Maybe it's some sort of "standby" voltage or floating or something, but I would assume that for an input pin, there should be no outgoing voltage...
The input lines on the LDV signal processor that you are trying to measure are floating and you can read anything with your multimeter.
When those lines are connected to the Arduino you drive them Low or High. I recall from previous posts, that the grounds are tied, so that is OK.
You should verify that the 3.3v high signal level of the Due is seen as a high by the LDV, and it is not requiring a value closer to 5v.
The input lines on the LDV signal processor that you are trying to measure are floating and you can read anything with your multimeter.
When those lines are connected to the Arduino you drive them Low or High. I recall from previous posts, that the grounds are tied, so that is OK.
Do I need a pull-down resistor for both DATA_HOLD and CPU_READY on the breadboard? Would that display the ribbon cable voltage for, say DATA_HOLD, to be "0"?
You should verify that the 3.3v high signal level of the Due is seen as a high by the LDV, and it is not requiring a value closer to 5v.
I don't see anything in the LDV manuals that specify the HIGH/LOW voltage requirements. But I did measure the voltage of the other data pins right out of the ribbon cable, without arduino connected and with no data flowing, and all the data pins were at approx 3.72 volt (which I would assume is HIGH, because that's within the HIGH range for 5V, plus I don't have any at a LOW to quantify but I'd assume LOW is much closer to 0v)
Would these logic levels charts for 5V and 3.3V be the standard even for the LDV signal processor?
Do I need a pull-down resistor for both DATA_HOLD and CPU_READY on the breadboard?
I wouldn't think so as the input lines are always connected to an Arduino output which is either High or Low. The LDV should never be in doubt as to the state to the input.
Would that display the ribbon cable voltage for, say DATA_HOLD, to be "0"?
I would think so.
I don't see anything in the LDV manuals that specify the HIGH/LOW voltage requirements
I would think that the logic levels should all work, regardless of whether you are using a Due or Uno, but it's a little late in the game to be thinking about whether or not the LDV inputs are 5v tolerant.
The Due is not 5v tolerant on its inputs, but I think you already addressed this fact. What is the ouput level when the LDV is driving an output High?
I wouldn't think so as the input lines are always connected to an Arduino output which is either High or Low. The LDV should never be in doubt as to the state to the input.
This is where I'm suddenly confused. Let's temporarily put away the arduino for this scenario. I have the ribbon cable coming straight out of the LDV signal processor, and nothing else. I connect the ground lead of my voltmeter to one of the ground lines on the ribbon cable. I connect the positive lead of my voltmeter to CPU_READY, it reads 2.56 volts. I repeat this by moving the positive lead to DATA_HOLD, and it also reads 2.56 volts. Nothing else is attached to the ribbon cable....
What in the world...? Why would an input on the signal processor be putting out a voltage difference relative to ground?
And the output level when LDV is driving an output HIGH seems to be 3.72 volts
Why would an input on the signal processor be putting out a voltage difference relative to ground?
I am not a hardware guy, so I can't really tell you why a CMOS logic gates behave like they do, but this article explains some of it http://www.allaboutcircuits.com/textbook/digital/chpt-3/cmos-gate-circuitry/
Be aware, that TTL and CMOS can refer to both logic levels, and semiconductor fabrication details.
Thanks for the link! Some of it was hard to digest (lots of acronyms) but I think this kinda explains the gist of it:
Their inputs are, however, sensitive to high voltages generated by electrostatic (static electricity) sources, and may even be activated into “high” (1) or “low” (0) states by spurious voltage sources if left floating. For this reason, it is inadvisable to allow a CMOS logic gate input to float under any circumstances. Please note that this is very different from the behavior of a TTL gate where a floating input was safely interpreted as a “high” (1) logic level.
It sounds like this voltage is from a floating input. I'm guessing the pin (with the floating voltage) in the LDV uses a TTL gate (not that it matters), right?
If so, how do I keep it from floating? Doesn't that mean I should use a pull-down resistor then, to pull the voltage coming from the LDV's DATA_HOLD and CPU_READY pins down close to 0?
If so, how do I keep it from floating?
You connect to to an Arduino output which is either High or Low. The Ardudino output can both source and sink current, and it is never in anything other than High or Low state.
From the summary section
Pullup and pulldown resistors are used to prevent a CMOS gate input from floating if being driven by a signal source capable only of sourcing or sinking current.
So I guess the arduino output on that pin would "override" whatever voltage (if any) is showing up coming from the pin from the signal processor?