(deleted)
Automower.ino (9.3 KB)
(deleted)
Don't you think you should start with an easier sketch? One that just does the serial communication with your mower?
The Serial object is the virtual serial interface on the USB bus. If you want to use the hardware serial interface on pin 0 and 1, use the Serial1 object.
(deleted)
In short words I can't send any "serial" code without the bridge sketch. As far as I understand I can't use USB and Pin0/Pin1 anyway.
I understand that in the final application you have to use the WiFi for the communication. But I would try to communicate with the mower over simple serial communication first and when this works advance to the WiFi connection.
Why can't you use USB? You cannot use the hardware serial interface and the Bridge class at the same time, that's correct.
To be prepared for the WiFi usage later, you can start using the AltSoftSerial library (AltSoftSerial Library, for an extra serial port) to get a software emulation of a serial interface and one that is not blocking the complete Arduino. The pins are fixed to 13 and 5. You'll loose your LED but you can use any other pin to light an LED.
(deleted)
Maybe I don't understand some restrictions from the bridge sketch and serial over Pin1/Pin0:
The hardware serial interface is used to communicate between the two processors the Yun has, on the AVR-side (the Arduino sketch) the Bridge class is responsible for this.
How did you connect the mower to the Arduino? Please don't post the same pictures again, I want to see how you did it.
serial (HV) connected to 1 and 0 on the Arduino
This probably won't work because the hardware serial interface (which is on pin 0 and 1) is used for inter-processor communication on the Yun. If you have pins 5 and 13 in the Yun unconnected, use the AltSoftSerial library (AltSoftSerial Library, for an extra serial port) to get a software emulated serial interface.
power connected to 5V and GND
Your schematics say 3V3 and not 5V for the mower.
How do the wires connect to the mower?
(deleted)
(deleted)
mySerial.read(statusAutomower, 5);
There is no read() method that takes two arguments. This won't work.
Why don't you use AltSoftSerial but SoftwareSerial? The later will make you much more trouble because it blocks interrupts during every transfer and consumes all processing power available. So you might have to slow down the controlling application on the PC to not overflow the incoming serial hardware doing the Bridge transfer. The SoftwareSerial will block interrupts for at least 1ms (1 byte) during which the Bridge interface might transfer up to 25 bytes, 24 of them might magically disappear because no interrupt handler is emptying the hardware register.
(deleted)
(deleted)
Automower.ino: In function 'void doCommand(YunClient)':
Automower:157: error: no matching function for call to 'AltSoftSerial::read(uint8_t [5])'
/Arduino/libraries/AltSoftSerial/AltSoftSerial.h:44: note: candidates are: virtual int AltSoftSerial::read()
Use your old readBytes method, as I already wrote, there is no read method that reads multiple bytes.
- Pin5 and Pin13 apply for the Yun as well? In that case I can't use the internal LED anymore?
Yes.
- commandAutomower is an array with 5 bytes (HEX). Will altSerial.write(commandAutomower, 5); send out these 5 bytes in order without any LF CR or something like this? Does write even work?
It will send these 5 bytes (bytes are not in hex although they may be printed in hex) over the emulated serial interface. Yes, write works.
- Will altSerial.read(statusAutomower); read only the next 5 bytes? What happens if there are only four or six?
It will do nothing except generating a compiler error. See above.
- If I wait 1000 ms before reading (to give the Automower time to respond), will it be buffered or is it better not to wait?
If wait means you're calling delay() it's always better not to do that if anything else should happen on your Arduino (as receiving characters from any interface). Although most of this stuff is handled in the background using interrupts, these handlers just copy the incoming stuff to buffers and these buffers may overrun. Try to always react on events and never wait for fixed times except you have no other option.
(deleted)
So with readBytes I can use two arguments?
Yes.
I think with available >= 5 it should limit it to 5 bytes already, right?
You don't need that because readBytes() already waits until either the number of bytes were received or a configurable timeout was reached.
But is there a timeout if the response isn't immediate?
If you use readBytes() there may be one. See Stream - Arduino Reference
Should I move the reading to the loop?
Please explain in more detail.
There won't be any data except after sending 5 bytes.
What does that mean?
(deleted)
(deleted)
(deleted)