TX2 RX2… Am I missing something?

Nutsy
Tue Aug 09, 2016 1:26 pm
Is there a trick to getting these pins working?
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?

Pito
Tue Aug 09, 2016 2:14 pm
Serial2.print (on PA3=RX2 and PA2=TX2) works fine here (Maple Mini) (init with Serial2.begin(115200);).
No need to configure the pins.
IDE 1.6.10., latest 32duine core.
You must X the signals when doing Serial2Serial, btw.

Nutsy
Tue Aug 09, 2016 2:44 pm
Yeah, got that side working it seems… Im trying to use Easy Transfer library to get my maple to send some basic values to a mini arduino to run my stepper motors…

But for some reason i cant get the arduino to read data…


Nutsy
Tue Aug 09, 2016 3:58 pm
More fiddling about and it seems its something wrong with the maple. Its sending something out, i hooked my usb serial to it and did a serial consol.
But maybe the data its sending out isnt quite right for the arduino to read… I dont know :( Maybe Easy Transfer needs a proper port for maple mini and doesnt work out the box.

Pito
Tue Aug 09, 2016 4:04 pm
Maple is 3.3V and arduino is usually 5V signaling. Use at least 1kohm resistors in series with the signal wires (or better a level shifter)..

Nutsy
Tue Aug 09, 2016 5:01 pm
I didnt know that :( I also dont have any resistors :(

Ho fun, time to do some shopping i guess…


Pito
Tue Aug 09, 2016 5:46 pm
:) Actually you need 1 resistor (1kohm or higher), it is a workaround only, better to use a level shifter or 3.3V arduino

Arduino TX 5V —-> resistor 1k ——> MapleMini RX 3V3
Arduino RX 5V <————————– MapleMini TX 3V3
Arduino GND <————————–> MapleMini GND


Nutsy
Tue Aug 09, 2016 6:11 pm
well… the receiving end is the arduino. So the ard cant pick up the 3.3v signal?
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…

zmemw16
Tue Aug 09, 2016 6:14 pm
isn’t maple i/o 5v tolerant?
isn’t a high state for either side about 2v2 or is that just for ttl?

stephen


Pito
Tue Aug 09, 2016 6:20 pm
But yeah the arduino isnt reading the easy transfer packets…
as a first step try to xchange some bytes to verify your hw works, then you may mess with protocols..

Nutsy
Tue Aug 09, 2016 6:26 pm
I only have one Maple at the moment… The best I could do is try to read the serial coming out of the maple through a usb serial adapter. Its not plane text data…

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…


Pito
Tue Aug 09, 2016 6:40 pm
send a packet from Maple to Uno
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..

Nutsy
Tue Aug 09, 2016 8:13 pm
interesting… I wrote a quick sketch to make the led flash when it receives data… Any data. And it does flash when the maple sends something.

So the Pro Mini is receiving, so why isnt easy transfer working? :/


Pito
Tue Aug 09, 2016 8:30 pm
There is EasyTransfer_TX_Example and RX example.
Run the EasyTransfer_TX on MM and RX on the Promini. It should work.
Wiring as above. Do not use SoftSerialET example.

Nutsy
Wed Aug 10, 2016 10:06 am
thats the examples i tried… they didnt work.

edogaldo
Wed Aug 10, 2016 10:26 am
@Nutsy, just a tip: did you consider the data types differences between Arduino and Maple? I.e. in Arduino an int is 16 bits while in Maple it’s 32 bits.
Maybe this can impact the transfer between the 2 different boards..

Nutsy
Wed Aug 10, 2016 2:30 pm
No i didnt, I didnt know serial connections would be different…

Is there a way to force either board to one type?


edogaldo
Wed Aug 10, 2016 2:37 pm
Nutsy wrote:No i didnt, I didnt know serial connections would be different…

Is there a way to force either board to one type?


Pito
Wed Aug 10, 2016 3:05 pm
The Q is whether the Easy Transfer functions can process those differences in types (ET does the transfer in binary form).

Nutsy
Wed Aug 10, 2016 3:21 pm
i really do some times wonder if all this is beyond me and i should pack it in :(

Pito
Wed Aug 10, 2016 3:44 pm
The mapping is for example:

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
};


edogaldo
Wed Aug 10, 2016 3:46 pm
The library is for Arduino and in any case, in doubt, I’d try forcing the correct type size.

Nutsy
Wed Aug 10, 2016 4:25 pm
Well that fixed it… Wrong data types… You see again I didnt know that Int had 16 32 64 bits…. On the maple mini i was able to force it to int16… arduino cant seem to force to the higher bit… I guess its the limitation of the hardware…

Anyway thats working now…
Thanks :D


Nutsy
Wed Aug 10, 2016 5:25 pm
Spoke to soon… i could get the blink transfer program but im still having trouble sending data for my stepper motors to run on :/
All im sending are 2 ints… MPH and RPM :/

madias
Thu Aug 11, 2016 8:57 pm
zmemw16 wrote:isn’t maple i/o 5v tolerant?
isn’t a high state for either side about 2v2 or is that just for ttl?

stephen


Nutsy
Thu Aug 11, 2016 10:19 pm
Well i gave up on Easy Transfer and found a tutorial on how to send multiple values across serial to a second arduino…

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? :(


RogerClark
Thu Aug 11, 2016 11:27 pm
I would start by printing the values to Serial USB. and see what is being set.

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


Pito
Fri Aug 12, 2016 12:10 am
You mess with types a lot in your code.
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;
};


RogerClark
Fri Aug 12, 2016 12:44 am
BTW.

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


edogaldo
Fri Aug 12, 2016 7:42 am
I’d suggest you to change your formulas this way:
long XYZm = (long)(dialRange * (((float)XYZv) / XYZRange));

zmemw16
Fri Aug 12, 2016 10:34 am
remind me if sending ‘Hello’ char by char works, each way mm<->avr?
stephen

Nutsy
Fri Aug 12, 2016 11:48 am
Wow lots to reply to, ill try to get everything…

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? :D

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 :D


edogaldo
Fri Aug 12, 2016 12:27 pm
Another suggestion: why not making the Maple process the formulas and just send to the Arduino the results?!

Best, E.


Nutsy
Fri Aug 12, 2016 12:33 pm
edogaldo wrote:Another suggestion: why not making the Maple process the formulas and just send to the Arduino the results?!

Best, E.


madias
Fri Aug 12, 2016 5:45 pm
If you need to transfer data from AVR to STM32 there are better/faster/smarter solutions than UART (especially when you use soft serial on AVR either): I2c or better SPI. You should try out a SPI solution so you have the “native” serial on AVR without need for software slowdown and less processor circles (serial slow down completely the system on AVR and STM32). Only drawback: You need four lines instead of two. Some times ago I build a 4-voice synthesizer with 4 arduino nanos (as “voices”) and one Tiva TMC123 as master device. As transfer protocol I used I2c without problems (oddly enough it was more stable than SPI)

Pito
Fri Aug 12, 2016 5:57 pm
I2C and SPI are much faster and more sensitive to signal’s quality – you would need hw signal drivers/buffers when using longer cables.. (>20cm for example)

madias
Fri Aug 12, 2016 6:09 pm
Another silly question (didn’t read the whole thread at once):
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

Pito
Fri Aug 12, 2016 7:38 pm
A “level shifter” does not mean “a buffer or driver”. You need for example for SPI something like 74LCX244/245 drivers which are able to push nice rising and falling edges (a lot of current into the cable) over longer distances :)
With automotive you may try CAN :)

Nutsy
Fri Aug 12, 2016 8:34 pm
The final build is going to be on a couple of PCBs with the controllers soldered on should be no problems with distance… But hardware serial should be find for this…

madias
Fri Aug 12, 2016 8:55 pm
Pito wrote:A “level shifter” does not mean “a buffer or driver”. You need for example for SPI something like 74LCX244/245 drivers which are able to push nice rising and falling edges (a lot of current into the cable) over longer distances :)
With automotive you may try CAN :)

RogerClark
Fri Aug 12, 2016 10:00 pm
Re: transfer via I2C to AVR

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)


madias
Sat Aug 13, 2016 9:13 am
ok, sorry for getting OT here, Roger: Do you mean this one? http://dsscircuits.com/articles/86-arti … er-library

madias
Sat Aug 13, 2016 9:16 am
Another thing (to be on topic) with serial is, that you have always do a “Serial.available”, cause it’s not interrupt driven by library. It’s not a real issue but have have to take care of it. A simple solution would be (on STM32, because you have more timers you evermostly need) to set the “Serial.available” into a timer triggered interrupt and give back a flag.

RogerClark
Sat Aug 13, 2016 10:31 am
Sorry Matthias

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


Nutsy
Sat Aug 13, 2016 3:40 pm
Im not sure whats going on any more :( Both MPH and RPM arent working again… I have tried several things but I even reverted to some older code and it still doesnt work…….

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


madias
Sat Aug 13, 2016 4:53 pm
Nutsy, again: Are you really sure, that you have a common ground STM32 <—> Arduino?

edogaldo
Sat Aug 13, 2016 5:03 pm
Nutsy wrote:Im not sure whats going on any more :( Both MPH and RPM arent working again… I have tried several things but I even reverted to some older code and it still doesnt work…….

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


Nutsy
Sat Aug 13, 2016 5:12 pm
Hi , sorry yeah common ground.
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…


edogaldo
Sat Aug 13, 2016 5:16 pm
Nutsy wrote:Hi , sorry yeah common ground.
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…


Pito
Sat Aug 13, 2016 5:31 pm
Here is an Example – Send and Receive via Easy Transfer with a single Mini.
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);
}


Nutsy
Sat Aug 13, 2016 7:06 pm
edogaldo wrote:
Did you try applying the formula changes at leasr for rpm? It should fix it.

Best, E.


edogaldo
Sat Aug 13, 2016 7:29 pm
If not using easy transfer, try Serial.parseInt() to read the integer values.

Pito
Sat Aug 13, 2016 8:02 pm
Another source of issues could be the difference in uart baudrates.
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%).

Nutsy
Sat Aug 13, 2016 8:05 pm
parseInt doesnt seem to work at all…

Nutsy
Sat Aug 13, 2016 8:14 pm
Pito wrote:Another source of issues could be the difference in uart baudrates.
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.

Pito
Sat Aug 13, 2016 8:18 pm
I would recommend you to start operate in more structured way, and, to troubleshoot your system bottom-up.
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/

Nutsy
Sat Aug 13, 2016 9:53 pm
Think i found the issue…
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…

Nutsy
Sat Aug 13, 2016 10:29 pm
FIXED IT!!!!!!!! yeah that was it… simple that you cant send numbers higher than 255 or one byte in serial… Found some stuff on how to split the int into two bites, then them separately and reconstructed on the ard… And it works :D thank fluff for that.

3 days it took me to find that problem eeesh


rexnanet
Fri Sep 23, 2016 9:41 am
Were you still using Serial2 on PA2 and PA3 pins when it worked?

Leave a Reply

Your email address will not be published. Required fields are marked *