// Uno program, five random integers
void setup()
{
Serial.begin(38400);
int integersToSend[] = {12345, 65432, 333, 4, 5050};
for (int i = 0; i < 5; i++)
{
Serial.print(integersToSend[i]);
delay(1000);
}
}
void loop() {}
// Leonardo program
#include <EEPROM.h>
const int EEPROM_SIZE = 512; // Define the size of EEPROM available on the Leonardo
int addr = 0; // EEPROM address pointer
void setup() {
Serial.begin(9600);
Serial1.begin(38400);
Serial.println("EEPROM Data:");
for (int i = 0; i < EEPROM_SIZE; i += sizeof(unsigned long) + sizeof(int)) {
unsigned long timestamp;
int value;
EEPROM.get(i, timestamp);
EEPROM.get(i + sizeof(unsigned long), value);
Serial.print("Timestamp: ");
Serial.print(timestamp);
Serial.print(", Value: ");
Serial.println(value);
}
}
void loop() {
if (Serial1.available() >= sizeof(int)) {
int receivedValue = 0;
unsigned long currentTime = millis();
for (int i = 0; i < sizeof(int); i++) {
receivedValue |= Serial1.read() << (i * 8);
}
EEPROM.put(addr, currentTime);
addr += sizeof(unsigned long);
EEPROM.put(addr, receivedValue);
addr += sizeof(int);
if (addr >= EEPROM_SIZE) {
addr = 0; // Start writing from the beginning when EEPROM is full
}
}
}
Should this work or is there something I should change? I'm trying to view the written data in the serial monitor at 9600 baud after disconnecting and resetting.
The communication between the uno, sanding the integers to the Leonardo, should happen on 38400 baud.
Your send routine is sending a number as ASCII characters, but your receive routine thinks you should be receiving ints. One or the other needs to change.
Serial.write() will do it, though you need a pointer and length.
However, @zwieblum is correct, you need to synchronize somehow. Just sending raw ints continuously, you'll eventually get out of sync, and then all heck breaks loose. Better to leave it sending ASCII, and fix your receive routine.
I'd strongly recommend you look at the Serial Basics thread, here:
(Serial Input Basics - updated - #2 by Robin2)
I am told I need to be sending integers. I don't know why they want integers. This is for a bigger application. So it's just to set something up. I don't even know what the bigger application is for.
Then you have a question to ask them, don't you? If you send integers, how will they know which byte is which? If serial drops one character(quite possible in this old technology), how will you resync? Are they sending something to you, as well?
Questions, questions, always pesky questions.
Ask what command-response protocol is to be used. That'll leave them stumped, unless they've withheld something. Or, if you're to continuously blat ints without sync, ask if you should be leaving a 'dead space' between the ints, so they can infer a sync.
Lots of ways to skin the cat, some more robust than others; but when you've no knife, it's a tough job to start.
It is far more simple and reliable to send the integers as comma separated ascii text within a frame with start and end markers. A check sum can certainly be used as well.
Sending the multi byte binary values of integers introduces all sorts of complications. I would probably be recommended if there is a real premium on reducing the transfer length, but you have not said that is a requirement.
You really need to push back on what "sending integers" really is all about.
Well? Do we have a dialog here, or not? This is basic. If TX and RX are cross-connected with another board, it's no wonder you're having upload issues.