How to debug app, and best way to connect to Baby Orangutan?

Support Wixel
1

I just received my Wixels and I couldn’t be happier. I plugged it into a USB port (after installing libusb and libqtgui4) and it worked like a charm. The example_blink_led app loaded and ran perfectly the first time. Modifying the blink rate parameter and re-flashing worked too.

Well done folks, I’m really pleased and impressed. Thank you for making such a quality product.

I’m eager to write a custom app to program the Wixel and I was hoping to get some information about using sdcdb (and the simulator) to run and debug my app (locally, before flashing it to the chip.) Does anyone have any pointers or URLs about this? I looked online and searched the Pololu forums but I couldn’t really find much. The SDCC manual has a brief section on using the sdcdb debugger but I need more.

Also, I am going to be connecting the Wixel to a Baby Orangutan and I was wondering about potential trade-offs between the different methods:

  • SPI - native support on both sides

  • I2C - native on the AVR; software lib (Thanks Pololu!) on the Wixel

  • UART - “plain old” serial connection, native on both

  • …something else?

I also have an IMU (MiniIMU-9, wooo!) with an I2C interface, so my first thought was to just plug all three modules onto the same I2C bus and let the protocol handle it. But the I2C lib for the Wixel is master-only and I kind of want the Baby Orangutan to be in charge. I can patch the I2C lib to allow operating in slave mode, and maybe add support for multi-master at the same time, but that’s going to take awhile (especially without debugger support.)

The next option would be to plug the IMU and Wixel together with I2C and plug the Baby-O and the Wixel together with SPI or a serial connection. The Wixel will be polling the IMU and “serving” processed postion and trajectory info to the Orangutan, and (if it seems really needed) it wouldn’t be hard to write some sort of “pass-through” command interface to let the Orangutan communicate with the IMU through the Wixel.

It seems the UART route would be easist, since it wouldn’t involve writing a SPI lib for the Wixel. But writing and contributing that lib would be a lot of fun…

What do you guys think? Any suggestions?

2

Hello, sforman.

I’m glad you are having a good experience with the Wixel!

We haven’t tried sdcdb. You can probably use it to debug some bits of you code but I’m pretty sure it’s not going to be able to simulate the peripherals on the CC2511F32 like the radio, the ADC, or the I/O pins.

You might be interested to know that we just released an SPI master library for the Wixel:
pololu.github.com/wixel-sdk/spi0__master_8h.html

If at all possible, I recommend that you write your firmware on one processor instead of two. For example you could just use a Wixel and get rid of the Baby Orangutan, or use a Baby Orangutan and use one of our precompiled apps for the Wixel. In general I think this approach just makes things a lot simpler. One specific reason is that inventing your own communication protocol and debugging both sides of the communication can be tricky, and I wouldn’t want to do it without an oscilloscope. Do you have an oscilloscope?

I would probably connect the Baby Orangutan and Wixel via their UART interfaces but I don’t know enough about your goals and constraints to say if that’s the right choice for you.

–David

3

Hey David,

Thanks. I’m really impressed with the Wixel and the other stuff I got.

If you don’t use sdcdb, what do you use? I guess you have enough Wixels/CC2511F32 laying around that you can just use in-circuit debuggers. I’m not planning to use the Wixel for anything too exotic so I can almost certainly modify one of the existing apps to serve, but I find the idea of burning un-debugged code onto a real chip somewhat unnerving.

The SPI master library is welcome news. I’m really glad you support your products so well.

As you say, I’m going to concentrate on the firmware for one chip (the AVR) and not worry too much about the other. When I originally ordered them I hadn’t checked the Wixels’ processors specs and I didn’t realize how powerful they were. I was just going to use them as a radio connection but then I realized that that would be wasting them (or at least the one on board the robot.)

At the very least, in addition to serving as a radio link between the Baby Orangutan and the base-station, I’d like to get the on-board Wixel to poll and record data from the IMU, send it to the base-station, (pre-)process it for the Baby Orangutan (for position, attitude, sudden alterations of same, etc…), and act as a crude document server (of code pages) to the Orangutan.

Nothing major.

I don’t have an oscilloscope, but I’ve always wanted one and I’d love a great excuse to get one. That said, I was kinda hoping I could just wire the Baby-O to the Wixel with I2C and set their rates to the same value and be good to go. Not that simple?

The protocol I plan to use is ridiculously simple yet powerful. I’m writing a Forth-like interpreter for the AVR (incredibly fun BTW, I love the CISC architecture!) that will accept incoming bytes on (whatever) serial connection and “parse” them as Forth commands. Essentially the robot will start as a “blank” programmable slate and I’ll be able to “talk” to it and lay down new programs (and machine code primitives) on the fly.

