Custom C to JS functions on Tessel

jia 2014-06-14 02:41:26 UTC #1

I wrote up a step by step tutorial for how make a simple C change in Tessel's firmware and expose it up to the JS userspace.

In the end, this silly test case passes.

var tessel = require('tessel');
console.log("Can Tessel add?", 3 == tessel.add(1, 2));

github.com

tessel/docs/blob/master/tutorials/c-to-js.md

# Expose a C function up to JS userspace

This tutorial goes over how to expose a C function to JS where the user can interact with it via any JS function.

The function will pass this simple test case:

```js
var tessel = require('tessel');
console.log("Can Tessel add?", 3 == tessel.add(1, 2));
```

1. Clone down the [tessel/firmware](https://github.com/tessel/firmware) repo.
2. Set up the firmware according to the [tessel/firmware readme](https://github.com/tessel/firmware/blob/master/README.md). 
3. Open up `src/tessel.c`. Add these lines 

	```c
	uint32_t tessel_add(uint32_t x, uint32_t y)
	{
		return x + y;
	}
	```

This file has been truncated. show original

williamaadams 2014-06-15 17:17:45 UTC #2

I tried these steps, and was successful, with some mods.
I am NOT an OSX developer, but I so happen to be using a Mac to play with my Tessel. I got tripped up on: brew install gyp

This had no end of problems, from me having an old developer preview of Xcode, to permissions problems on the /Library/Python directory.

After installing the latest Xcode, I was only left with the permissions problem on the Python library.

I brute forced my way through that by just making the directory writeable, which allowed me to finally install brew. It then had a symlink problem, but I brute forced that as well, and all seems to be fine.

I'd imagine a fresh out of the box mac with up to date Xcode would not run into these problems. Just so you know.

One Question: I think a serial number is written into the OTP area. That must be done in the firmware right? Is it the same for all teasels? If I'm modifying my firmware, what do I need to do in order to maintain a unique serial number in that area?

jia 2014-06-15 23:18:21 UTC #3

The serial number is not written in the OTP region. All LPC1830 chips have a unique serial number at these rando memory locations. Nothing you do will overwrite that unless you change our linker script. What we do write is the TM board version (00, 02, 04, etc). We look this up when finding pin mappings.

I highly recommend against altering the OTP because we have no guarantees on which sections we may use in the future. That being said, the following might be useful:

OTP is handled differently than firmware. Updating the firmware does not change the OTP. Nothing touches the OTP unless you specifically change the OTP build. We only run this binary once, when first programming the boards.

It's also probably worth noting that according to the LPC1830 user manual pg 27 default OTP bits are all 0s, any 0 can always be flipped to a 1, but any 1s cannot be flipped back to a 0.

When you run make arm you'll see several binaries being built, among them:

the OTP binary
Wifi Patch binary
erase binary
firmware binary

Of these 4 binaries, only the firmware binary is supposed to be written to the ROM. You can see this if you look in the firmware linker script vs the OTP linker script. At the moment we don't explicitly expose the ability to write to RAM in our CLI, however you can use the dfu script directly to get access.

OlsonDev 2014-07-03 22:28:17 UTC #4

@jia Your GitHub link is no longer valid; it should be corrected to this.