search

gioblu / PJON

PJON (Padded Jittering Operative Network) is an experimental, arduino-compatible, multi-master, multi-media network protocol.
Other
2.73k stars 239 forks source link

Add support for Arduino Yun (LUDP, etc.) #211

Open drtrigon opened 6 years ago

drtrigon commented 6 years ago

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!

gioblu commented 6 years ago

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 When on ESP the dedicated wifi library is used instead: https://github.com/gioblu/PJON/blob/e982597a2baf790b419a7cb5fbc4256b58ff643f/src/interfaces/ARDUINO/UDPHelper_ARDUINO.h#L4

drtrigon commented 6 years ago

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:

Linux PC / Raspi(Zero) with PJON-python ---> ThroughSerial ---> Arduino Uno / Yun with PJON ---> SoftwareBitBang ---> "1-wire pjon" bus

Linux PC / Raspi(Zero) ---> EthernetTCP ---> Arduino Yun / ESP8266 / (may be Raspi) with PJON ---> SoftwareBitBang ---> "1-wire pjon" bus

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.

gioblu commented 6 years ago

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.

gioblu commented 6 years ago

@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

gioblu commented 6 years ago

@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 https://github.com/gioblu/PJON/commit/a5563b58748885d638058f15b9640044d6c6d894 before starting tests

drtrigon commented 6 years ago

Wow! Thanks for all that reply! ;))

For now PJON-python seems was not able to keep the pace of the c++ library and it is for now outdated.

I also got that impression.

@drtrigon thank you for your support and for dedicating effort to this issue!

It is a very nice project!! Thanks for your effort!

Please take a look to the work of @Galitskiy https://github.com/Galitskiy/PJON-gRPC it may be useful for you and maybe he could give you some advices for the setup that you have described.

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?

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.

How to do that? Just add a bus.set_synchronous_acknowledge(false); ?

I am working on READMEs and examples to state more clearly this limitation of ThroughSerial.

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 send_from_id or send_packet_blocking then - I used send_packet_blocking in the end but never reached the point where I could test it. I will look at this and GlobalUDP. In the docs I found:

The IP address of the device can be DHCP assigned if none of the other devices need to reach it except with ACKs or replies. Otherwise it should be static.

How to configure DHCP? How to enable?

Finally I would have to change my schemes like:

Linux PC / Raspi(Zero) with PJON-gRPC ---> ThroughSerial ---> Arduino Uno / Yun with PJON (router_extender or SoftwareBitBangSurrogate) ---> SoftwareBitBang ---> "1-wire pjon" bus

Linux PC / Raspi(Zero) ---> GlobalUDP ---> ESP8266 / (may be Raspi) with PJON (SoftwareBitBangSurrogate) ---> SoftwareBitBang ---> "1-wire pjon" bus needing 3.3-5V level shifting

So I will proceed along these 2 paths:

drtrigon commented 6 years ago

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.

fredilarsen commented 6 years ago

Hello, hope I am not intruding, but I have some relevant experience. As I see it the two most tempting alternatives are:

  1. Using a SoftwareBitBang surrogate with the EthernetTCP strategy, and the master/RemoteWorker running on Linux. When testing this, I used an Arduino Uno or Nano with an Ethernet shield. Sorry for not having tested Yun, but I would guess that if it compiles it works. The Surrogate does not require a fixed IP so it can be changed to use DHCP, but the RemoteWorker (the Linux PC) must have a fixed IP address. It is usually best to assign it a fixed IP address in the DHCP server and leave the PC itself at DHCP.
  2. (My current setup) using the LUDP based BlinkingRGBSwitch (one of the PJON examples, blinking in different color for each direction when a packet passes through, quite informative) on an Arduino Nano (or other Arduino) with an Ethernet shield, and a master running on Linux with the LUDP strategy. The switch connects the Ethernet LUDP and SWBB based devices without them knowing that the other devices are on other media :-) No configuration of IP addresses anywhere, just DHCP. Downside is that it will only work within a local network, but that covers my needs, and connections across the Internet or WAN could be handled with another router, GUDP or ETCP.

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.

drtrigon commented 6 years ago

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).

drtrigon commented 6 years ago

@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?

drtrigon commented 6 years ago

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.

drtrigon commented 6 years ago

...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…?!

fredilarsen commented 6 years ago

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.

https://www.ebay.com/itm/Mini-W5100-LAN-Ethernet-Shield-Network-Module-board-for-Arduino-high-quality/132487411585?epid=1131609005&hash=item1ed8dd7781:g:kI4AAOSw441bBMW3

fredilarsen commented 6 years ago

@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.

fredilarsen commented 6 years ago

I was thinking of the WINDOWS_LINUX_LUDP example, yes. Then on Arduino the WebPage/ARDUINO_SWBB/SensorMonitor and WebPage/ARDUINO_SWBB/LightController. And the switch from the PJON example ARDUINO/Local/SoftwareBitBang/Tunneler/BlinkingRGBSwitch, connecting the LUDP and SWBB buses.

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? The same regarding debugging, just add an issue and I will reply. It will also help me improve the READMEs.

drtrigon commented 6 years ago

@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 https://github.com/fredilarsen/ModuleInterface/issues/5 (need re-phrasing maybe).

gioblu commented 6 years ago

Ciao @drtrigon my stupidity, I am sorry I have corrected the matrix, thank you for the report. The problem with Linux serial are the missing serial system calls that in RPI are implemented with the use of WiringPi methods in the rpi interface.

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.

drtrigon commented 6 years ago

@gioblu: Your assumption was right, turns out wiringPi is fairly easy to compile on ubuntu 14.04:

$ git clone git://git.drogon.net/wiringPi
$ cd wiringPi
$ ./build

worked for me out of the box. Next I adopted examples/RPI/Local/ThroughSerial/BlinkTestTransmitter/Transmitter.cpp a bit according to this fork https://github.com/drtrigon/PJON/commit/1ab80b9aab801e9bbe68f9c64c2113246db0abe8 (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):

$ make
$ sudo ./Transmitter

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).

gioblu commented 6 years ago

Ciao @drtrigon happy to hear that, in this case I could add this as an initial example for LINUX serial. What do you think?

About response try defining TS_RESPONSE_TIME_OUT: https://github.com/drtrigon/PJON/commit/1ab80b9aab801e9bbe68f9c64c2113246db0abe8#diff-1f9681632428845c0f0b2f0ff9762543R16 also in the Arduino program.

drtrigon commented 6 years ago

Ok, I do not want to promise too much, but I think I got it: https://github.com/drtrigon/PJON/commit/9b9dc10b306a4ae3ec34ef3a766a8ea7b64ca1da

kubuntu 14.04           Arduino Uno             Arduino Yun
ThroughSerial   <--->   ThroughSerial
                        SWBB pin 7      <--->   SWBB pin 12
Device A                Device B                Device C

Device A: LINUX/Local/ThroughSerial/RemoteWorker/Transmitter/  (kubuntu 14.04, TS)
Device B: ARDUINO/Local/ThroughSerial/SoftwareBitBangSurrogate/  (Uno, TS, SWBB pin 7)
Device C: ARDUINO/Local/SoftwareBitBang/BlinkWithResponse/Receiver/  (Yun, SWBB pin12)

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?

drtrigon commented 6 years ago

@gioblu: You can add linux back to matrix with the restriction of needing wiringPi. ;)

gioblu commented 6 years ago

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. It would be nice to publicly record your contribution with a pull-request if you are ok with it. I see in the code some comments, feel free to pull-request non-linted code as long as it works, I will fix afterwards.

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.

drtrigon commented 6 years ago

https://github.com/gioblu/PJON/pull/213

drtrigon commented 6 years ago

What's the technical difference between Surrogate and Switch? Could I use PJONInteractiveRouter<PJONVirtualBusRouter<PJONSwitch>> also for TS to SWBB?

drtrigon commented 6 years ago

