Retrieving pin readings in a text file instead of via Serial Monitor

Other Hardware Storage
1

Hi folks,

I'm reading data on 16 pins on my arduino Mega and displaying the 0s/1s in Serial Monitor for manual copy/paste into a spreadsheet. With 16 bits = a "word", I'm hoping to reach close to 287,000 words/sec.

My code works but not fast (appx 4 words/sec); I suspect a "bottle neck" with Serial Monitor (i.e. I think Serial Monitor is too slow). I know it's been done where it was able to achieve incredible data rates for prolonged periods of time (i.e. overnight) but instead of viewing in Serial Monitor for copy/paste, it produced a text file on their laptop's desktop and had the 0s/1s listed like a log.

How do I have my arduino collect the data, and spit all of the data out in a text file? I don't need it to go overnight; but maybe 30 seconds or so, and collect tens of thousands of words. I've looked at EEPROM or Processing, etc, but prefer simply the arduino IDE generating a text file. Thoughts?

Thanks!
wayne

2

Post the code your using as 4 word per second is nothing like the Arduino is capable of outputting on serial.

You can speed reading even more by using port reading instead of pin reading if the pins are consecutive and on certain pins. What speed is your serial connection as speeding this up to 115200 will transfer data quicker than the de-facto 9600.
If all this is not fast enough then you can maybe send raw data (or hex) instead of converting to 0/1 text.

3

Oops of course, here it is:

const int PULSE_PIN = 2; //aka CYCLE_REQUEST

volatile int STATE = LOW;
volatile byte counter = 0; 

const int CPU_READY = 38;
const int DATA_HOLD = 39;

void setup()          
{
  Serial.begin(9600);    
  Serial.print("Start "); 
  Serial.println(__FILE__); 
                          
  pinMode(22, INPUT); // digital DB00
  pinMode(23, INPUT); // digital DB01
  pinMode(24, INPUT); // digital DB02
  pinMode(25, INPUT); // digital DB03
  pinMode(26, INPUT); // digital DB04
  pinMode(27, INPUT); // digital DB05
  pinMode(28, INPUT); // digital DB06
  pinMode(29, INPUT); // digital DB07
  pinMode(30, INPUT); // digital DB08
  pinMode(31, INPUT); // digital DB09
  pinMode(32, INPUT); // digital DB10
  pinMode(33, INPUT); // digital DB11
  pinMode(34, INPUT); // digital DB12
  pinMode(35, INPUT); // digital DB13
  pinMode(36, INPUT); // digital DB14
  pinMode(37, INPUT); // digital DB15
  
  pinMode(CPU_READY, OUTPUT); // CPU_Ready     digital 38     CPU_READY
  pinMode(DATA_HOLD, OUTPUT); // Data_Hold     digital 39     DATA_HOLD
  pinMode(PULSE_PIN, INPUT); // CYCLE_REQUEST  digital pin 2 CYCLE_REQUEST

//  digitalWrite(DATA_HOLD, HIGH); // starting with this line clear/reset

  attachInterrupt(digitalPinToInterrupt(PULSE_PIN), catchPulse, RISING); 

  digitalWrite(CPU_READY, LOW); // Tells sig processor to start sending data

  STATE = 0;
}

void catchPulse()                  
{                            
  STATE = 1; // data is present on data bus
  counter++; 
  digitalWrite(DATA_HOLD, LOW); // Data_Hold               
}                           
  

void loop()                      
{
  if (STATE == 1)
    {
    STATE = 0; //resets the interrupt flag    
    
    digitalWrite(DATA_HOLD, LOW); // Data_Hold

    Serial.print(digitalRead(37)); // DB15   //reversed! now 15 to 0, not 0 to 15
    Serial.print(","); 
    Serial.print(digitalRead(36)); // DB14 
    Serial.print(",");    
    Serial.print(digitalRead(35)); // DB13
    Serial.print(",");   
    Serial.print(digitalRead(34)); // DB12
    Serial.print(",");    
    Serial.print(digitalRead(33)); // DB11
    Serial.print(",");
    Serial.print(digitalRead(32)); // DB10
    Serial.print(",");    
    Serial.print(digitalRead(31)); // DB09
    Serial.print(",");
    Serial.print(digitalRead(30)); // DB08
    Serial.print(",");    
    Serial.print(digitalRead(29)); // DB07
    Serial.print(",");   
    Serial.print(digitalRead(28)); // DB06
    Serial.print(",");  
    Serial.print(digitalRead(27)); // DB05
    Serial.print(",");   
    Serial.print(digitalRead(26)); // DB04
    Serial.print(","); 
    Serial.print(digitalRead(25)); // DB03
    Serial.print(",");     
    Serial.print(digitalRead(24)); // DB02
    Serial.print(",");  
    Serial.print(digitalRead(23)); // DB01
    Serial.print(",");    
    Serial.println(digitalRead(22)); // DB00 

    digitalWrite(DATA_HOLD, HIGH); // Data_Hold done and reset for next set

   }

   else
   {

I guess I kinda skipped the code because I have another thread in the forum where people have been helping me out, so I don't think the code is the issue. But here it is for context anyway. Yes, I plan on modifying the reading by reading ports instead of pin by pin, and also plan on removing the "," (in there to help make it easy to paste into excel as csv).

There's essentially 16 pins that transmit binary data. Then there's 3 signal pins that manage the reading/timing/clearing of registers from the signal processor. I use an interrupt to trigger the reading of the 16 pins based on the status of one of the signal pins.

Any way I can "print" out these 16 bits to a text file via the USB cable that I can access on the computer?

4

Speeding up your serial speed to 115200 from 9600 will help a lot with the reading speed as when the serial output buffer fills Serial.print becomes blocking. (12x speedup)
Instead of printing 34 bytes per read (16 bits + 16 commas + CRLF) you could print it as hexadecimal instead and convert to binary on the PC, this would only need 6/8 bytes per read ('0x' + XXXX + CRLF). (4x speedup)

To capture output to a file you could use some com software like Putty/Realterm/terraterm to log com port session data to a file.

5

Speeding up your serial speed to 115200 from 9600

Why only to 115200, why not 250000?

To capture output to a file you could use some com software like Putty/Realterm/terraterm to log com port session data to a file.

I've just downloaded and setup CoolTerm, am I going in the right path? Should I be using a different com software (like the ones you listed)? Any tips/advice or things to keep in mind as I continue?

6

Also would using CoolTerm to generate a text file be sufficient to catch ALL the collected data? If so, is my hunch correct that Serial Monitor is actually pretty slow and doesn't display all data (esp if it's fast data)?

EDIT: I set up CoolTerm to an Arduino Uno I had that wasn't hooked up to anything, and used an infinite loop to read the pins (blank pins, since it wasn't hooked up). (I used 8 pins and read that twice per row to get 16 bits; only 12 digital pins available.)

I read rows of 16 bits, for ~60 seconds, and acquired ~1800 rows. It's an improvement from previously using Serial Monitor (on the Mega), which acquired approx 600-700 rows/words per minute; but still far from the 287,000 words/sec I'm looking for. Should I try another com software? Or is there another way that doesn't use com software?

7

I tried a few things: increasing baud rate, eliminating the commas, and replacing the logic to read port by port, instead of pin by pin. Here's the code I'm at now (just "dry runs" of reading the 16 pins with an infinite loop):

void setup() {
  Serial.begin(230400);

  DDRD = B11111110; // pins 1-7 outputs, pin 0 input
//  DDRD = DDRD | B11111100 ;
  DDRB = B00111111; // sets pins 8-13 as outputs

}

void loop() {

  Serial.print(PIND);
  Serial.println(PINB);

}

