More info here: www.pjon.org
Great work on PJON! Where can I find documentation/more info on how to build this for STM32 microcontrollers, like the STM32F091CCU7 using SerialAsync (over PLC)?
PJON 12.0 – Networking freedom for hackers, makers and experimenters
11–20 of 23 posts
Re: PJON 12.0 – Networking freedom for hackers, makers and experimenters
#12Happy to see somebody from my city dedicated to such an ambitious project. I wish you all the best Giovanni! I see you are based in Via Larga, do you guys have an office there?
Ciao mahesh, I do not know many people who is interested in computer science or networking here in Milan. Would be a pleasure to have a chat :)
Re: PJON 12.0 – Networking freedom for hackers, makers and experimenters
#13Cool! I see the documentation mentions:
> ... during development its scope and features have been extended to cover use cases where IP is generally applied
I understand the point is having minimal requirements, but how do you interoperate w/ IP?
Re: PJON 12.0 – Networking freedom for hackers, makers and experimenters
#14Happy to see somebody from my city dedicated to such an ambitious project. I wish you all the best Giovanni! I see you are based in Via Larga, do you guys have an office there?
Ciao mahesh, I do not know many people who is interested in computer science or networking here in Milan. Would be a pleasure to have a chat :)
Email inviata!
Re: PJON 12.0 – Networking freedom for hackers, makers and experimenters
#15Re: PJON 12.0 – Networking freedom for hackers, makers and experimenters
#16Earlier quoted context omitted.
Great work on PJON! Where can I find documentation/more info on how to build this for STM32 microcontrollers, like the STM32F091CCU7 using SerialAsync (over PLC)?
Would also be interested in PJON for stm32 based systems.
Although stm32 is not the widest support, some strategies work with it, see the compatibility table here: https://github.com/gioblu/PJON/wiki
Re: PJON 12.0 – Networking freedom for hackers, makers and experimenters
#17Cool! I see the documentation mentions: > ... during development its scope and features have been extended to cover use cases where IP is generally applied I understand the point is having minimal requirements, but how do you interoperate w/ IP?
PJON is based on a concept of selectable "strategies" to support using the protocol with different physical media. Some of these, like the one named SoftwareBitBang which allows a bus on a wire connected directly to an I/O pin, are very compact.
There are also strategies for TCP and UDP based communication, essentially using the same packet structure but sending them as TCP or UDP over a LAN or WAN. These strategies need the Ethernet library, and use more memory.
Still, the memory requirement is small enough to run a router with two PJON objects with the strategies SoftwareBitBang and DualUDP on an Arduino Nano with a W5500 Ethernet shield. This allows easy traversal between different physical media, and IP-based communication, also with PJON-based software running on a Windows or Linux computer.
Re: PJON 12.0 – Networking freedom for hackers, makers and experimenters
#18I would be curious to see to what extent it supports error recovery. Perhaps I missed it, but I didn't see anything that specifically addressed that.
This seems like it would be very compelling, especially for small scale stuff. Being able to wire something as small as an ATiny85 into a computer and communicate over a relatively high-level protocol would be very useful for interfacing with sensors and other peripherals.
I wonder how difficult it would be to adapt something like USBtiny[0] build an adapter. For potentially a few $ worth of parts, you could connect to all kinds of nifty embedded peripherals, albeit at relatively slow speeds. One obvious use case that comes to mind would be controlling lights / sensors / fans etc. in custom computer builds.
Re: PJON 12.0 – Networking freedom for hackers, makers and experimenters
#19I would be curious to see to what extent it supports error recovery. Perhaps I missed it, but I didn't see anything that specifically addressed that. This seems like it would be very compelling, especially for small scale stuff. Being able to wire something as small as an ATiny85 into a computer and communicate over a relatively high-level protocol would be very useful for interfacing with sensors and other periphera…
There's an optional 8-bit CRC and sequence number, with a single bit ACK.[1] This is even weaker than ARCnet, circa 1977, one of the earliest protocols for talking to low-end devices.
This is for talking to things like lightbulbs with some US$0.50 CPU inside. It's for really low end devices. It's best for idempotent operations that can be requested repeatedly without harm and are timeout-tolerant.
[1] https://github.com/gioblu/PJON/blob/master/specification/PJO...
Re: PJON 12.0 – Networking freedom for hackers, makers and experimenters
#20I would be curious to see to what extent it supports error recovery. Perhaps I missed it, but I didn't see anything that specifically addressed that. This seems like it would be very compelling, especially for small scale stuff. Being able to wire something as small as an ATiny85 into a computer and communicate over a relatively high-level protocol would be very useful for interfacing with sensors and other periphera…
There's an optional 8-bit CRC and sequence number, with a single bit ACK.[1] This is even weaker than ARCnet, circa 1977, one of the earliest protocols for talking to low-end devices. This is for talking to things like lightbulbs with some US$0.50 CPU inside. It's for really low end devices. It's best for idempotent operations that can be requested repeatedly without harm and are timeout-tolerant. [1] https://github.…
Small correction: Using CRC is not optional. Setting the crc flag makes it use CRC32 even for very small packets. The default is to use CRC8 for packets of a few bytes and then upgrade to CRC32 over a small size threshold. This is to minimize the size of otherwise tiny packets.
Also, the ACK implementation depends on the strategy (physical media type), and it is not a single bit but a single byte, and it seems to me to be robust. I am sure the creator, gioblu, has some more comments about this.