Next, there’s an article, A BNF Parser in Forth, that describes how to create a BNF parser (no surprise, eh?) using only about 1-2K of Forth source (which compiles down into much smaller Forth “words”.)

I’ll be able to adapt that code to let the firmware parse BNF language descriptions, which then, in turn, enables it to parse the languages defined in the descriptions, allowing me to bootstrap the code up to the point where it can understand custom DSLs (Domain Specific Language) that describe things like, say, how to respond to incoming sensory stimuli.

Last night I thought up the term “Haiku Programming” to describe what I’m planning.

This ties into work being done at Alan Kay’s Viewpoints Research Institute with their OMeta parser and the COLA concepts. (They have a “parser” that recognizes and responds to TCP packets and implements a TCP/IP stack…)

For what it’s worth, I’m building a flying kite-ish sort of robot. The primary constraint is therefore weight, followed closely by low power consumption. Other than that I don’t need I high bandwidth or anything.

Warm regards,
~Simon

4

We run the code and see if it behaves as expected. If it doesn’t then I might insert some debugging code to toggle I/O pins or turn on LEDs to help me figure out what is going on. I’m pretty sure the Wixel can not destroy itself so it is not unnerving.

Did you mean to say UART instead of I2C? Yes, it is that simple if you use a precompiled Wixel app that we’ve already tested but not if you are writing your own.

It sounds like an interesting project so let us know how it goes!

–David

5

Well if that’s the case I should be good to go with the existing apps and libraries. Thank you!

Well, I thought I meant I2C, but really I’m asking about the tradeoffs. (I was under the impression that I could basically wire up the Baby Orangutan, Wixel, and IMU with two wires and let them talk to each other with the I2C protocol. But I’m a total newbie to this stuff.) Why the UART instead of I2C? There are Wixel libs for both, no?

Thanks for your attention and feedback. I’m really having a lot of fun with this stuff, and writing the AVR firmware.

Earlier tonight I got it to the point where it can interpret a command line (from a buffer in memory, but the scanner goes through a character-by-character “get next char” command that can be easily connected to a serial byte source.)

So far, in 618 bytes of (machine) code, it’s got:

drop - pop the top item from the stack and discard it.

swap - swap the top two items on the stack

dup - duplicate the top item on the stack

key - get the next character byte from the buffer and put it on the stack

word - scan a space-delimited token (word name) from the buffer, put the
       offset of the word in TOS and the length of the word in TOS-1

find - give an offset and length (as from "word" above) on the stack
       return the address of the word or 0xffff in TOS and TOS-1

interpret - read the buffer and execute the named words

<<w - left shift a 16-bit value in TOS and TOS-1 (used for addressing
      flash RAM on the AVR)

@ - given a byte offset in TOS look up it's value in the heap (user
    variable storage.) Used in conjunction with the variable words below

var_does - class for variable instances, not word for interpreting.
           puts its word's PFA onto the stack

here - variable, points to free space on heap

latest - variable, 16-bit, points to most recently defined word in dict.

state - variable, compiling vs. interpreting (not used yet)

ckey - variable, current read offset in input buffer

>pfa - given a word's address, calculates its PFA (Parameter Field
     - Address) where the word's code (or whatever) lives.


example command lines:

get the offset in the heap of the first free byte
  here @

look up the address of the machine code for the word "dup"
  word dup find >pfa

Next I’ll write compiling commands for creating new commands on the fly, a page-writing command that can move the new code from SRAM to Flash (program) RAM, and enough UART (or whatever) code to get bytes from my computer (and eventually the radio/base-station) to the interpreter.

After that the firmware should be completely self-hosting. :slight_smile:

Cheers,
~Simon

6

Hello, sforman. The Wixel i2c library only supports having the Wixel as the master so that’s probably not what you want. We don’t supply any i2c libraries for the Baby Orangutan but you can probably find some elsewhere. The Arduino IDE’s Wire library runs on an ATmega328P.

–David

7

Thanks David,

I should be able to do most of what I want to with the pre-existing Wixel apps. For now I have my firmware running on the Baby Orangutan and interpreting commands sent over the UART serial connection provided by the USB programmer (which works flawlessly by the way, very nice work folks!)

I can use the apps to let the Wixels act as a wireless serial bridge for now and worry about programming them to do more later.

Thank you again,
warm regards,
~Simon

8

I loaded the wireless serial app onto both Wixels and connected one to the Baby Orangutan (with voltage divider on the B.O. Tx -> Wxl Rx line to handle the 5v to 3.3v difference in operating voltages) and the other to my computer with the USB cable.

Everything worked so flawlessly that, if it weren’t so exciting, it would almost be anticlimactic. :smiley:

Very nice work Pololu!

~Simon