Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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

0 - https://dicks.home.xs4all.nl/avr/usbtiny/



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


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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: