Fork as a non-tessel specific module

[techniq]

I've been working on a project using a BeagleBone Black and the pn532 (Adafruit's breakout board) and am currently using the nfc node module, which just provides node bindings to the libnfc C++ based library. I've been considering writing a native implementation when I came across this project. The MIT / Apache license permits a fork, but I wanted to get your feedback on the idea. I would be interesting in collaboration on the project so we could guarantee the same library could work with tessel as well as beaglebone black, raspberry pi, etc. I'm currently using the UART interface to communicate with the pn532 and it looks like this project is using I2C. I have some PCB created based for the UART connection so I would need to make sure the new/updated library could use both UART and I2C.

Thoughts?

[tcr]

Hey @techniq,

First off, this library would be the appropriate place to add UART support as well as I2C. Though our module only exposes its I2C lines, Tessel could be directly wired to Adafruit's board (say over the GPIO port) so it's worth covering all cases.

As for making this library portable, here's our story for that right now: work done by @nlintz in his "Portable Tessel Client": https://github.com/nlintz/PTP-Tessel includes an implementation of Tessel's generic hardware API (UART, I2C, SPI, and GPIO drivers) that work across BeagleBone, RasPi, and Cubieboard. Most of our npm modules can work using these drivers unmodified.

So rfid-n532 can work identically on Tessel or on another board with a PTP driver library (one implementing just our generic hardware API). We'd love to make this library as widely useful as possible beyond just Tessel, so I'd love to get your thoughts on that approach.

[tcr]

Also since this is the first mention of PTP stuff online: we want to split the driver code component (SPI, I2C, UART, GPIO interfaces) from the code pushing component, but for the moment they're bundled together in PTP-Tessel.

[techniq]

Hmm, while the PTP-Tessel project definitely looks promising and would allow me to use rfid-pn532 unmodified, I'm not sure how much I would want to tie my project to another hardware project's API with a facade. If I went the route of using a generic facade, I would rather it be with something not hardware specific like cylonjs. It also looks like PTP-Tessel doesn't currently have support for the BBB, but should be as easy as adding an entry to BOARD_PORTS.

[tcr]

(I believe @nlintz did get PTP as a proof of concept working on BBB, we should ensure that makes it to master).

We saw there's a gap between comprehensive platforms like Cylon / Johnny-Five and just the underlying driver layer, so we tried to abstract that without being too opinionated. Plus, not every library seemed to offer full support for GPIO+I2C+UART+SPI. But I can understand wanting to do a proper port.

If you're interested in forking the library to target a specific library or platform, we would encourage that. We can collaborate and ensure UART support works solidly for Tessel as well.

[techniq]

Sounds good, I'll let you know what I ultimately decide. I'm currently working on migrating my environment to run within a docker container on the BBB (which I have mostly working) but once that settles down I plan to look at dropping the libnfc dependency. I'll probably start by just forking this project and making the changes needed to get it working on the BBB, then finding the best way to abstract out the BBB dependency while still maintaining support for Tessel, RPi, etc. Thanks for your feedback and pointing me at the PTP-Tessel project as that might very well come in handy.

[tcr]

No problem! Also, @techniq, I'd love to know if you have links about getting Docker on BBB working. I tried a few months back but mostly came up empty.

[techniq]

I have some notes currently on a private github repo. I can look at posting them on a public gist if you need more details, but the short of it is:

• I spent some time trying to get Debian (Wheezy and Jessie) and Ubuntu (Trusty) to install and run Docker, but ended up using Arch Linux ARM because:
  • Ubuntu doesn't appear to have great ARMv7/armhf package support, especially with the docker package. They do have docker.io in the universe section, but it's only amd64 and i386. There is a armhf package on launchpad, but it was only up to 0.9.1 when I last looked (looks to be 1.0.1 now). If you do try Ubuntu, there are images available here
  • Docker has much better ARMv7/armhf support, and Jessie (testing) does include a docker.io package for armhf, and I was able to get it installed, but whenever I tried to run any docker commands, it just threw errors (I don't remember what exactly). I had trouble at the time finding a Jessie armhf image, and ended up doing a dist-upgrade on a wheezy install. Looking back, I think the issue may have been the kernel not upgrading correctly. It looks like a Debian Jessie image is available now. I seem to recall the Debian image fills a 2GB card (with data), so unless you have the latest revision model with the 4GB onboard, you'll want to use a 4GB+ SD card (and be sure to resize the rootfs to fill the disk).
  • Lastly, I setup Arch Linux ARM, and it installed without any issues (docker package is currently at 1.0.0).

For docker base container images, I'm currently using mazzolino/armhf-debian, which includes qemu-arm-static and allows you to run / further buildout the container while on a non-ARM machine (I run a 64-bit trusty vagrant VM on my macbook). Here's the full list of ARM based docker containers I had ran across:

• https://registry.hub.docker.com/u/mazzolino/armhf-debian/
• https://registry.hub.docker.com/u/mazzolino/armhf-ubuntu/
• https://registry.hub.docker.com/u/kytknst/debian-wheezy-armhf/
• https://registry.hub.docker.com/u/cellofellow/rpi-arch/
• https://github.com/djmaze/armhf-ubuntu-docker

The debian images are at least 150MB smaller than the Ubuntu images it seems, and I was able to setup NodeJS on the armhf-debian one (although npm install doesn't work through qemu-arm-static and must be run on device / non-emulated).

I saw Docker 1.2 has better device support (not requiring running the containers with --privileged), but I haven't upgraded to it yet (waiting on the archlinux package to update soon hopefully).

This post ended up not being as short as I intended, but should give you a good start. My notes include how to flash both disk and partition images, resizing the rootfs partitions to fill the SD card, and other various reference docs. We can chat sometime if you need some help getting things setup. Hope this helps :)