Im trying to send data to a second board via Serial2, isnt tx2 and rx2 serial 2? Or do I need to change a pin mode for these pins? if so, how?
No need to configure the pins.
IDE 1.6.10., latest 32duine core.
You must X the signals when doing Serial2Serial, btw.
But for some reason i cant get the arduino to read data…
But maybe the data its sending out isnt quite right for the arduino to read… I dont know



Ho fun, time to do some shopping i guess…

Arduino TX 5V —-> resistor 1k ——> MapleMini RX 3V3
Arduino RX 5V <————————– MapleMini TX 3V3
Arduino GND <————————–> MapleMini GND
Ive ordered some logic level converters.
But yeah the arduino isnt reading the easy transfer packets… Where i can make my uno talk to my arduino pro mini…
isn’t a high state for either side about 2v2 or is that just for ttl?
stephen
as a first step try to xchange some bytes to verify your hw works, then you may mess with protocols..
Ive been using the Easy Transfer RX and TX blink examples to try and test it…
As i mentioned I could get it to work with the Uno and Pro mini… but not the Maple Mini and Pro Mini…
MM Tx ——> Uno Rx
Gnd ——— Gnd
So you can test, both speeds for example 9600.
At the beginning of MM prog wait for example 5secs, then send the packet to Uno (Uno at that time is receiving already)..
Do not use SoftSerial..
So the Pro Mini is receiving, so why isnt easy transfer working? :/
Run the EasyTransfer_TX on MM and RX on the Promini. It should work.
Wiring as above. Do not use SoftSerialET example.
Maybe this can impact the transfer between the 2 different boards..
Is there a way to force either board to one type?
Is there a way to force either board to one type?

MapleMini:
struct SEND_DATA_STRUCTURE{
//put your variable definitions here for the data you want to send
//THIS MUST BE EXACTLY THE SAME ON THE OTHER ARDUINO
int blinks; // or int32
int pause; // or int32
short dummy; // or int16
long hallo; // or int64
char joe; // or int8
};
Arduino Uno:
struct SEND_DATA_STRUCTURE{
//put your variable definitions here for the data you want to send
//THIS MUST BE EXACTLY THE SAME ON THE OTHER ARDUINO
int32 blinks;
int32 pause;
int16 dummy;
int64 hallo;
char joe; // or int8
};
Anyway thats working now…
Thanks
All im sending are 2 ints… MPH and RPM :/
isn’t a high state for either side about 2v2 or is that just for ttl?
stephen
It half works.
MPH dial is getting the correct numbers and runs as normal…
However the RPM one isnt working And I cant work out why.
I have a feeling its something to do with data types… Where the MPH dial only is getting numbers upto 80, the RPM is getting numbers up to 12000.
That should be within INTs range but ive set the variable to long just in case. But it still doesn’t work.
Im really having a hard time getting this to work. Its stopping me from taking the project to the next level. I need to get these basic controls working before I can add real speed and rev calculating. I also want to get more creative with the LEDs… But I MUST get the dials to work.
Heres my project source….
http://hastebin.com/rodizuqibo.cs The Maple Mini side, does all the data heavy stuff
http://hastebin.com/docerabiha.cs The Mini Arduino Pro, is just reading off serial sent from the maple and controlling the motors.
Please take a look and tell me what I’m doing wrong?
Then use software serial on the receiving end so that you can print what the receiver is actually receiving.
BTW. I suspect it would not be hard to get Easy Transfer to work, but you can’t just have the same struct on the TX and RX side as the internal representations of the data will be different on 8 bit AVR and 32bit STM32, and the compiler is different which would possible result in different internal representation.
e.g. If you trued to send data using Easy Transfer from STM32 to another STM32 and used Keil as the compiler on the TX side and GCC on the RX side, there is a good chance the data would be screwed up and a different number of bytes.
If you are trsnasferring between systems that are more than 8 bits, you also have to deal with the “endian” ness of the processor its self, but in this case as the AVR is only 8 bits, the endian’ness is implemented by the compiler on the AVR side and will be determined by the hardware on the STM32 side
I have not double checked this , but STM32’s seem to be little endian, and gcc AVR is also supposed to be little endian ( please double check this).
Of course as data types like float and double will also be an issue as they could be completely different on both sides. I know the AVR does not have double at all, as double is effectively type defed to float
Why rpm an mph are long? Is the long the same on MM and Uno?
You are receiving a byte and you cast it to long or int – why? With serial.read() you get only 1 byte – which byte from “long” or int?
You cannot get the rpm and mph declared as long or int by reading a single byte from serial..
You do not use Easy Transfer within your code above..
With ET you may try:
MMini:
struct SEND_DATA_STRUCTURE{
//put your variable definitions here for the data you want to send
//THIS MUST BE EXACTLY THE SAME ON THE OTHER ARDUINO
uint16 RPM; // 0-20000
uint16 MPH; // 0-5000 :)
};
ProMini:
struct RECEIVE_DATA_STRUCTURE{
//put your variable definitions here for the data you want to send
//THIS MUST BE EXACTLY THE SAME ON THE OTHER ARDUINO
uint16 RPM;
uint16 MPH;
};
I’m going to merge the Serial TX buffering code into the master at the weekend (when I have time to double check the master will be OK)
This will speed up the transfers as it will no longer be blocking (but shouldn’t cause you any problems, it should just make it faster)
Its interesting that you are using the Scheduler and that its working, as this is a relatively new feature to the Arduino API and I’m not sure many other people have used it on the STM32. Prior to the Scheduler in the API most people used FreeRTOS which is a much more powerful scheduling system, but in your case I suspect you could achieve the same scheduling using a switch statement
long XYZm = (long)(dialRange * (((float)XYZv) / XYZRange));
stephen
edogaldo, I’ll try that out and let you know, Im still fairly new to C++ If i was VBAing I would just encapsulate the variables in the type I wanted them to convert to.
Roger, Ill get the new master from github after the weekend, who knows might even speed up fastLED as the new serial would be none blocking.
I completely forgot about software serial being an option, as you probably know theres only 1 serial on this arduino pro mini, It never occurred to me that I could do serial prints with software serial to check the numbers… One of the biggest drawbacks in arduino type building is no real debugging features, I would love to place stops in my code and cycle through line by line to see whats going on and what variables are holding what numbers…
I will also have a go at getting that going a little later too, see whats going on. ill have to get the soldering iron out though to put some connectors on the spare pins. (or i can just build this onto my full sized arduino and just test there… no soldering required :p)
As for scheduler, yeah i realise after learning how to set it up its not too powerful, its really just a timer to say what loop function to call and when. I was hoping for better multi threading than that, IE if its even possible proper staggering of code running… Say a portion of this loop then a portion of that loop and another portion of this loop………. That would have negated the need for me to setup a second board to just run the motors as everything would have run more smoothly. While this loop scheduler improved things the motors still were noticeably choppy.
As for the whole 8 bit 32 bit stuff… I really am still very new to programming and thats approaching the engineering level that calls for BSE and PHDs in computer science… Which is funnily something I would have liked to have done if life circumstances were different.
And whats an endian?
Also, I’ve been using the AVR Mark2 compiler for all this stuff, is that right? Or should I be using a different compiler?
Pito, yeah I’ve been messing with types, its mostly down to trying to get things to work trying different things out, I could probably still do with cleaning up the code a little.
But I said before, I realise the RPM shouldn’t need to be long as I think int goes -32000 to 32000 or something… As for the int or long on the byte, Thats only there because it was in the tutorial…
I removed all the easy transfer stuff after getting the serial read side half working… I assume as Roger said the formatting of the data being sent between the boards is incompatible.
I just want to thank everyone for taking the time to look through my code. I realise how much a pain in the arse it is to read through other peoples code, esp when its some one at my skill level and badly documented.
Ill try the software serial to get the debug prints working and take another look at my type castings and keep you updated… Its annoying that its soooooo tantalisingly close to having this bit working and me not being able to work out why its not
Best, E.
Best, E.
Do you use a common ground for ALL devices? Most problems occurs if no common ground is present.
Pito: your are right, it depends much on the length of the cables and transfer speed. Without using buffers you can also try to lower the data transfer speed (still higher than UART)
Edit: Yes, now I can remember, I used some level shifter (buffers) for my project. They are totally cheap and a really *must have* for any kind of using: http://www.aliexpress.com/item/20pcs-lo … 11638.html (maybe you find in the meantime cheaper ones)
Edit2: more cheaper (0.19Euros/piece) : http://www.aliexpress.com/item/5PCS-Two … 43189.html

With automotive you may try CAN


With automotive you may try CAN

Last time I tried this, it didnt work because of a bug in the Arduino AVR core code that had not been fixed for years. I eventually found the fix on the Arduino.cc forum and had to edit the AVR core.
But I suppose they may have fixed that bug by now.
However as you are not sending much data, Serial would probably be fine and requires less components ( no level shifting).
You could also look at how often you send updates to the display. I doubt you need to update it that often, and if you want animation, you could interpolate results on the AVR side to give the appearance of a higher frame rate.
Re: Endianness
Processors are Big Endian or Small Endian.
Its a way to describe how the processor internally stores numbers
e.g. Whether the processor stores 0x1234 in memory
0x12
0x34
or
0x34
0x12
which is further complicated if the processor is 16 bit, as 0x12345678 could be stored as
0x5678
0x1234
so in memory as single bytes would be
0x56
0x78
0x12
0x34
( Google and you will find much better explanations)
I can’t really remember exactly what the problem was.
I know that I had to write an I2C Slave to SPI bridge using a Pro Mini, but when I first tried my code it didn’t work.
But when I investigated the problem the fix was to actually change something the I2C library of the AVR
This was probably 1 year or possibly more ago and perhaps it now works fine

