-
Notifications
You must be signed in to change notification settings - Fork 240
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for Arduino Yun (LUDP, etc.) #211
Comments
Ciao @drtrigon I have never personally tested Yun, but ESP8266 is compatible with PJON using both EthernetTCP and GlobalUDP already thanks to the work of @fredilarsen
|
I see ... thanks for the info! I adopted the issue. But then still a SoftwareBitBangSurrogate for ESP would be nice. May be I should explain, what I'm trying to do; Actually I would love to use the SoftwareBitBang strategy to gradually replace my 1-wire bus by one of the following schemes:
As I could not find a SoftwareBitBangSurrogate ready for Yun or ESP I went for the variant Linux PC ---> ThroughSerial ---> Arduino Uno but was not able to get it working. PJON-python does not work (don't know why, may be crc8 vs crc32 issue) and there is no example for Linux using ThroughSerial. So I invested (wasted?) 1 full day trying to get it to work Yesterday. Can you give me any hint? In the end the sensor data should go e.g. to a collectd instance. I need a way to get the data from the linux machine, some command line tool for simple send and receive of payload to a device would be useful as far as I can see. |
Ciao @drtrigon I have pushed few minutes ago the ESP8266 full compatibility for SoftwareBitBang mode 1. I have made a lot of testing and ESP8266 SoftwareBitBang seems solid using both 80 and 160MHz frequency transmitting or receving to and from ESP8266 or other Arduino compatible devices (Arduino Uno/Duemilanove/Nano/Mega/Leonardo/Attiny85). PJON-python is not maintained by me but by @Girgitt. For now PJON-python seems was not able to keep the pace of the c++ library and it is for now outdated. |
@drtrigon thank you for your support and for dedicating effort to this issue! If using ThroughSerial I suggest you to start with disabiling the synchronous acknowledgment because it has been proven unfeasible if used along with a hardware serial port. I am working on READMEs and examples to state more clearly this limitation of ThroughSerial. Here you can find the complete compatibility table: https://github.com/gioblu/PJON/wiki/Interfacing |
@drtrigon I think the fastest way to accomplish your goal may be to use the GlobalUDP strategy with ESP8266 and forward data to and from a PJON instance using SoftwareBitBang. It should be quite easy if taking inspiration from the surrogate example of @fredilarsen Remember to pull the new change a5563b5 before starting tests |
Wow! Thanks for all that reply! ;))
I also got that impression.
It is a very nice project!! Thanks for your effort!
I am looking at it currently, thanks for the hint. Is this up to date? I read in the comments something about PJON v8 and v9... Does it currently work with ThroughSerial on ubuntu?
How to do that? Just add a
Great news, thanks in advance! Yesterday I adopted the SoftwareBitBangSurrogate to ThroughSerial which was straight forward up to one thing, I was not sure whether to use
How to configure DHCP? How to enable? Finally I would have to change my schemes like:
So I will proceed along these 2 paths:
|
I had a look at PJON-gRPC hoping it would allow me to get to a result quickly... PJON-gRPC server part is a hell of a beast to compile - nothing that can be done within an hour using usual libs and deps on ubuntu (14.04)... Now I have to got the ESP path but that will take some time (set up the hardware etc) nothing that allows for a fast prove-of-concept. |
Hello, hope I am not intruding, but I have some relevant experience. As I see it the two most tempting alternatives are:
With solution 2, you can have a module with PJON ID 1 running as a process on a Linux PC, another module with ID 2 as a process on a Windows PC, and more on other PCs or Raspberrys, all talking together on the LAN via LUDP, all with DHCP and only a unique PJON ID needed (and unique MAC for the Arduinos where this is not hardcoded into the Ethernet card). Then add a switch connecting the LUDP bus to a SWBB bus, and add modules of different sorts (Arduinos, ESP8266, ...) to that bus. Add another switch to add still another SWBB bus somewhere else in the house. All they need is unique PJON IDs. At some point it may work with dynamic PJON address assignment as well, but then you would need to introduce a name or something else to identify each module. All modules will find each other by PJON ID independent of where they are located and on which media. Feel free to have a look at my repo ModuleInterface which is building on PJON and making it easier to control devices. It has an example with a Linux master, a BlinkingRGBSwitch (from the PJON example), and SWBB worker modules. All controlled from the web site that is included in the setup. You may find some useful PJON related code even if you do not need ModuleInterface. |
Thanks @fredilarsen for the reply very informative - I had already a look at ModuleInterface and it looks promising (e.g. the webserver/interface). But honestly I did not get how to set it up and what parts do what. Basically I want to have a device (call it router) that connects to any number of PCs (honestly I do not care about strategy here) one one side and on the other a SoftwareBitBang to replace my 1-wire network. All can/should be local only - if I want to share then not the devices but the webserver/interface (which can sit on any local machine) only. So I am fine with any solution ThroughSerial, Ethernet, LUDP, ... My current issue is that I am not able to establish a connection between PC and any device using any stragtegy, I already tried:
As I have a linux machine (ubuntu 14.04) I really have trouble to compile PJON-gRPC and also ThroughSerial examples as they are for win only. Using the Yun is ok for me but out of my experience it always needs some special tricks thus I wanted to start simple and small (ThroughSerial). I imagine something like Arduino Uno connected via ThroughSerial to a linux machine. But I am fine with any starting point that works (minimal example, prove of concept) - this is my desperate need - can you help here? At the current point I do not care on strategy (except at the end of the chain should finally be SoftwareBitBang) as I just want to get started with PJON, play a bit around and test. It's now 1.5 full working days I tried without success (currently I do not have access to my VirtualBoxes that makes it abit more involved also). |
@fredilarsen I assume you are referring to ModuleInterface/examples/WebPage/WINDOWS_LINUX_ETCP and ModuleInterface/examples/WebPage/WINDOWS_LINUX_LUDP ? Can you give me a simple step-by-step howto on how to compile that for linux and arduino yun? How to debug in case it's not working? |
Ok finally I got PJON/examples/LINUX/Local/LocalUDP/PingPong working between my physical machine and a VM (both kubuntu 14.04, both compiled without any issue. Ok next testing with an Arduino Yun. |
...hmm as I can see from forum.arduino.cc/index.php?topic=187287.0 UDP is not supported by Arduino Yun in a way as by the ethernet shield. At least there is not drop-in replacement library. Yun wifi would be very nice for isolated setups (through a wall or window e.g.). So I am stuck here … need to buy an ethernet shield and while I am search all Arduino Ethernet product are retired…?! |
Regarding Ethernet shield, I have standardized on using these red ones, and I have tested them on Nano, Uno and Mega, and they have been running continuously for at least a couple of years. |
@drtrigon I trust in wires, so I prefer to use wired Ethernet wherever possible. But I agree that a WiFi to SWBB switch would be a nice thing for special places. (But running the OS strategy on 433MHZ could be a good solution as well.) As it seems the ESP8266 can talk SWBB to Arduinos without a voltage level converter, it would be nice to use as a switch. Unfortunately, because of a bug in the ESP WiFi library, UDP broadcasts work extremely slow while directed UDP is fast. This means that LUDP which is compact and needs very little configuration cannot be used on ESP. And GUDP needs all devices with ID and IP address to be registered in a table, so it is not so nice for a dynamic switch. Then the efficient one-to-one ETCP connection used in the Surrogate example remains, and we are currently testing to see if it can be used on the ESP. |
I was thinking of the WINDOWS_LINUX_LUDP example, yes. I hope the README below the WebPage example is relatively self-explaining, but I am thankful for feedback on anything that may be unclear or missing. To build the Linux example, just go down to the bottommost directory and type 'make'. You will get an executable with the same name as the cpp file but no extension. You need the gnu C++ compiler installed. I see that there are multiple levels to get working at once (SWBB modules, SWBB-LUDP switch, Linux master, database, web server), so I think I will add a couple of dummy masters (one directly on SWBB, one with LUDP on Linux) to the WebPage example, not communicating with a web server or database at all, but feeding configuration to the modules. Just to make it easier to build from the bottom up and test the different levels while building. Regarding building the ModuleInterface examples, perhaps it is better to take that as an issue on the ModuleInterface page in case it can be useful to others. Will you create an issue there when needed? |
@gioblu: Tryed TS on Linux as mentioned on https://github.com/gioblu/PJON/wiki/Interfacing but was not able to get it working as it does not seem to be supported in fact. Tried to modify PJON_LINUX_Interface.h and ThroughSerial.h in order to get it to compile but was not able to work out all the needed #defines as I am not an expert on fopen and stuff. @fredilarsen: Thanks for the hardware hint, will check that! Also I opened fredilarsen/ModuleInterface#5 (need re-phrasing maybe). |
Ciao @drtrigon my stupidity, I am sorry I have corrected the matrix, thank you for the report. It should be fairly simple to add the missing system calls. It may be even easier if the serial functions of wiringPi work out of the box on a standard linux distribution (in that case it would be enough to define the constant RPI before PJON.h inclusion) although a dedicated set of system calls may be a more efficient solution. I still didnt have the time to dedicate a streak to this. |
@gioblu: Your assumption was right, turns out wiringPi is fairly easy to compile on ubuntu 14.04:
worked for me out of the box. Next I adopted examples/RPI/Local/ThroughSerial/BlinkTestTransmitter/Transmitter.cpp a bit according to this fork drtrigon@1ab80b9 (omitt wiringSerial and wiringPiSetup). I also started playing with BlinkWithResponse (response not working yet). You can compile and run them by (I had to use sudo due to the serial port):
Now I can finally start putting a TS to SWBB Surrogate together and start playing with that! As soon as I either have the hardware or Arduino Yun gets added by you I wll start playing with the LUDP and router solutions (replacing the surrogate then). |
Ciao @drtrigon happy to hear that, in this case I could add this as an initial example for LINUX serial. About response try defining |
Ok, I do not want to promise too much, but I think I got it: drtrigon@9b9dc10
Arduino Uno and Yun can basically be any kind of AVR/Arduino (as supported by PJON), no special needs except for a serial-usb port on one of them. This setup works in the respect that the LED (pin 13) on Device C blinks and in the console app on Device A shows "BLINK" as an answer. I also added some LED feedback in Device B (see code) that works too. Very, very nice! A first developing and testing setup that works - may be not as cool as the LUDP variant - but very nice anyway! ;) One issue is left - may be you guys can help me again; after about 1 min the system hangs and stops blinking, it looks like it's Device A but not 100% sure. Device A is a VM by the way - may be that's the cause (no time to check yet). @gioblu: I put all my stuff in my fork. I added you as Collaborator such that you have full access. Do you need me to issue a pull request or what would be the right thing to do? |
@gioblu: You can add linux back to matrix with the restriction of needing wiringPi. ;) |
Ciao @drtrigon thank you very much for your support. My compliments you have demonstrated to have quite a fast learning curve if compared to the average users, specially considering you were operating not on solid grounds. I have taken a look to your fork. About the hang I think the problem is in the acknowledgment if a hardware serial is used on Arduino compatible devices when a collission occurs, I am still not sure about it I am actually working on this issue. Try disabling the acknowledgment or use a software serial port on arduino side. |
What's the technical difference between Surrogate and Switch? Could I use |
I can confirm that putting |
@drtrigon thank you for the report, so no freeze if there is no active sync ack, right? |
Don't know what you exactly mean, it was the code using |
heheeh, sorry for my bad english and for being cryptic :) |
Thank you, also for 687e1b4#diff-699dc14a20e7c87c251aee74801b9f4c ! |
@drtrigon Regarding the Surrogate vs Switch, the Switch is kind of a general routing device, while the Surrogate was something I came up with to exploit a special mode of the ETCP strategy. Giovanni is innocent :-) ETCP can work in 3 modes. The standard mode makes it create a socket to the receiver, send packet and get a sync ACK on that socket before it is closed. Then it will check if an incoming connection has arrived on its own listening port. Because of a very small limit to the number of open sockets on Arduino, it must close the connection as soon as possible, and this reduces the efficiency. But it can talk to a list of pre-registered (IP, id) devices. It is more complex than the very simple LUDP strategy, but can talk to devices spread on different networks. The two other modes are more limited in one fashion, in that they are established from one device to another and kept open for efficiency. Focusing on the most efficient of them, the "single-direction" mode, device A connects to device B on a specific listening port to establish a socket for packets in direction A->B, then connects one more socket to the same port for packets in direction B->A. In theory data can flow full-duplex, but this is limited by the single-threaded devices and programs. Still the buffering makes it more efficient than using one single socket, and there is no idle traffic except keep-alive. The LUDP based switch was created later, giving similar features plus the possibility to have multiple switches connecting different buses/media together through a LAN. But it is limited to the local network and is not firewall friendly. The difference in efficiency between the two approaches has not been benchmarked yet. I would recommend the LUDP based switch if this is just on a LAN, as the strategy is smaller and simpler and requires no fixed IP addresses. In the BlinkingRGBSwitch example using |
@fredilarsen: Thanks for this very detailed explanation! As I am not an expert I might have missed some points - sorry if that is the case - but I can come back and re-read again!. ;)) So from what I got - the choice of a TS to SWBB surrogate make sense in that I want to connect a PC (linux) to the SWBB bus only and not a (full) TS bus to the SWBB bus. And it won't make to much sense to write a TS to SWBB switch for that case. Good. Now I accidentally also got some more answers to fredilarsen/ModuleInterface#5 as I finally found https://github.com/fredilarsen/ModuleInterface/blob/master/src/MI_PJON/PJONModuleInterface.h @gioblu: I also sent the code through some CI processes, and got a few (may be) notable results:
(travis run relevant parts can be found from https://travis-ci.org/drtrigon/sketchbook/jobs/393290826#L4812 till https://travis-ci.org/drtrigon/sketchbook/jobs/393290826#L5073) For me I'll follow now this TODO (no order):
|
Ciao @drtrigon thank you for your useful reports. I have referenced few commits to fix some of the warnings present in your attachments. About the style: void example()
{
// something
} I prefer this because for me it is more readable and at the same time more compact, also more than half of the world, in many languages uses this form: void example() {
// something
} How this can be the standard? call(param,
param,
param); I cannot comply with that, isn't this more readable: call(
param,
param,
param
); The same indentation applied to the content of a condition or function is applied to parameters, in my opinion enhancing readability. About the preprocessor: #ifndef RPI
#define RPI true
#endif This I think helps to avoid mistakes quickly identifying where the preprocessor condition ends: #ifndef RPI
#define RPI true
#endif For security reasons I have never connected Travis to this repository (I am paranoid). Yes ESP8266 communicates nominally with both 5v and 3v3 devices, just be sure the board you are using has 5v tolerant pins. |
@gioblu: I saw your commits applying the changes suggested by the linters, very nice - thanks! About the style ... this is a topic that leaves a lot of room for discussion. I used a pragmatic approach; I ran astyle using various settings and used then the one that caused the smallest number of changes. For me this is most of the time "kr" (Kernighan & Ritchie style), but not always sometimes I am closer to "allman" (Allman style) and personally I think I would prefer "google" (Google style) but there a had some other more technical issues (have a look at http://astyle.sourceforge.net/astyle.html#_Basic_Brace_Styles to get a full listing). Summarizing I would say I do not care so much about WHAT style is used but I really like to enforce THAT a consistent style is used. Going a bit more into detail I used
so for functions (classes, ...) the bracket is put on the next line but not for cases and anything else. I like this because the functions are easier to see/find in a text editor. When talking about wrapped elements or parameters - I have to say I come from the python world, were we have PEP8 https://www.python.org/dev/peps/pep-0008/#indentation which gives you actually quite a lot of freedom, but I would clearly prefer what you mentioned first (as my eyes are more used to it). Being honest here I have to add that this actually has drawbacks, imagine a lengthy function or class name for I see you do want to protect your github account. You don't have to fork. Actually I host all my repos on my local machines and do mirror them to github for travis only, have a look at https://github.com/drtrigon/sketchbook#setup or in more detail at https://steveperkins.com/migrating-projects-from-github-to-gitlab/. All it needs is a I do think PJON needs a "travis connection" to ensure code quality (with less effort - freeing time for other stuff ;) and especially do unit testing for various architectures (build matrix). I do even use it for hardware stuff (generate schematics, pcbs, etc.). I do own ESP8266 currently (ESP-01 https://en.wikipedia.org/wiki/ESP8266) and from what I find in https://hackaday.com/2016/07/28/ask-hackaday-is-the-esp8266-5v-tolerant/ I would call this 5V tolerance an "undocumented feature". What I want to say is that these are interesting news for me and will be useful in the future but for other projects. For a PJON master I would like to have a proper design and not rely on a function that might be accidental and also might not exist in the future any longer. Another argument against the ESP8266 is missing LUDP support which I really started liking as soon as I understood that it needs very little configuration only (no ip... what a dream ;) ! |
@gioblu: Regarding the preprocessor, if you can use astyle v3 (I currently use v2 only), you can use |
@gioblu and @fredilarsen: Thanks a lot for your hints so far ... had time to play a bit more and have now my own kind of "GenericDevice" that supports a very simple command set that allows me to read and write data (see https://github.com/drtrigon/sketchbook/tree/master/OWPJON). Serialization is done in the most simple (and code efficient?) way by simple type casts and python un-/pack. Everything works from linux command line using pipes through TS or LUDP to a Surrogate or Tunneler (modified BlinkingRGBSwitch to become BlinkingSwitch - LUDP works like a charm!) and from there via SWBB to Arduino or ATtiny devices. Unittest is available also. The ATtiny example takes currently 5554 bytes (67%) setup according to https://github.com/gioblu/PJON/wiki/ATtiny-interfacing but I also added I also wanted to ask what's the technical difference between Surrogate and Switch? Could I use Regarding my TODO #211 (comment):
|
Btw.: Dragino mentioned at https://github.com/gioblu/PJON/tree/master/src/strategies/ThroughLoRa also uses Arduino Yun, so supporting Yun would allow for a very nice LUDP-LoRa (tunneler or surrogate) with optional LUDP-SWBB feature. As I already own one that would be brilliant. (not even mentioning the wifi magic ;) |
@drtrigon Regarding the difference between Surrogate and Switch, the Surrogate is really only intended for one-to-one strategies like the ETCP variant (that only requires Ethernet firewall port opening/forwarding in one direction) used in the Surrogate example. It "inserts" the external process or device into the bus through the one-to-one link. Could be used for serial as well I guess. Normally a Switch (or Router if using bus ids) should be used, routing packets between buses/strategies. So one LUDP bus can for example connect multiple SWBB buses through LUDP-SWBB switches like the BlinkingRGBSwitch, and also contain LUDP devices. All SWBB and LUDP devices talking together transparently. Regarding LUDP-LoRa, both are multi-device strategies, so a Switch or Router should be used, allowing multiple devices on each of the two to freely talk together. Or be part of a larger network. |
Regarding the basic need for a UDP handling for Arduino Yun / Bridge I made some progress. As mentioned in https://arduino.stackexchange.com/questions/14170/streaming-sensor-data-over-udp-using-an-arduino-y%C3%BAn-how-to-do-it-and-how-fast we can communicate to the linux part and execute shell commands directly by writing to serial port. See https://github.com/bigjosh/SimpleTempLoggerYun/blob/master/Arduino/SimpleTempLoggerYun/SimpleTempLoggerYun.ino for a working example. This allows us to use
and send with:
(may be multicast should be used instead of broadcast, see http://www.dest-unreach.org/socat/doc/socat-multicast.html)
This would allow blocking access to UDP features. All needed code would be on the AVR side (sketch and header). No need to install user specific code on linux part of Yun just If something like a non-blocking approach is needed - e.g. using a server continuously listening for UDP packets - may be a dedicated python script needs to be installed (user specific code), see http://forum.arduino.cc/index.php?topic=187287.15. This would need us to write and maintain code for both sides; AVR and linux part of Yun. Using one of these 2 approaches we have to implement a header analogue to https://github.com/arduino-libraries/Ethernet/blob/master/src/EthernetUdp.cpp in order to use it in https://github.com/gioblu/PJON/blob/master/src/interfaces/ARDUINO/UDPHelper_ARDUINO.h then. |
Would allow to use Dragino LG01-S (Uno/Yun combo) for direct LUDP - LoRa tunneler (also solving level shifting issues). Me be even use as 3 way tunneler LUDP - LoRa - SWBB would be possible. See also #222. |
How to use the SoftwareBitBangSurrogate with Arduino Yun? I tried to run the Arduino example https://github.com/gioblu/PJON/blob/master/examples/ARDUINO/Local/EthernetTCP/SoftwareBitBangSurrogate/Surrogate/Surrogate.ino. It compiled successfully for Yun but I was wondering a few things: The Arduino Yun ...
Can you elaborate how to adopt the code for that? I would be willing to fork and implement it myself if you wish. Greetings!
The text was updated successfully, but these errors were encountered: