Variable arguments on ARM architectures

Hacking around into ARM and thinking about scheduling I was thinking about C functions variable arguments: although not very useful for a small operating system like NxOS, I thought that including the va_* functions into the base library would be cool. Even if it seemed quite simple, I’ve thought to check it out from a reliable source like uClibc.

It’s pretty strange, but the current version of uClibc seems not to include the stdarg.h header file. After a quick google search, I’ve found this source file. It’s not really included in uClibc, but at least it bore out my hypotesis…

The point is that there’s a specific procedure call standard for the ARM architecture. I should read it deeply, but it’s easy to understand that the registers r0, r1 and r2 are used for the first parameters of a function. There’s no way to get a pointer to a register, but the C programming language includes the va_* functions, hence there must be a de-facto standard, or something similar. The document just briefly mentions them into section 7.1.4.

I’d like to investigate on this issue, and maybe, eventually, I’ll put my results on this blog.

Shared UART/CC2420 access for the msp430 (TinyOS)

I’m proud to annunce the first, still totally untested, version of the DispatcherC component, currently hosted on the mercurial repository (http://freehg.org/u/dacav/tiny_cynar_dispatcher/ ).

The component provides:

• A protocol for nxt commands encoding
• A modularized code that allows the programmer to access both the cc2420 radio and the uart

Some code available

I’ve published a mercurial repository containing all the development source code for this project. Everything can be found at:

http://freehg.org/u/dacav

Since my last post, a lot of time ago, the project underwent some changes due to technical discussion and organizational delays: some code in nesC has been written for the synchronization between tmotes nodes. The code has been changed a lot of times, so the repository contains a lot of stuff that should be tested.

My new task consists in the creation of a half duplex communication library, made as enhancement of the device driver included into the current nxos mainline. I’m producing some patches in a dedicated repository

TinyOs U[s]art: so in[s]idious!

So damned world of TinyOS!
How many snares!
You can say it loud!!

On these days we are experimenting troubles, since we need to make the TMote communicate with the NXT brick. The thing probably doesn’t seem so bad… after all we’ve got both a working Rs485 driver on the NxOS, and a consolidated operating system like TinyOS on the other side that provides us a USART device driver! But the world isn’t so plain as it seems…

First working release

Finally it works!

After some days of hard work, finally we have got a working device driver for
the rs485 serial interface! It has been some kind of painful experience …
However here there’s a summary description of the performed work:

Lurking on the Web

It seems that we’ll need to write software for both sides of the boat! Ok, this is not so surprising or unexpected…

The point is that, in order to learn how to move in the TinyOs environment, I’ll need to know something about NesC. Lurking on the web I’ve found this interesting paper… it seems to be a good recreational reading material…

RS485, Communication begins

After a quite long period of inactivity (in these days I’ve still a lot of stuff to do for exams…), I’ve started a closer collaboration with Paolo Pivato, who is working on the T-Mote support.

We just realized that the two device drivers are actually capable of data transmission. Now we need to test reception support, as it doesn’t work for the moment. The problem is probably due to a simple configuration issue.

In this very moment I’m searching in the source code of TinyOs for the Data Link protocol specification of the UART.

Searching for RS485

RS485 Communication

It has been decided that the Mindstorms brick will communicate with the Tmote with a RS485 communication interface. On the NXT this interface is situated on the 4th RJ11 port.

In these days I’m trying to find out information on the RS485, since I’m going to develop a serial software protocol. As asserted at wednesday’s meeting, and specified by the documentation I’ve found on the web, the interface hardware requires a half-duplex transmission protocol (It seems however that the consecuences of a wrong use of a RS485 interface shouldn’t be so critical).

Other operating systems for Mindstorms

In these days I’ve tried an alternative operating system for the Lego NXT called NXOS. The link of NXOS webpage has been put into my blogroll.

The operating system seems not to be a RTOS, but I like how it’s structured and managed. Here follow a brief overview of my very early experience with that system:

3rd Week results: a new parser scaffold

As the oil parser’s source code is not free software, my new objective is to get an unfettered one.

The OSEK Specification (the website is linked on my blogroll) provides all information necessary to write a parser for OIL, so I’ve started to write a new parser in order to replace the deadly SG.exe.