I can confirm that putting bus.set_synchronous_acknowledge(false); before bus.begin(); in both, the Receiver (https://github.com/gioblu/PJON/tree/master/examples/ARDUINO/Local/ThroughSerial/BlinkWithResponse/Receiver) and the Transmitter (https://github.com/gioblu/PJON/tree/master/examples/LINUX/Local/ThroughSerial/BlinkWithResponse/Transmitter) helps in the respect that the blink example now runs stable for at least 1 hr (in VM). I did not test using SoftwareSerial on pins 0 and 1 yet.

gioblu commented 6 years ago

@drtrigon thank you for the report, so no freeze if there is no active sync ack, right? Thank you again!

drtrigon commented 6 years ago

no freeze if there is no active sync ack, right?

Don't know what you exactly mean, it was the code using bus.send_repeatedly - NOT the one using bus.send_packet(44, "B", 1) == PJON_ACK - see https://github.com/gioblu/PJON/blob/master/examples/LINUX/Local/ThroughSerial/BlinkWithResponse/Transmitter/Transmitter.cpp#L47. Then YES there was no freeze for more than 1 hour of running the code.

gioblu commented 6 years ago

heheeh, sorry for my bad english and for being cryptic :) thank you again for your fast feedback!

drtrigon commented 6 years ago

Thank you, also for https://github.com/gioblu/PJON/commit/687e1b4f0da3727f428a440b3972e88e1ebbab2a#diff-699dc14a20e7c87c251aee74801b9f4c !

fredilarsen commented 6 years ago

@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 single-direction mode is not really suited for a bus, but for keeping an efficient connection between two devices, perhaps through the Internet and firewalls that only need one port forwarding on the B side. The Surrogate and Remoteworker concept was made to utilize this mode, by letting one device (a master or similar, potentially a PC process) be part of a SWBB (or other strategy) bus by a "Surrogate" device. The RemoteWorker will communicate "directly" with devices on the SWBB bus, and replies from these devices will be received "directly" by the RemoteWorker. The Surrogate is just a transparent stand-in forwarding packets.

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 PJONInteractiveRouter<PJONVirtualBusRouter<PJONSwitch>>, the PJONInteractiveRouter part is just for hooking up the callback functions for blinking the LED in Green or Blue for each direction, or RED for delivery error. So if not using a status RGB LED, use just the PJONVirtualBusRouter<PJONSwitch> instead.

drtrigon commented 6 years ago

@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 https://github.com/fredilarsen/ModuleInterface/issues/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):

gioblu commented 6 years ago

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). I will make a fork on another account and use it there.

Yes ESP8266 communicates nominally with both 5v and 3v3 devices, just be sure the board you are using has 5v tolerant pins.

drtrigon commented 6 years ago

@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 --style=kr --indent=spaces=2 for LINUX/Local/ThroughSerial/RemoteWorker/Transmitter, when looking at "kr" more closely you will see following (for default of indent=spaces=4):

int Foo(bool isBar)
{
    if (isBar) {
        bar();
        return 1;
    } else
        return 0;
}

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 call - due to the big intention, ALL param have to be short - so I think your argument is clearly better! Comming to the preprocessor directives I fully agree with you - I do like having intention there - I have to look into astyle options once more...

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 git remote set-url --add origin ...

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 ;) !

drtrigon commented 6 years ago

@gioblu: Regarding the preprocessor, if you can use astyle v3 (I currently use v2 only), you can use --indent-preproc-block to adopt this behaviour.

drtrigon commented 6 years ago

@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 #define PJON_INCLUDE_SWBB true hoping (not verified) that this would include SWBB only. Has anybody experience using LTO (link time optimization) also?

I also wanted to ask what's the technical difference between Surrogate and Switch? Could I use PJONInteractiveRouter<PJONVirtualBusRouter<PJONSwitch>> also for TS to SWBB Surrogate? Why?

Regarding my TODO https://github.com/gioblu/PJON/issues/211#issuecomment-397952478:

drtrigon commented 6 years ago

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 ;) May be https://forum.arduino.cc/index.php?topic=530659.0 helps?

fredilarsen commented 6 years ago

@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.

drtrigon commented 6 years ago

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 nc or socat as mentioned in e.g. in http://www.dest-unreach.org/socat/doc/socat-multicast.html or in more detail, receive data with:

$ socat UDP-RECVFROM:9761,fork,reuseaddr -

and send with:

$ echo -ne 'some data\n' | socat - UDP4-DATAGRAM:255.255.255.255:9761,broadcast

(may be multicast should be used instead of broadcast, see http://www.dest-unreach.org/socat/doc/socat-multicast.html) This needs is to install socat first (http://www.ibuyopenwrt.com/index.php/8-yun-compatible/158-console-class):

opkg update
opkg install socat

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 socat from repos.

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.

drtrigon commented 6 years ago

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 https://github.com/gioblu/PJON/issues/222.