the figures I’m sending out are int16, and are correct up to the point of serial write.
But on the arduino the returned figures are completely wrong. Numbers, but in no way the correct numbers… Im even getting minus values.
I have tried several type conversions and its all the same… Ive tried everything I can think of. I honestly dont know what to do

the figures I’m sending out are int16, and are correct up to the point of serial write.
But on the arduino the returned figures are completely wrong. Numbers, but in no way the correct numbers… Im even getting minus values.
I have tried several type conversions and its all the same… Ive tried everything I can think of. I honestly dont know what to do
As for changes. Tbh I couldnt really work out how much i changed :p
Anyway, ive regrabbed my code from the hastebin posts and the MPH is working again. So its not hardware failure… I now need to look through it very closely to see what broke it and what fixed it…
I still think the issue is down to data types
ill start going over it again now…
As for changes. Tbh I couldnt really work out how much i changed :p
Anyway, ive regrabbed my code from the hastebin posts and the MPH is working again. So its not hardware failure… I now need to look through it very closely to see what broke it and what fixed it…
I still think the issue is down to data types
ill start going over it again now…
Connect RX1 with TX1, watch usb serial console.
You may experiment with the cable’s lenghts and serial speeds

PS: using stm32duino core with TX buffer implemented..
// Example - Easy Transfer running on a single MapleMini/BluePill
// ET data channel - Connect RX1 with TX1
// For results watch usb serial console
// Pito 8/2016
#include <EasyTransfer.h>
//create two objects
EasyTransfer ETin, ETout;
struct RECEIVE_DATA_STRUCTURE{
//put your variable definitions here for the data you want to receive
//THIS MUST BE EXACTLY THE SAME ON THE OTHER ARDUINO
int rpm;
int mph;
};
struct SEND_DATA_STRUCTURE{
//put your variable definitions here for the data you want to receive
//THIS MUST BE EXACTLY THE SAME ON THE OTHER ARDUINO
int rpm;
int mph;
};
//give a name to the group of data
RECEIVE_DATA_STRUCTURE rxdata;
SEND_DATA_STRUCTURE txdata;
void setup(){
Serial.begin(115200); // usb console
Serial1.begin(1382400); // Easy Transfer data channel, connect RX1 and TX1 together
//start the library, pass in the data details and the name of the serial port. Can be Serial, Serial1, Serial2, etc.
ETin.begin(details(rxdata), &Serial1);
ETout.begin(details(txdata), &Serial1);
}
void loop() {
//first, lets read rpm and mph
txdata.rpm = 12666;
txdata.mph = 187;
// then we will go ahead and send that data out
ETout.sendData();
// and we receive the same data
rxdata.rpm = 0;
rxdata.mph = 0;
ETin.receiveData();
// we print out what we received
Serial.print(rxdata.rpm);
Serial.print(" ");
Serial.print(rxdata.mph);
if ((rxdata.rpm != txdata.rpm) || (rxdata.mph != txdata.mph)){
Serial.println(" ERROR");
} else {
Serial.println(" OK");
}
delay(100);
}
Did you try applying the formula changes at leasr for rpm? It should fix it.
Best, E.
MapleM is crystal driven (afaik), the promini is resonator driven. When the uart speeds are more than 3-5% off, the data could get corrupted.
Moreover promini’s 16MHz is not the best “baud” frequency, as for example the 115k2 is something like 111k in reality (-3.5%).
MapleM is crystal driven (afaik), the promini is resonator driven. When the uart speeds are more than 3-5% off, the data could get corrupted.
Moreover promini’s 16MHz is not the best “baud” frequency, as for example the 115k2 is something like 111k in reality.
1. start small and try to elaborate the maple<—>promini communication – for that you need 5lines long sketches
2. when your basic communication works, start with parsing integers or Easy Transfer or whatever you need
3. then start to add your higher layers like schedulers or complex calculation..

PS: the avr baudrates precision (provided you use crystals) tables are here http://wormfood.net/avrbaudcalc.php/
http://stackoverflow.com/questions/2479 … connection
serial write has a max value of 255 1 byte… so my values im sending arnt compatible with the function… Now its time to work out how to get round it…

3 days it took me to find that problem eeesh