tessel/t2-firmware

Firmware for Tessel 2's SAMD21 coprocessor and related SoC code

Tessel 2 Firmware

• About the T2 Firmware
  • SAM D21 Overview
  • Directory structure
  • Bridge
    • Signals
  • Port command queue
  • Compiling
    • Dependencies
    • Building
    • Updating

About the T2 Firmware

SAM D21 Overview

The Atmel SAM D21 microcontroller on Tessel 2 serves several purposes:

• Controls the two module ports' GPIO, SPI, UART, I2C, and ADC interfaces from the SoC
• Transfers data and commands between USB and the SoC for the Tessel CLI
• Provides a USB serial console for the SoC
• Programs the SoC's SPI flash over USB
• Manages SoC and module port power state

Directory structure

• firmware/ -- The main SAMD21 firmware source
• common/ -- Utilities for SAMD21 peripherals and board-specific headers
• deps/ -- Dependency submodules: Atmel headers and USB stack
• boot/ -- USB DFU bootloader
• soc/ -- Bridge daemon running on the SoC that communicates with the MCU over SPI
• node/ -- Node libraries for controlling the module ports via the MCU

Bridge

The SPI bridge between the MT7620n ("SoC") and SAMD21 ("MCU") is modeled loosely on USB, and provides three bidirectional channels between Unix domain sockets on the Linux environment of the SoC and various functions in the MCU firmware. Pipe 0 is connected to a pair of USB endpoints and used for Tessel CLI communication with the Linux system. Pipes 1 and 2 are used for control of the two Tessel module ports.

Signals

• MOSI, MISO, SCK, CS1 -- SPI lines. SoC is SPI master, MCU is SPI slave
• SYNC -- driven low by the SoC during setup transfers, driven high by the SoC during data transfers
• IRQ -- driven high by the MCU when it wants to be polled by the SoC because it has data to send or has become ready to receive

Note that the MT7620 SPI controller is designed only to talk to SPI flash and is not full duplex, and the protocol designs around this limitation.

A transaction has a setup phase and an optional data phase. To begin the setup phase, the SoC brings SYNC low. On this pin change, the MCU prepares a DMA chain for the setup transfer. In the setup transfer, each side provides:

• A magic number, to verify correct operation
• Bits specifying which channels are connected
• Bits specifying which channels for which this side is ready to accept data
• A byte for each channel specifying the data length ready to be sent on that channel

After this information is exchanged, both sides can compute the contents of the data transfer. If one side is ready to accept data on that channel and the other sends a nonzero length, the transfer will be performed. Otherwise that channel-direction is ignored for this transaction, and the writable bit or length count are repeated in future transfers until the other is present. The SoC drives SYNC high to begin the data phase.

The data transfer payload contains the channel payloads in channel order. There is no framing information in the data transfer, as it was derived from the setup payload. The MCU sets up a chain of DMA operations between the SPI controller and the provided buffers.

Port command queue

Each port has an independent command queue, which is accessed through a Unix domain socket on the Linux SoC. Node or other software can submit a batch of actions that are sent in a single bridge transaction which are executed in order and replies sent back via bridge and domain socket.

Some replies (pin change interrupt, UART receive) are asynchronously inserted into the stream of in-order replies.

The eventual goal is that the SoC will send larger command batches or macros to be executed in real-time, isolated from the Linux preemptive scheduler and Node garbage collector.

Compiling

Dependencies

Building the firmware requires gcc-arm-embedded.

OS X

To install quickly on a Mac with Homebrew:

brew tap tessel/tools
brew install gcc-arm

Ubuntu 14.04, 14.10

Use the gcc-arm-embedded PPA:

sudo add-apt-repository ppa:terry.guo/gcc-arm-embedded && sudo apt-get update
sudo apt-get install git gcc-arm-none-eabi

Building

git clone https://github.com/tessel/t2-firmware --recursive
cd t2-firmware
make

Updating

dfu-util is a command line utility to update the firmware on T2. See their website for installation instructions (brew install dfu-util works).

Plug the USB port your T2 into your computer while holding down the button by the Tessel 2 logo - this will put T2 into bootloader mode, with the power LED blinking.

