I am trying to talk to an arduino MKR1000. Want to send and receive short ASCII strings.
Any help appreciated.
Thanks
Glenn Tom
Hi Glenn,
I imagine the process would have nothing to do with WiFi because the WiFi device would be connected to the serial/usb port - would it not?
Therefore, disregarding wifi, then you would approach it in the same way as a tethered device. That is, sending and receiving data via the usb port. Well, that would be my approach.
These links may be of help:
http://developer.xojo.com/userguide/serial-devices
http://developer.xojo.com/serial-port-tutorial
Cheers.
If you want WiFi, then need to write some socket program both to Arduino and Xojo.
May be you want to use MQTT to do the communications. https://forum.xojo.com/40624-mqtt/0
That’s interesting Jos.
I’m using an Arduino Uno that’s tethered to a laptop via a usb cable. I’ve thought about the options of using WiFi in order get longer distance without the cable.
I’ve never tried it, but I’ve “assumed” that if I used the WiFi Shield available, then the data would be transmitted (read/write) as if it was connected via the usb cable, and therefore no need to change anything in my software (on the Xojo side).
If the WiFi device converts to serial data, then how does the software know how it got the data? The software should not care how.
There must be something I’m missing.
[quote=381450:@Steve Kelepouris]That’s interesting José.
If the WiFi device converts to serial data, then how does the software know how it got the data? The software should not care how.
There must be something I’m missing.[/quote]
No, the WiFi shield is not like a Serial port, it talks to Arduino via Serial (Bus) but communications for it is IP.
Perhaps this project helps you to understand the Arduino side: https://create.arduino.cc/projecthub/lubosrusnak/how-to-control-arduino-from-mobile-phone-d1344b?ref=platform&ref_id=424_trending_part__&offset=0
Ok fine, I’m not talking about what happens on the Arduino side - yes, there is some coding to do there, but providing that is correct then surely the Xojo side simply reads/writes as it would serial?
No, from Xojo you must use some kind of IP communication, like Sockets, Websockets, REST calls… For implement REST in Arduino there are things like: GitHub - marcoschwartz/aREST: A RESTful environment for Arduino
Well, I disagree. It should not be that hard, it should be easy.
I like the moxie, but maybe you have the wrong tool. In the shield the com from Arduino cam be serial (or spi if I recall), but outbound is WiFi (I.e. Ethernet based). So xojo will receive it via the PC as any other Ethernet comms.
WIFI - means networked devices communicating across the network using standard network protocols
Serial Communications - Connect your Arduino to the PC/Mac via a USB cable
Bluetooth might also be a possibility
I was thinking on the receive end (the pc) an Arduino+WiFi converts the data to a serial stream and spits the data out of the usb port into the pc. That way my software reads it, as if it was tethered via a cable.
So my scenario requires an Arduino+WiFi shield at both ends.
Hope this helps the Op. in some way.
@Steve Kelepouris
You may want to take a look at the Pololu Wixel (https://www.pololu.com/docs/0J46/all).
[quote=381531:@Steve Kelepouris]
So my scenario requires an Arduino+WiFi shield at both ends
.[/quote]
That simply adds a layer of complexity that is unnecessary, since:
- The PC/Mac can already communicate with the Arduino over the network
- There is a need to write code to convert a typical TCP/IP connection to a simulated serial one
You will be dealing with a raw stream from the socket on the Arduino side and just a regular Socket on the PC/Mac at the other. Depending on the protocol. The output and input to those streams doesnt care if its going down a serial port or over the network. The code on your Arduino and on the Xojo app will be the same for handling the data regardless, indeed its not that hard to abstract it on both sides so that you could connect either via serial or wifi. Its only what youre writing the data to or where you check to see if data is available that will change.
If you use an arduino with built in Wifi capabilities like one based on the ESP8266 then no other hardware would be necessary. The firmware on the ESP chips is still a bit of a work in progress. Since Ive been working with them it has evolved and gotten a LOT better and more reliable. Ive finally gotten my connections to them very stable and the secret seems to be regularly checking to make sure that wifi is still connected. It can drop the connection but doesnt seem to send any error when this happens, anything you write just goes into nothing. It also doesnt seem to generate a proper error on the Xojo socket when it drops so some kind of ping going back and forth periodically will better let your Xojo app know when it needs to reconnect.
In my case Im connecting from the Xojo app to the arduino so the arduino is setup with a static IP address on my network and is acting as a server. It listens for my incoming connection and then I hold that socket open and send commands back and forth. I tried to keep the packetizing as simple as possible so all my commands and info are just text and are terminated by a carriage return. When the arduino receives one it knows its buffered the entire command and can pass that off to the handler that parses it out and figures out what to do, and sending data upstream to the Xojo app just requires a Socket.println( whatever your packet) in the arduino code. Its very simple but I can send name=value
pairs back and forth and get all the info I need by just splitting those. It is a bit more memory used in the Arduino to buffer the receptions.
What kind of data are you going to send back and forth? You can develop all your parsing and handling stuff via the serial port and then dive into the Wifi portion later once youve got that working. If possible I would recommend keeping the data packets that it needs to receive as small as possible because youll need to buffer them in the arduino as they come in. You can use the String class in the Arduino IDE and just concatenate as you go, but dynamic memory allocation in the Arduino makes me nervous for long term reliability. I know that none of my commands are more than 32 bytes so I can just allocate a 32 byte array in memory and keep it there. Using the String classes makes parsing easier but you might suffer some stack fragmentation that would cause it to hang up later on. They cant re-allocate their heap and many of the Arduino devices have very limited RAM. The ESP8266 chips are better in this regard as they have a lot more memory available so designing for them might remove some of those limitations or dangers.
There are good examples that come with the ESP8266 compile target for the Arduino IDE for both setting up the Wifi, making socket connections and receiving socket connections so you should definitely have a look at those and experiment with them. They can be adapted to do just about anything else that you would need to for communications. Most of the examples of IOT things out there are just having the arduino make simple http calls to a remote host for reporting in data. You can also handle that easily for just incoming data in a Xojo app. If you need 2 way communication then youll need to either keep a socket open and design a protocol of some kind, or run a simple HTTP server on the arduino and accept the same kind of simple HTTP requests from the xojo app. Frankly I would think that would be more complicated than just managing a carriage return delimited packet system of some kind, but it totally depends on what kind of data you need to send and if you need it to be 2 way.
Sorry, I somehow missed that you had already chosen the new MKR1000 board. Thats a pretty beefy machine, and an expensive one too, so it probably doesnt matter how to choose to parse the packets and all that. If youre not going to use just a one way HTTP hit to the Xojo app then I would definitely develop the protocol and other things over the serial port, and then add in the complication of the Wifi and networking stuff. You can build from their examples and just replace your calls to Serial.print with similar calls to whatever their object is that is the Socket. Reading data should be similarly easy to convert once you have a valid Socket object in the Arduino.
Well, I do hope that Glenn (the OP) gets back on board and lets us all know what the requirements are.
I just want to be able to send ascii text back and forth between a XOJO GUI and from a MKR100. I can send text from the Arduino and it can be seen by web browser (Chrome) but not clear how to get XOJO to read. A close parallel to the Serial Socket would be wonderful.
I am a NEWBIE to network communications.
Glenn
I eventually went to a HC-05 bluetooth adaptor. My existing applications work with the Serial Socket. If anyone can help with the WIFI solution, I am still interested is getting that working.
Steve is partially right, of course you can put a layer of code that hides the communications medium, and above that level send and receive strings without knowing about the medium.
The difference I found, switching between the use of serial comm via USB and sockets (as required by Wifi), is that serial comm works great 1 character at a time, whereas sockets don’t. The socket will perform poorly sending one character at a time, because of all the overhead involved.
So it seems as if your comm drivers need to be classified as character or packet (ie 1 or n characters per message), because that difference will work its way up your code hierarchy at least a level, and change the higher level code.
Another thing to know is the difference between TCP and UDP. “Everyone knows” that TCP has error detection and correction built into it, whereas UDP does not. But I learned when trying to run sockets on a realtime system was that TCP also has an automagical buffering system, so that the packet doesn’t necessarily go out the moment you pass data to the socket. Whereas UDP seems to send the packet immediately. I would only use UDP for realtime systems and do my own error checking.
Yes thanks BTL, for the confirmation of the “theory” although it may not help Glenn’s situation, there may be something worthwhile.
In my case, my software reads data from the serial port and I’m not going to change it. Therefore I don’t care if the data is supplied via WiFi, Bluetooth or handed down via the ancient Egyptian Sun God, Ra himself, it will always have to be converted to serial data.
Therefore that would require a hardware device to do the conversion, Yes, an extra step, but not expensive and much easier than trying to reconfigure my software to suit.