[HN Gopher] Jacdac Plug-and-Play for Microcontrollers
       ___________________________________________________________________
        
       Jacdac Plug-and-Play for Microcontrollers
        
       Author : nrsapt
       Score  : 44 points
       Date   : 2022-03-15 10:09 UTC (1 days ago)
        
 (HTM) web link (microsoft.github.io)
 (TXT) w3m dump (microsoft.github.io)
        
       | j_leboulanger wrote:
       | Can you buy the cable ?
       | 
       | That seems interesting on the cost side if the cable is not too
       | expensive.
        
         | mmoskal wrote:
         | Right now, only if you're buying 10,000 units, but hopefully
         | will change soon!
        
         | a2800276 wrote:
         | The cable/connector does indeed look interesting, if easily
         | available ... possibly with more pins... I wish they had more
         | details, from the thumbnail[0] they posted of the board edge
         | PCB footprint, I don't see how it could be reversible... The
         | short finger (presumably VDD) would need to be on opposing
         | sides top and bottom, and it's always on the right. Or is my
         | thinking messed up?
         | 
         | [0]: https://microsoft.github.io/jacdac-
         | docs/overview/connectorca...
        
           | jamesadevine wrote:
           | It is reversible! The reversibility is largely provided by
           | the PCB edge connector as you've identified. More details
           | here [0]
           | 
           | [0] - https://microsoft.github.io/jacdac-
           | docs/ddk/design/#pcb-edge...
        
             | gbraad wrote:
             | The original jackplug was also just as simple. Instead of
             | 3.5 they could have gone for the 2.5" to avoid confusion as
             | an audio out. But the new proposed cable? Is it available?
             | Seems to be more work to offer.
             | 
             | /me checks taobao again
             | 
             | Nope, still not.
             | 
             | Kittenbot devices came with a standard audio jackplug. Easy
             | cabling, off the shelf.
        
               | camtarn wrote:
               | Ah, was that the origin of the name I wonder? Definitely
               | would have been a nice idea. I'm also not fond of the
               | custom connector.
        
               | camtarn wrote:
               | Although, thinking about it, I wonder if the connector is
               | designed for sequencing (power/ground first, then data)
               | and if the linear insertion of the jack plug caused
               | issues with that, since when the plug is being inserted
               | the connector nearest to the outside contacts all three
               | of the rings on the jack in turn.
        
               | gbraad wrote:
               | Yep, it wasn't perfect and might cause issues with
               | shorting the terminals briefly.
               | 
               | But this wasn't originally for rocket science, but simple
               | DIY projects or kids projects. If repositioned it will
               | have a hard time getting adopted.
        
       | zanethomas wrote:
       | The nice thing about standards is that there are so many of them
       | to choose from. ---Andrew S. Tanenbaum
        
       | joezydeco wrote:
       | This popped up three years ago (including on HN) and then
       | disappeared. How did it end up at Microsoft?
       | 
       | https://web.archive.org/web/20191130155328/https://jacdac.or...
       | 
       | I worked with a similar single-wire protocol when working with a
       | large German appliance maker. This looks pretty close to the same
       | idea, they even used PCB edge connectors like this to save a few
       | pennies.
       | 
       | I'll just add that getting the software and hardware right is a
       | lot trickier than it looks. Bus arbitration and collision
       | recovery at the hardware level isn't always the easiest when
       | working with low speed microcontrollers. And, by the time you
       | have it all working, you've reinvented CANBUS but without the
       | differential signalling so you need to keep the cables short.
       | 
       | And all of this is supposed to fit on a single 'cute' board with
       | a pushbutton or tricolor LED? Hardware overkill.
       | 
       | It probably has some use in the hobbyist sector, I'd love to see
       | Sparkfun or Lady Ada pick it up but they're very smart groups and
       | have their own direction with things like Qwiic (which is just
       | I2C, something already on a lot of MCUs in hardware) The
       | proprietary connector, fixed to 3 pins only, is a huge turnoff
       | too. I can get a lot more mileage out of putting FTDI parts on
       | each side of a board and using USB-C patch cords I bought at the
       | gas station.
        
         | camtarn wrote:
         | Yeah. Something like a standard set of protocols on top of an
         | existing peer-to-peer bus, with a good set of supporting
         | libraries, would have been great. I love the idea of service
         | advertising and standard service APIs.
        
         | gbraad wrote:
         | It was developed IIRC by an intern as part of his thesis and
         | included in the microbit tooling on makecode. After this it got
         | more standardized, but they went to a less obvious connector
         | (Kittenbot came with a standard jack) and now they describe a
         | custom plug. This increased the barrier of entrance and
         | building came less appealing to me.
        
           | mmoskal wrote:
           | The main issue with audio jack cables is that they are not
           | designed to carry much power (Jacdac cables are rated at 1A).
           | You get different voltage drop depending on what cable user
           | bought at the gas station. This is a problem is you want to
           | run a small servo or even a few neopixels on a module.
           | 
           | Another issue is that the connector often short while
           | plugging-in and out which may cut the power to your entire
           | bus, resetting everything. Not a great end-user experience.
           | There is also a risk users will plug Jacdac to their
           | headphones, possibly burning them.
        
           | joezydeco wrote:
           | Yeah it totally has that 'quickly-launched-short-lived summer
           | intern project' vibe to it which is fine but is something I'd
           | typically expect out of Google, but not Microsoft.
        
         | mmoskal wrote:
         | Indeed, if you know how to design a custom PCB, have it made,
         | and write embedded software, then Jacdac might be an overkill
         | for you.
         | 
         | The Qwiic cables have to be really short (Jacdac cables can be
         | a few meters) and are not designed for easy plug-in and out
         | thousands of times. Also, the I2C devices are not standardized
         | meaning you need a new driver in your software environment for
         | every single accelerometer. Finally, I2C doesn't let you have
         | multiple instances of the same device because of address
         | collisions.
        
           | joezydeco wrote:
           | But doesn't Jacdac require PCB customization as well to make
           | that edge connector work?
        
             | mmoskal wrote:
             | Eventually, you'll be able to buy Jacdac modules, brains,
             | and cables.
        
       | littlevache wrote:
       | As the XKCD prophecy foretold, there are now 15 competing
       | standards... https://xkcd.com/927/
        
         | progre wrote:
         | And the 14 other bus protocols with service advertising aimed
         | at microcontrollers are...?
        
           | Goz3rr wrote:
           | From the top of my head: SPI, I2C, 1-wire, UART/RS232, RS485,
           | CAN and a bunch more I'm not remembering
        
             | progre wrote:
             | None of those has service advertising (only enumeration).
             | RS232 is not even a buss protocol,
        
             | camtarn wrote:
             | I guess the differentiator is that Jacdac is a higher level
             | protocol. RS232, RS485 and CAN are just 'send some data
             | down this pipe' deals, and RS232/RS485 don't even have a
             | particularly standard way of framing data. I haven't used
             | SPI or I2C enough to know about them, but from looking them
             | up, they also seem to just offer a way to send arbitrary
             | data.
             | 
             | Jacdac both offers a standard way of using devices (from
             | the website: 'devices with the same functionality but
             | different hardware implementations can be substituted
             | without having to recompile the application that uses them.
             | For example, two different models of accelerometer hardware
             | can replace each other because they share the same software
             | interface.') and a standard way of finding devices (because
             | all devices advertise the services they provide every
             | 500ms).
             | 
             | Honestly, as somebody whose job involves a lot of
             | interfacing with random bits of hardware, this would make
             | my life a heck of a lot easier! There have been way too
             | many times I've received a device manual for e.g. a Modbus-
             | over-RS485 interface and had to go 'okay, is this list of
             | register IDs zero-based or one-based? floating point or
             | fixed point? big-endian or little-endian (or _both_ in the
             | case of one awful device!) ' etc etc.
        
               | mmoskal wrote:
               | Indeed! Lots of Jacdac is not about the cable or the
               | UART-based signaling, but about the service
               | standardization and definitions.
               | 
               | Now if only we could get all these silicon vendors to put
               | Jacdac directly on their current I2C/SPI sensors... It's
               | definitely possible given that basic Jacdac
               | implementation runs on PMC150C with 64 bytes or RAM and
               | 1.5k of ROM, but it may be a hard sell since they seem to
               | like lock-in.
        
       | buescher wrote:
       | This is like a software engineer's idea of modular hardware.
       | Looks like fun and may be great for one-offs. The problem for
       | using a system like this for early prototypes and proof-of-
       | concept is that the hardware AND software of a cost-optimized
       | production device is going to be from a completely different
       | planet.
       | 
       | I like the edge connector though - nice way to get a maybe-
       | someday connector on a board without adding visible BOM cost. The
       | board routing involved will cost money, of course, and the gold
       | plating shown, if necessary, is also a cost adder.
        
         | mmoskal wrote:
         | If you want to make a million copies of something, Jacdac is
         | unlikely to help you much outside early prototyping. OTOH, if
         | you want 10 copies of something it may simplify things - you
         | don't have to solder any wires 10 times. If you want more, you
         | can get a PCB with holes matching holes on modules and screw
         | them in with M3 screws (skipping the cables - the holes carry
         | signals), or solder them down.
         | 
         | Gold plating is not strictly necessary, depending if you plan
         | to use the plug thousands of times.
         | 
         | Edit: also very good observation on top of the comment - Jacdac
         | is indeed a way to bring "modern" software engineering
         | practices to hardware design.
        
       ___________________________________________________________________
       (page generated 2022-03-16 23:01 UTC)