Now flash the device:

Preferred: t2-cli

Make sure t2-cli is installed

npm i -g t2-cli 

then, to update the SAMD21 binary, run:

t2 update --firmware-path build/firmware.bin

to update the OpenWRT binary, run:

t2 update --openwrt-path [path to your tessel-openwrt build]

Note: if you do not provide a --firmware-path or --openwrt-path, t2-cli will default to pulling remote images!

Legacy: dfu-util

➜  dfu-util -aFlash -d 1209:7551 -D build/firmware.bin
...
dfu-util: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!
Opening DFU capable USB device...
ID 1209:7551
Run-time device DFU version 0101
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 0101
Device returned transfer size 256
Copying data from PC to DFU device
Download	[=========================] 100%        12524 bytes
Download done.
state(7) = dfuMANIFEST, status(0) = No error condition is present
dfu-util: unable to read DFU status after completion

That should be it! Don't worry about the final warning at the bottom - it doesn't seem to affect anything.

Note that this only updates the firmware on the SAMD21 coprocessor. You will need to update OpenWrt on the SoC separately-- TL;DR use t2-cli t2 update command.

Using a SWD debug probe

Solder an 0.05in header on J401 next to port A.

We use the Bus Blaster v3 with a Cortex Debug adapter cable.

It needs to be flashed to support SWD.

Then run:

arm-none-eabi-gdb build/firmware.elf -ex 'target remote | openocd -c "gdb_port pipe; tcl_port 0; telnet_port 0" -f scripts/d21.cfg'

Using onboard SWD

One of Tessel's unique features is the ability to program and debug the SAMD21 coprocessor from the MT7620 SoC without an external SWD adapter. The SAMD21 SWD pins are connected to GPIOs on the SoC, allowing openocd to bitbang the SWD protocol.

Log into your Tessel via SSH over WiFi or Ethernet. USB console is implemented in the SAMD21, and will be unavailable while that processor is stopped.

Run the following commands to install and start openocd.

opkg update
opkg install openocd

cat > openocd.cfg <<EOF
interface sysfsgpio
transport select swd

sysfsgpio_swd_nums 41 42
source [find target/at91samdXX.cfg]
EOF

openocd -f openocd.cfg

Then, in a checkout of this repository after compiling:

arm-none-eabi-gdb build/firmware.elf -ex 'target remote <tessel ip>:3333'

Flashing the bootloader

Warning: You probably do not need to do this. If the bootloader is intact, every other piece of software on Tessel can be fixed over USB. If you break the SAMD21 bootloader and can't boot or access the SoC, you'll need a SWD adapter to recover the device.

One of the duties of the SAMD21 is to sequence SoC power rails on bootup. Without it, the SoC may not boot reliably. If you do this with onboard SWD, be very careful, and don't power down the Tessel until you confirm that your computer recognizes the new bootloader over USB.

Compile the firmware, follow the openocd setup instructions above, then run:

$ arm-none-eabi-gdb build/boot.elf -ex 'target remote <tessel ip>:3333'
(gdb) load
(gdb) compare-sections
(gdb) mon reset run

t2-firmware's Issues

USB Daemon crashes with process responses larger than the max pipe buffer size

I caught this error when I tried to retrieve details about what networks were around in a crowded space.

Essentially, what happens is that the epoll indicates the child process has data on stdout to be read. All 4096 bytes are read from stdout into the internal buffer which causes the space_available var to become 0 and it removes the child process file descriptor from epoll.

Just after reading the data from the process into the internal buf, we check and see if we can write from the internal buffer to the CLI. We then proceed to write it out to the CLI. Once all the data has been written to the USB connection, we check if there is credit left on the pipe buffer. There isn't, so we attempt to remove the pipe buffer from epoll again, which causes the crash.

I2C API design issues