So under pin-by-pin reading at 230400 baud (CoolTerm doesn't allow 250000, maxes out at 230400), I'm getting an average reading of approx 56400 words/min, which is approx 940 words/sec. Then I modified it as seen in code above to read port-by-port, and was getting 334660 words/min, which is approx 5578 words/sec.

Questions:

  1. Did I set up the port-by-port reading correctly? In the setup portion I was imitating the example on the arduino pages, but realized the second line is probably irrelevant. Can someone explain this part?

  2. When I ingested data via CoolTerm into a .txt file, I noticed under pin-by-pin I was getting rows of "0000000000000000" (this is what I want), but under port-by-port I was getting rows of "10" and sometimes "30" or "32". What is that? Is it hex or something?

  3. Assuming #2 is resolved and I can identify the binary values of each pin. Going 9600 to 230400 baud increased rows/min from ~1800 to ~334600 (5578 words/sec), which is a 186 times improvement (or comparing to Serial Monitor, a ~800 times improvement). Since CoolTerm maxes at 230400 baud (anyone know why?) and arduino at 250000, (8.5% increase) maybe I need another com software that can do 250000?

  4. I also just bought the Due. At 84 MHz (over Uno's 16 MHz), could I reasonably expect a ~5.25 times improvement if I replicate it to the Due?

  5. Is there anything else I can do to increase the rate even more?

8

Welcome back.

With your port assignments, it looks like you are testing on a UNO or other ATmega328 arduino.

To output binary bytes on the Serial port, you need to use Serial.write().

void setup() {
  //Serial.begin(230400);
  Serial.begin(250000);

  DDRD = B11111111; // pins 0-7 outputs, pin 0 RX not used in sketch
  DDRB = B00111111; // sets pins 8-13 as outputs + 2 dummy pins

  PORTD = B11111111;//write output high makes printed character umlat y (ASCII 255)
  PORTB = B00111111;//write output high makes printed character ?(ASCII 63)
}
void loop() {
  Serial.write(PIND);
  Serial.write(PINB);
  Serial.write('\n');//comment out the separator for increased speed

  //time Serial output 
  static unsigned long start = micros();
  static unsigned long count = 0;
  count++;
  if ( count >= 8000)
  {
    Serial.println(micros() - start); //adjust count for 1000000=1second
    while (1) {} //stops output
  }
}

As expected from the analysis of baud rates and bytes in the previous thread, you can get a little over 8000 words + newline in a second. It will take some research on how to push out data faster than that. As stated before, leaving out the separator will get you up to 12,500 words/second. You will then have to parse the output.

  1. Is there anything else I can do to increase the rate even more?

There is the possibility of faster serial output of bytes using SPI to some sort of flash memory.

There may also be some sort of parallel memory and it would be possible to mirror the input registers to output registers and do parallel Port writes similar to the parallel port reads.

Do you know if the the original interface board had parallel output as well as input. How was it pushing data to the analysis program. It may be worth trying to reverse engineer how the original instrument worked.

I am still wary of trying to push more date through the system when you don't know if word A/B identification is necessary.

Is there some sort of calibration routine for the machine, where you start with a known input(particle size, air velocity,etc)? I would expect that with slower sampling rates of unchanging data you should be able to see something which makes sense .

9

waynewayne:
but still far from the 287,000 words/sec I'm looking for. Should I try another com software? Or is there another way that doesn't use com software?

287K words per second, I don't think your ever going to achieve that while saving to Serial unless the data your reading is able to fit in the MCU's SRAM and then write out to serial after reading.

I say 115200 baud as some older PC's serial hardware could not handle faster than this and might loose data.

10

@Riva---To capture output to a file you could use some com software like Putty/Realterm/terraterm to log com port session data to a file.

From realterm.soureforge.net

What Baud Rates does Realterm support?

Realterm will pass any requested baud rate through to Windows. Many other applications have a list of baud rates, but Realterm does not, it will request anything.

Mostly, if a baud rate is not accepted, there is no error or warning - it just does not work. Whether a baud rate will be work depends on two things Reaterm has no control over:

Will the driver and/or Windows accept a requested but possible rate?
Can the hardware divide its clock down to the requested rate?
Microsoft says this : "For all other cases, as long as the requested baud rate is within 1 percent of the nearest baud rate that can be found with an integer divisor, the baud rate request will succeed"

The most basic PC uart has a maximum baud rate of 115,200. Any frequency of 115,200 / N, can usually be requested. More modern PC's and laptops, usually have a higher maximum baud rate of 230,400, or 460,800, or 921,600. Actual serial ports usually have a maxium that is a multiple of 115,200. Once you have found the maximum, any baud rate of /N should work.

I have seen several references from people who have gotten 500,000 baud from the Arduino.

If you have realterm, I'd try set the baud rate to 460,800 and you could double the 8k words/sec you are getting at 230,400.

You are still a very long way away from what the instrument can output at max.

11

Thanks! Yes, I'm testing this currently on the Uno (just out of convenience since I had it lying around). I do have a Mega available, as well as a Due.

I tried your modified code, with Serial.write() and and unsigned long sections (not sure if I quite understand this portion of the code), but with RealTerm it gets me a blank txt file. I actually ran it at 230400 baud, even though you changed it to 250000 baud, because 250000 baud is not an available baud setting on RealTerm as well as CoolTerm.

There is the possibility of faster serial output of bytes using SPI to some sort of flash memory.

There may also be some sort of parallel memory and it would be possible to mirror the input registers to output registers and do parallel Port writes similar to the parallel port reads.

Could you elaborate a bit more on these potential ideas?

I'm not sure what you mean by whether the original interface board had parallel output as well as input. Basically the signal processor had a ribbon cable (guess it's parallel?) coming out to the interface card installed in a desktop. It also had DMA (direct memory access) with various registers that manages the data sets, has some assembly language work; is it worth looking into this DMA process? I kind of bypassed this DMA process just because the current approach was logically "simpler" but maybe I need to step back and look at the bigger picture again?

My approach to word A/B identification was to take the entire set of post-processing equations and shift it up/down one row to match the A/B sequence if it feels out of place. Other than that, I regretfully don't have any way to identify A/B words. Additionally, I suppose with a slower sampling rates, there would be less data (since there's less particles) so I plan to test that next. I couldn't test it before because with Serial Monitor getting maybe 400 rows of un-dummy (dummy data were rows of all 1's) data per min, it was 4 words/sec (far too slow). And, nope, there is no mentioning of any calibration routine for this machine (would've been nice though).

unless the data your reading is able to fit in the MCU's SRAM and then write out to serial after reading.

Riva, are you saying storing it in SRAM as a buffer, then move it serially out post-reading with RealTerm/CoolTerm? Would this be significantly faster? How do I store it in SRAM? Or rather, how do I quantify if and how much I can store in the SRAM?

12
  1. When I ingested data via CoolTerm into a .txt file, I noticed under pin-by-pin I was getting rows of "0000000000000000" (this is what I want), but under port-by-port I was getting rows of "10" and sometimes "30" or "32". What is that? Is it hex or something?

Any ideas on one of my previous questions? For the time being, I'll assume "10", "30", and "32" to be "words" too, esp with the following results.

I installed RealTerm (CoolTerm is maxed out at 230400 baud) and tested with the current arduino Uno. Incredible because I can reach much higher baud rates with RealTerm. Here are the results (some baud rates are repeated):
At 230400 baud: 339255 words/min (5654 words/sec)
At 460800 baud: 435800 words/min (7263 words/sec)
At 460800 baud: 436740 words/min (7279 words/sec)
At 921600 baud: 437589 words/min (7293 words/sec)
At 921600 baud: 436714 words/min (7279 words/sec)
At 921600 baud: 433616 words/min (7227 words/sec)

What I observed going up incrementally from originally 9600 baud to 230400 is a greater increase in the word rate. Even from 230400 to 460800 there is another increase. But it seems like from 460800 to 9211600 (double) the rate stays almost the same. Is it safe to suggest that these rates are staying the same because the arduino Uno is "capping out" at these rates?

Could I increase these rates further (and have it more noticeable at 921600) with the arduino Due? Given that it is 5.25 higher in MHz, does that translate into 5.25 times more word rate?

13

waynewayne:
Riva, are you saying storing it in SRAM as a buffer, then move it serially out post-reading with RealTerm/CoolTerm? Would this be significantly faster? How do I store it in SRAM? Or rather, how do I quantify if and how much I can store in the SRAM?

That is what I was thinking of but with you posts since then referring to DMA access etc I think you should explain in more detail (if you can) what this device is, what it does and why are you using an arduino to read the thing instead of a parallel port on the PC.
How much data needs transferring per session and in what time-frame must it transfer.

14

Sorry, I avoided diving too deep into the background to make it less confusing, but ironically this information would've helped.

BACKGROUND INFO:
I've been working on repairing a surplus Laser Doppler Velocimetry (LDV) system, which measures flow speed by crossing laser beams, and the velocity of a traveling particle could be measured based on the reflection of light off the particle.

There's several components to this LDV, but basically the end portion of the LDV is a signal processor, which connects to a desktop via a ribbon cable to an ISA board (installed on the motherboard) and a RS-232 cable. The ribbon cable carries raw velocity data and signal lines that manage the timings of readings, and the RS-232 is just a way to manage the signal processor's settings. The desktop has a software called FIND (Flow Intelligent Display) that allows the user to manage the LDV settings (tethered by RS-232 cable) and process collected data (data sent by ribbon cable to the ISA board).

This ISA board is missing (the LDV system was purchased from a surplus supplier). Luckily, the system came with just enough instructions to describe how to take the data from the ribbon cable and (through a series of equations) produce velocity data.

On the ribbon cable, the signal processor puts out a string of 16 bits (on 16 pins), a set of which is also known as a "word" (16 bits string). A pair of words (word A and word B, both different formats) contain velocity data (binary components into velocity equations = velocity data) that respond to a single particle passing in front of the laser intersection. In the flow of data, it sends the words in A/B/A/B/etc sequence. I need to capture this data, and break down the binary components, convert it to decimal value, and plug it into the velocity equations. Sadly, I don't have a way to identify which word is A or B, so I need to capture ALL the data, otherwise a missing word will throw off the equations.

Additionally, the ribbon cable also contain three signal lines: CPU_READY, CYCLE_REQUEST, and DATA_HOLD, which serve as communication between the signal processor and the original ISA board to let it know when to collect the 16 bit words. CPU_READY when active just means it's ready to begin ingest. CYCLE_REQ when active by the signal processor, means there's a word ready for collection. The ISA board activates DATA_HOLD, so that the signal processor holds the data in the register to give the ISA board time to read the data. When it finishes reading the data, the ISA board deactivates DATA_HOLD, and the signal processor clears the registers. This process repeats for each word.

The tricky part is that I don't know what the actual data rate really is.. all I know is that the original ISA interface board is spec'd up to 287,000 words/sec. Hence that's what I'm aiming for. Speed is an issue because the word A/B/A/B/etc sequence means if I lost a word here and there, it shifts the entire sequence (so I need the speed to be fast enough to catch every word).

I'm using an arduino because I know it's fast, and also it's a heck of a lot less expensive than traditional DAQ systems out there. But I don't really "need" to use an arduino, honestly I just want something that works at this data rate and can get all of the words.

What do you mean by using a parallel port on the PC, is there a potential solution there?

Also, any thoughts anyone, on my previous questions?

15

Another question (sorry), I found that the Yun has a clock speed at 16 MHz and a Linux Microprocessor at 400 MHz. Would this 400 MHz help increase my ingest speed to even higher rates? Or is that dependent on the 16 MHz clock speed?

16

Thanks for the explanation, It possibly helps to understand what's going on now.

As the LDV is sending A/B pairs are these just the Doppler shift of the split beam at any given moment in time or are they something else that is part of a dataset that is sent every time a reading is requested (over RS232).
If the A/B pair is just the Doppler shift of the split beam then the reading of just a single consecutive pair of words (A, B) will allow you to calculate a spot velocity for that moment in time and reading several A/B pairs would allow averaging the readings. The only problem with this is is you would need to know what reading is A and what reading is B to determine the direction of flow.

On the other hand, if they are part of a dataset then how big is this dataset?

To find this out (assuming it's not in your manual) you could maybe write a simple Arduino sketch that sends the RS232 request and then just counts & acknowledges the CYCLE_REQUEST (no storing of data) until no more data arrives and then just print the count.
If you know the count then you will know how much memory is needed to buffer a reading before the slow(ish) sending over serial to the PC.

I know nothing about the Yun so cannot help you there but I would consider the Teensy3.1 if you need a little more speed/memory.

17

In my opinion, the easiest way to do high-speed logging with an Arduino is to get an expansion shield with an SD card on it, then write your data to the SD card.

Here's one example:

(I'm using it, but it doesn't fit particularly well on a Uno because it bumps into the power jack.)

Once you've got an SD card hooked up, you can use the SdFat library to do high-speed data logging:

https://github.com/greiman/SdFat/tree/master/SdFat/examples/LowLatencyLogger

18

The only problem with this is is you would need to know what reading is A and what reading is B to determine the direction of flow.

Yes, that's correct. Based on the structuring of Word A and B format, I can't actually tell if a word is A or B. My "quick and dirty" solution is a spreadsheet that is set up with equations in A/B/A/B/etc format, and I plug in the collected data set into the columns that the equations calculate from. If the velocity data looks tangible/meaningful/reasonable, then I would assume that the data set was pasted in as A/B/A/B/etc order. If the entire set of data looks funky (i.e. velocity doesn't make sense, etc), then I would assume that the word order of the data set is actually B/A/B/A/etc; which I could fix by shifting the entire set of data down or up one row to match the A/B/A/B/etc data to the A/B/A/B/etc equations.

On the other hand, if they are part of a dataset then how big is this dataset?

I'm not sure what you mean, but if you mean the size of the data set, it depends. The original card is spec'd to run at "up to" 287,000 words/sec. I highly doubt that it is consistently running at this max rate, but have no evidence/data yet to suggest a more realistic rate. I also know that the signal processor can put out 120,000 words/sec per channel (2 channels), so a lower max to keep in mind is 240,000 words/sec. Not a major difference since they're both so high, but again I don't yet know the realistic rate yet. If data collection could occur over roughly 10-15 seconds, it'd be perfect. What I may use it for can require like 2-4 seconds, which yields less data. I'd multiply the seconds against the (unknown) data rate and that would be the size of the dataset.

To find this out (assuming it's not in your manual) you could maybe write a simple Arduino sketch that sends the RS232 request and then just counts & acknowledges the CYCLE_REQUEST (no storing of data) until no more data arrives and then just print the count.
If you know the count then you will know how much memory is needed to buffer a reading before the slow(ish) sending over serial to the PC.

Actually, this isn't such a bad idea. It'll help answer the question of data rate and who knows, if it's much higher than what arduinos can handle, I can save myself the heartache of going down further. Will look into this next.

In my opinion, the easiest way to do high-speed logging with an Arduino is to get an expansion shield with an SD card on it, then write your data to the SD card.

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?

19

So, using RealTerm, and the Due, I was able to modify the code to use port manipulation to read it faster. Reading the pins of port C in a loop (without data attached, so pins should read 000000etc), then capturing via RealTerm in a .txt file.

This is the code:

//const int PULSE_PIN = 2; //aka CYCLE_REQUQEST
//const int CPU_READY = 38;
//const int DATA_HOLD = 39;

int input_data = REG_PIOC_PDSR;

void setup() 
{
  Serial.begin(460800);
  
  pinMode(22, INPUT);  // DB00
  pinMode(23, INPUT);  // DB01
  pinMode(24, INPUT);  // DB02
  pinMode(25, INPUT);  // DB03
  pinMode(26, INPUT);  // DB04
  pinMode(27, INPUT);  // DB05
  pinMode(28, INPUT);  // DB06
  pinMode(29, INPUT);  // DB07
  pinMode(30, INPUT);  // DB08
  pinMode(31, INPUT);  // DB09
  pinMode(32, INPUT);  // DB10
  pinMode(33, INPUT);  // DB11
  pinMode(34, INPUT);  // DB12
  pinMode(35, INPUT);  // DB13
  pinMode(36, INPUT);  // DB14
  pinMode(37, INPUT);  // DB15
  
  pinMode(3, INPUT);  // Included port C pins to make entire port INPUT
  pinMode(5, INPUT);  // 
  pinMode(6, INPUT);  // 
  pinMode(7, INPUT);  // 
  pinMode(8, INPUT);  // 
  pinMode(9, INPUT);  // 
  pinMode(38, INPUT);  // 
  pinMode(39, INPUT);  // 
  pinMode(40, INPUT);  // 
  pinMode(41, INPUT);  // 
  pinMode(44, INPUT);  // 
  pinMode(45, INPUT);  // 
  pinMode(46, INPUT);  // 
  pinMode(47, INPUT);  // 
  pinMode(48, INPUT);  //
  pinMode(49, INPUT);  // 
  pinMode(50, INPUT);  // 
  pinMode(51, INPUT);  // 
  pinMode(72, INPUT);  // 
  
 // pinMode(CPU_READY, OUTPUT);  // CPU_READY  digital 38
 // pinMode(DATA_HOLD, OUTPUT);  // Data_Hold  digital 39
 // pinMode(PULSE_PIN, INPUT);   // CYCLE_REQ  digital 2
  
}

void loop() 
{
    digitalWrite(DATA_HOLD, LOW);  // Data_Hold holds data
    
    Serial.println(digitalRead(input_data));
    
    digitalWrite(DATA_HOLD, HIGH);  // Data_Hold done and reset for next set
  
}

The text file results are:

1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1

Just rows of a single 1 repeatedly.

  1. Why is it showing 1s only? Is this some sort of hex format based on rows of 0/1s? How do I get it to display 0/1s of each pin per row?

  2. This is at 460800 baud. It also uses the arduino.org IDE instead of original ardiuno.cc IDE (Due wouldn't work on the .cc IDE). When I try 921600 baud, it only captures non-alphanumeric junk characters. Why? What can I do to get it to run 921600 baud?

20

Weekend bump to see if you folks, or anyone else, have any input on my last two questions! I greatly appreciate it, y'all!