• The internal I2C class https://github.com/tessel/t2-firmware/blob/master/node/tessel.js#L424-L466 is designed to provide a 1:1 relationship between an instance and a specific device at a specific address.
• The I2C class is exposed via a Port instance method: https://github.com/tessel/t2-firmware/blob/master/node/tessel.js#L215-L220
  • This method only creates a new I2C instance if the instance's faux-private _i2c property hasn't been initialized and assigned a value (which is expected to be an instance of I2C)
  • The address provided as an argument (addr) to this method is forwarded on to the I2C class constructor, which is stored as the value of a property of the instance that was created.
  • The instance created is then assigned as the value of the port's _i2c property.
  • This only works correctly the first time, because any future invocations of port.I2C(address) will see that this._i2c has been assigned and will return that.
  • The consequence illustrated:

var device1 = port.I2C(0x00);
var device2 = port.I2C(0x01);

device1 === device2; // true
device2.addr; // 0x00

Node support for ADCs

Need better documentation on limitations for pins

E.g. only pins 2,5,6,7 on both ports support interrupts.

Other important information that needs documentation?

Node support for pulseIn

Akin to pulseIn on Tessel 1.

T2 LEDs return invalid state often

It appears to happen upon first read:

➜  t2-demo t2 init
➜  t2-demo t2 run index.js
INFO Connecting to Tessel...
INFO Connected to Harold over LAN
INFO Writing index.js to RAM on Harold (3.072 kB)...
INFO Deployed.
INFO Running index.js...
I'm blinking! (Press CTRL + C to stop)
I'm blinking! (Press CTRL + C to stop)
I'm blinking! (Press CTRL + C to stop)
/usr/lib/node/tessel-export.js:765
        throw new Error('Invalid state returned by LED:' + value);
              ^
Error: Invalid state returned by LED:255
    at /usr/lib/node/tessel-export.js:765:15
    at FSReqWrap.readFileAfterClose [as oncomplete] (fs.js:380:3)
INFO Stopping script...

SoC power management

The ability to disable SoC power on command and restore it on a specified event.

pin.rawWrite is undefined

I get the following error when running the ambient.js example. I haven't investigated yet:

/tmp/app/node_modules/ambient-attx4/node_modules/attiny-common/lib/index.js:26
  this.irq = hardware.digital[2].rawWrite(false);
                                 ^
TypeError: undefined is not a function
    at new Attiny (/tmp/app/node_modules/ambient-attx4/node_modules/attiny-common/lib/index.js:26:34)
    at new Ambient (/tmp/app/node_modules/ambient-attx4/index.js:41:17)
    at Object.use (/tmp/app/node_modules/ambient-attx4/index.js:383:10)
    at Object.<anonymous> (/tmp/app/node_modules/ambient-attx4/examples/ambient.js:13:26)
    at Module._compile (module.js:444:26)
    at Object.Module._extensions..js (module.js:462:10)
    at Module.load (module.js:339:32)
    at Function.Module._load (module.js:294:12)
    at Function.Module.runMain (module.js:485:10)
    at startup (node.js:112:16)

TypeError: i2c._initialize is not a function

Seems like this function on the I2C class is no longer present.

/tmp/remote-script/index.js:6
i2c._initialize()
    ^
TypeError: i2c._initialize is not a function
    at Object.<anonymous> (/tmp/remote-script/index.js:6:5)
    at Module._compile (module.js:426:26)
    at Object.Module._extensions..js (module.js:444:10)
    at Module.load (module.js:351:32)
    at Function.Module._load (module.js:306:12)
    at Function.Module.runMain (module.js:467:10)
    at startup (node.js:117:18)
    at node.js:948:3

Testcase:

var tessel = require('tessel')

var hardware = tessel.port.A
var i2c = new hardware.I2C(0x24)

i2c._initialize()

Clarify docs to make compiling/flashing easier for newcomers

Getting the T2 into bootloader mode

Issue:
It was quite hard to get the T2 into bootloader mode. For the first two tries I didn't manage, and didn't know (for someone who sees a Tessel for the first time, it wouldn't be straightforward what he should see)

Fix:
Explain the signs of the T2 entering bootloader mode (eg.: blue/power led blinking / red led on board continously lit)

Nit: alarming error message following flashing

Issue:

$ dfu-util -aFlash -d 1d50:6097 -D build/firmware.bin
dfu-util 0.8
...

Copying data from PC to DFU device
Download    [=========================] 100%        12624 bytes
Download done.
state(7) = dfuMANIFEST, status(0) = No error condition is present
dfu-util: unable to read DFU status after completion

Fix:
Would be nice if we could get rid of the unable to read DFU status after completion-message?

How do you make a release?

Need instructions in the readme

Optimize flash write

If the flash write code were aware of the data direction and were able to poll the status register on the MCU side, it could be made much more efficient.

Multiple-pin IO instructions

Add IO instructions that operate on multiple pins atomically.

USB Daemon doesn't always emit SIGKILL for children

Specifically, on the USB Daemon PR, I'm running into an issue where the USB Daemon isn't getting a SIGCHILD event for one of two completed processes.

The processes I'm running are:

/etc/init.d/tessel-app stop (process 0 below)
rm-rf /tmp/remote-script/ (process 1 below)

The packets being sent are:
-> New process of id 0
<- allocate 4096 credits for control, process 0
<- allocate 4096 credits for stdin, process 0
-> allocate 4096 credits for stdout, process 0
-> allocate 4096 credits for stderr, process 0

-> New process of id 1
<- allocate 4096 credits for control, process 1
<- allocate 4096 credits for stdin, process 1
-> allocate 4096 credits for stdout, process 1
-> allocate 4096 credits for stderr, process 1

-> Write to control buf, process 0
<- allocate more credits for control, process 0

-> Write to control buf, process 1
<- allocate more credits for control, process 1

-> Close control stream, process 0

-> Close control stream, process 1

!!! SIGCHILD occurs for process 1 !!!

-> Close process 1

<- Send data from STDERR to CLI (the data is "Not found" because the tessel-app script hasn't been started yet)
-> Add more credits to STDERR

Tests for bridge data integrity

The bridge (spid + firmware) could use extensive tests to verify data integrity by echoing randomly-sized packets on multiple channels to test all edge cases (queued packets, transfers with multiple channels, etc). I wrote a tool to parse logic analyser dumps for timing margin violations, which could be used in conjunction with this test tool. As a starting point, look at port_test.

hw bindings no longer available?

Have this bindings moved or isn't it written yet? It's used by the gps module.

var hw = process.binding('hw')

Error: No such module: hw
    at Error (native)
    at Object.<anonymous> (/tmp/remote-script/index.js:10:18)
    at Module._compile (module.js:426:26)
    at Object.Module._extensions..js (module.js:444:10)
    at Module.load (module.js:351:32)
    at Function.Module._load (module.js:306:12)
    at Module.require (module.js:361:17)
    at require (module.js:380:17)
    at Object.<anonymous> (/tmp/remote-script/test/getSetPollTime.js:5:11)
    at Module._compile (module.js:426:26)

Fix usbpipe buffer size

https://github.com/tessel/t2-firmware/blob/master/firmware/usbpipe.c#L3 is suboptimal.

The bridge can handle 255 byte chunks. Unfortunately, USB is optimized when transfers are a multiple of the endpoint size (64), but the bridge cannot handle 256 byte chunks due to its use of a 1-byte length field.

Expose enabling/disabling individual module ports on the T2

I noticed that the module ports only fire up once the require("tessel") call instantiates the hardware API. After this happens the module ports power up, and LEDs on both sides of the POWER led (next to their respective module ports) light up.

I have read on the forum that both module ports are planned to be individually powered and could be disabled from code, but I didn't see this functionality exposed yet.

This kind of functionality would come especially handy for LED/Display type modules (to temporarily turn off or reset/power cycle the module without extra wiring etc.).

Implement UART

Implement GPIO Interrupts from module ports

Digital gpio read reply not detected.

Two bisect operations led to 199970c which accidentally removed 199970c#diff-2d23ead71f8f80d4acf8db294b6989e8L101

Patch to follow.

Port is not a subclass of EventEmitter, but expects to emit an event

I discovered this while writing more tests for #63

t2-firmware/node/tessel.js

Line 89 in 0ce65d2

this.emit('async-event', byte);

Patch to follow

t2 wifi should not require password

I currently use MAC addresses to control access to my home network. Since my home network does not have a password the tessel 2 would not connect. I would like to run

  t2 wifi -n "Network Name"

I get no error message, but the tessel does not connect to my network.

have commit hash written to build

SPI with default chip select

Trying to instantiate an SPI connection without specifying chipSelect fails with this error.

usr/lib/node/tessel.js:464
    this.chipSelect = params.chipSelect || this._port.digital[0];
                                                             ^
TypeError: Cannot read property '0' of undefined
    at new SPI (/usr/lib/node/tessel.js:464:62)
    at new Port.SPI (/usr/lib/node/tessel.js:217:51)
    at new ISP (/tmp/remote-script/node_modules/attiny-common/node_modules/avr-isp/index.js:17:14)
    at Object.use (/tmp/remote-script/node_modules/attiny-common/node_modules/avr-isp/index.js:563:10)
    at Object.updateFirmware (/tmp/remote-script/node_modules/attiny-common/lib/attiny-isp.js:138:20)
    at Attiny.updateFirmware (/tmp/remote-script/node_modules/attiny-common/lib/index.js:181:7)
    at /tmp/remote-script/node_modules/attiny-common/lib/index.js:62:14
    at /tmp/remote-script/node_modules/attiny-common/lib/index.js:138:9
    at Port.spiComplete (/tmp/remote-script/node_modules/attiny-common/lib/index.js:173:19)
    at Port.<anonymous> (/usr/lib/node/tessel.js:93:40)

Error on default blinky example from `t2 init`

I get this error when I run the index.js generated by t2 init in the CLI:

uffer.js:260
      length += list[i].length;
                       ^
TypeError: Cannot read property 'length' of null
    at Function.Buffer.concat (buffer.js:260:24)
    at null.<anonymous> (/usr/lib/node/tessel-export.js:93:23)
    at emitNone (events.js:67:13)
    at Socket.emit (events.js:166:7)
    at emitReadable_ (_stream_readable.js:408:10)
    at emitReadable (_stream_readable.js:402:7)
    at onEofChunk (_stream_readable.js:387:3)
    at readableAddChunk (_stream_readable.js:129:5)
    at Socket.Readable.push (_stream_readable.js:110:10)
    at Pipe.onread (net.js:552:8)

Add APIs for Node to take advantage of instruction batches and advanced IO capabilities on the coprocessor

Couldn't ssh into tessel 2 with existing permissions

I'm facing following issue while trying to ssh into tessel after t2 provision.

ssh -i ~/.tessel/id_rsa [email protected]
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/Users/ravitejareddy/.tessel/id_rsa' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
bad permissions: ignore key: /Users/ravitejareddy/.tessel/id_rsa
Permission denied (publickey).

changing permissions to following fixed this

chmod 400 ~/.tessel/id_rsa

I'm using Mac OS. I'm not sure if this is relevant but tessel is not connected to my Laptop directly. It is connected to my router though LAN and my Laptop is connected to router through WiFi.

What needs doing on firmware?

Make issues for things that need to be done here.

Error running self.i2c._initialize() when starting RFID

Steps to Reproduce

1. Followed the instructions here: http://tessel.github.io/t2-start/modules/rfid.html
2. Get the following error in the console:

$ t2 run rfid.js
INFO Looking for your Tessel...
INFO Connected to charizard over USB
INFO Writing rfid.js to RAM on charizard (58.368 kB)...
INFO Deployed.
INFO Running rfid.js...
/tmp/remote-script/node_modules/rfid-pn532/index.js:64
  self.i2c._initialize();
           ^
TypeError: self.i2c._initialize is not a function
    at new RFID (/tmp/remote-script/node_modules/rfid-pn532/index.js:64:12)
    at Object.use (/tmp/remote-script/node_modules/rfid-pn532/index.js:723:10)
    at Object.<anonymous> (/tmp/remote-script/rfid.js:13:20)
    at Module._compile (module.js:426:26)
    at Object.Module._extensions..js (module.js:444:10)
    at Module.load (module.js:351:32)
    at Function.Module._load (module.js:306:12)
    at Function.Module.runMain (module.js:467:10)
    at startup (node.js:117:18)
    at node.js:948:3
events.js:85
      throw er; // Unhandled 'error' event
            ^
Error: Error upon remote process exit: 1
    at USBProcess.<anonymous> (~/.nvm/versions/node/v0.12.5/lib/node_modules/t2-cli/lib/usb/usb_process.js:49:26)
    at USBProcess.g (events.js:199:16)
    at USBProcess.emit (events.js:107:17)
    at Parser.<anonymous> (~/.nvm/versions/node/v0.12.5/lib/node_modules/t2-cli/lib/usb/usb_daemon.js:121:14)
    at Parser.emit (events.js:107:17)
    at Parser._write (~/.nvm/versions/node/v0.12.5/lib/node_modules/t2-cli/node_modules/usb-daemon-parser/index.js:152:16)
    at doWrite (_stream_writable.js:301:12)
    at writeOrBuffer (_stream_writable.js:288:5)
    at Parser.Writable.write (_stream_writable.js:217:11)
    at ondata (_stream_readable.js:540:20)
    at emit (events.js:107:17)
    at readableAddChunk (_stream_readable.js:163:16)
    at Readable.push (_stream_readable.js:126:10)
    at InEndpoint.emit (events.js:107:17)
    at Transfer.transferDone (~/.nvm/versions/node/v0.12.5/lib/node_modules/t2-cli/node_modules/usb/usb.js:295:9)

I'm on OS X 10.10.5

Feature Request: better Neopixel support across GPIO pins

In t1 the neopixel library is basic... but not bad. However there is a limitation of using only one strip as it is attached to a fixed pin (4 I believe).

Neopixel support on Tessel is great but this is a pretty big limitation. (for example - when running strips that can't realistically be chained together via their data-out-in lines, or that need to be controlled independently)

Reading I2C creates RangeError: Maximum call stack size exceeded

Tried this with the color sensor & reported as a bug there: johnnyman727/rgb-tcs34725#2

But hitting the same issue with the Gesture Sensor: https://github.com/jiahuang/apds-gesture

Both hit the issue while trying to receive data over I2C.

:0


RangeError: Maximum call stack size exceeded

Fix _rx/_tx buffer size limit / automatic chunking

I recently tried to port/use my UART-based serial OLED helper lib on the T2. After fixing some trivial issues stemming from the API changes I ran into the following error:

Error: Buffer size must be less than 255
    at Tessel.Port._tx (/usr/lib/node/tessel.js:219:11)
    at Tessel.UART._write (/usr/lib/node/tessel.js:620:14)
    at doWrite (_stream_writable.js:291:12)
    at clearBuffer (_stream_writable.js:395:7)
    at onwrite (_stream_writable.js:330:7)
    at WritableState.onwrite (_stream_writable.js:88:5)
    at null.<anonymous> (/usr/lib/node/tessel.js:114:31)
    at emitNone (events.js:67:13)
    at Socket.emit (events.js:166:7)
    at emitReadable_ (_stream_readable.js:408:10)

Apparently, it is hrown in the Tessel.Port.prototype._tx method of tessel.js:

  if (buf.length === 0) {
    throw new Error('Length must be non-zero');
  } else if (buf.length > 255) {
    // TODO: split into sequence of commands
    throw new Error('Buffer size must be less than 255');
  }

I could twist & bend the lib itself to fit this, but I think it would be better (for interop's sake*) if we fixed this in the platform itself.
How can I help with this?

*and also performance's sake.

Bridge data corruption

Seems to happen with lots of small packets, and is commonly triggered with io.js versions that don't support cork on domain sockets (1.4 did support it, 2.0.2 does not).

Probably the SYNC handler takes too long and the firmware is not ready for the SPI transfer.

We need a tool to spam the ports with random echo commands, and a tool to watch the logic analyzer trace on a firmware patched to toggle a GPIO in the IRQ and watch for timing violations.

Add API for Button functionality

There is currently no way to access the button input on tessel-2.
https://tessel.io/docs/hardwareAPI#button-and-leds

What would it take to add this functionality to the tessel-export.js module?

Need .on('rise') and .on('fall') events for pins

To maintain back-compatibility.
Relevant to tessel/hardware-modules#5

Is this best solved with a state variable?

Restart usbdaemon after USB connection closes

We could make successive CLI commands more likely to succeed if we restarted the USBDaemon after a connection closes. That way any unclosed process or broken state in the daemon would be resolved.

According to @kevinmehall we used to have this functionality but we lost it at some point.

I2C TypeError on construction

I get this error when running new hardware.I2C(0x24)

/usr/lib/node/tessel.js:430
    this._port._simple_cmd([CMD.ENABLE_I2C, this._baud]);
               ^
TypeError: this._port._simple_cmd is not a function
    at new I2C (/usr/lib/node/tessel.js:430:16)
    at new Port.I2C (/usr/lib/node/tessel.js:210:21)
    at new RFID (/tmp/remote-script/index.js:63:14)
    at Object.use (/tmp/remote-script/index.js:723:10)
    at /tmp/remote-script/test/readcard.js:15:13
    at /tmp/remote-script/node_modules/tinytap/src/tester.js:101:5
    at doNTCallback0 (node.js:408:9)
    at process._tickCallback (node.js:337:13)
    at Function.Module.runMain (module.js:469:11)
    at startup (node.js:117:18)

Indicate boot state using an LED

I would like to know when it's safe to start using a Tessel that's just booting up. It would be great if I could check out an LED indicator rather than polling ps to check when the USB Daemon is running.

Make update instructions clearer

Within #compiling section:

to make sure T2 is detected:

➜  dfu-util --list
...
Found DFU: [1209:7551] ver=0002, devnum=13, cfg=1, intf=0, alt=1, name="SRAM", serial="UNKNOWN"
Found DFU: [1209:7551] ver=0002, devnum=13, cfg=1, intf=0, alt=0, name="Flash", serial="UNKNOWN"
Note the vendor id and product id within the brackets (1209:7551 in this case). You'll need to substitute those numbers in the command below to flash the device:

What are we looking for?

Write a better test bench for the USBDaemon

Currently, the USBDaemon is using a Rust test bench copied over from the SPIDaemon tests and modified to create a domain socket rather than connect to one. In addition, it uses the Domain Specific Language from the SPIDaemon tests which are particularly not suited for the USBDaemon because it's going to be dealing with much larger transfers.

We should rewrite the test bench for the USB Daemon to be better suited for the use case and more exhaustive so we can flush out any remaining bugs.

I2C send never calls callback

This is causing problems with the accel module. The callback is never called and no is never printed.

console.log('yes')

i2c.send(new Buffer([0x2A, 0x00]), function (err) {
  console.log('no')
})

Node process involving tessel.js never exits

Moving over from tessel/t2-cli#222.

Implement synchronous port wait instructions

wait until a specified input pin is at a specified level.

Node support for sysfs LEDs

The require('tessel').led API should use the LEDs attached to the MT7620n by writing to /sys/class/leds/*/brightness.

In addition to direct control, we could consider APIs for setting triggers.

Node support for ws2812

Gotta get those Neopixels™ working.

New command: digital read port (A, B)

To make digital pin reading more efficient:

• allowing a client to request the values of the entire port, encoded as an 8-bit unsigned int byte
• "port value" is determined by these parameters:
  • 0 for pins that are enabled for I2C, SPI or UART use
  • 0 for pins that are input or output and currently "low"
  • 1 for pins that are input or output and currently "high"

Pins correspond to bits as:

B7	B6	B5	B4	B3	B2	B1	B0
7	6	5	4	3	2	1	0

For example, if all pins on a given port were in use as digital i/o pins and currently pin 7 is "high" and pins 0-6 are "low", then the port value would be 128:

B7	B6	B5	B4	B3	B2	B1	B0
1	0	0	0	0	0	0	0

Implement delay instructions

for timed GPIO bitbang

Node support for PWM output

TypeError: immediate._onImmediate is not a function

Hitting this error when trying to use the ambient module.

timers.js:371
      immediate._onImmediate();
                ^
TypeError: immediate._onImmediate is not a function
    at processImmediate [as _immediateCallback] (timers.js:371:17)