SparkFun Electronics

[EmbeddedMan]

So check this out http://www.cpustick.com/index.htm
Download for UBW32 from here : http://www.cpustick.com/downloads.htm

Rich was kind enough to create a port of his really cool StickOS for PIC32, and then make a bootloader compatible version for us UBW32 people. His StickOS is a _self_hosted_ development environment on the PIC32. All you need is a terminal emulator (not even a PC). You write code in BASIC, debug it, profile it, step through it, breakpoint, etc. all right on the micro! Use timers, interrupts, counters, ZigBee, etc. He's planning on adding even more software support for cool peripherals in the future.

After you write your BASIC program, you save it to Flash. And get this - it compiles it down, stores it in flash compiled, then _decompiles_ it when you want a program listing! So the text of the source code is never stored. I'm really impressed, and see a lot of cool things you could do with this software.

At this point it is free (the HEX files are) and if you like Coldfire more than PIC32, that's where he originally started the work. I can't wait to do a little project with this software on my UBW32s - note, of course, that out of all the processors Rich has timed, the PIC32 runs code faster than any of the others.

So try it out, and let us know if you do something cool with this software. I'm sure Rich would love to hear any suggestions or feature requests.

Thanks a million Rich. Your work is very much appreciated.

*Brian

[ttabbal]

Wow... That's really cool. I totally hate BASIC though.

Anyone want to write a JVM? Java is significantly nicer to work in.
_________________
------ Travis

[Philba]

python! python!

OK, I know, not gonna happen but one can only hope.

[riden]

[ttabbal]

That aJile chip is a cool idea.

I was joking about a JVM on PIC, though it would be nice to see a higher level language than C, but lower than BASIC, available for applications that don't need to be super fast. Python would work fine for me as well.
_________________
------ Travis

[EmbeddedMan]

My impression is that StickOS is using a sort of VM concept - the lines of BASIC are translated to bytecode and stored in RAM or Flash, and then executed by the 'VM' from there. Maybe it would be possible to support other languages than BASIC? I don't know - I really don't have a problem with BASIC. Pascal anyone? Ooo - how about Lisp?

Honestly the PIC has power and memory, so if you'all wanted to put your favorite language on the UBW32, there's nothing holding you back . . .

*Brian

[rtestardi]

Sorry if this is a duplicte -- my first reply got eaten by the spam filter.

So I have to admit that StickOS really isn't so much about the "language" -- we've even considered putting language "skins" on it to make it look more like X or more like Y (the language-specific portion of parser is about 5% of the code)...

The real thing about StickOS is the software development environment (SDE) being *resident* within the MCU... This means you can log into the MCU and interactively have full control over the system just as if you were using an ICE... You can change your program, save your program, debug your program -- single step, breakpoints, watchpoints -- and even profile your program for performance, all using no off-MCU resources. You can even manipulate the pins/peripherals of the MCU interactively, as a slave data acquisition/control device (or just to play! :-).

Where this really shines is with the zigbee transport, where you can have a house full of these things, each with effectively its own ICE, and you can log in to each one from your PC, reprogram them, and they can even trivially communicate wirelessly (modifying each other's variables or pins remotely!) to form a distributed system.

So StickOS is really about giving the user full *interactive* control over the MCU, via an MCU-resident transport and SDE. It's also about being able to play with bits interactively at the keyboard -- that's been so much fun to me! :-)
_________________
Embedded Systems Made Easy: http://www.cpustick.com

[phishguy]

I liked what I saw. The only things that I wish was incorporated is a LCD driver routine and some string handling functions. Yes, I know they could be written in code. But, it would be nice if it was built in.

[rtestardi]

That's actually on our (ever growing :-) todo list... The LCD driver will initially only handle "print"-like output (thru a "scroll" command) initially, but eventually we'd like to handle string variables as well.

Basically our plans are for a number of SPI (and non-SPI) peripherals that are detected by the OS and then the OS has drivers (and often new BASIC statements) to control them -- the entire internal architecture is designed so that you can add commands/statements on a per-peripheral basis without affecting the core code.

(In fact, if you look at the Freescale Badge Board version, the LED display has three new commands associated with it -- "jmscroll" to scroll results across the display, and "jmset" and "jmclear" to handle bitmapped graphics. Those all use the "peripheral extension" mechanism in the code.)
_________________
Embedded Systems Made Easy: http://www.cpustick.com

[phishguy]

Great! I'll keep watching the website for developments.
Do you have a list of your anticipated additional features?

[rtestardi]

The biggest future features include:

1. expose mass storage interface (as well as serial port) to USB and allow drag-and-drop of BASIC programs and firmware.

2. add qspi-based peripherals (CF card reader, LCD display) and have automatic detection and new language features. Initially these will just be "print"-like statements that can append to a file on the CF card or scroll information across the LCD display.

3. similar to the qspi-based CF card, we'd eventually like to support USB host mode and log data directly to a memory stick (we have this all done in the StickOS "skeleton" code already, but have not integrated it with StickOS as in requires hardware support from the platform to go into host mode).

4. add a uart-based UI for MCUs that have neither USB nor Ethernet.

5. add string support for character arrays.

The main thing this depends on is me not finding (well, not accepting) a job for the next few months... I'm almost convinced there! :-)
_________________
Embedded Systems Made Easy: http://www.cpustick.com

[phishguy]

Congrats on the article on dev-monkey.
http://www.dev-monkey.com/blogs/jon_titus.php?mid=484&lp_id=72&nid=4277&rid=2383403

[wittend]

I am experimenting with StickOs on a UBW32. It is great! Really quick and intuitive for quick turnaround.

I have a couple of questions:

I have saved four small routines. When I try to save one more, I get a message "out of storage".
If I use the command "memory" I get:
0% ram code bytes used
0% flash code bytes used
0% ram variable bytes used
0% flash parameter bytes used
0% variables used
(this is after a clear flash and a reset)

I understand that this is very beta code on the UBW32, but I'm wondering if there is a limit of four names in the 'directory' and also how one deletes an entry.

Thanks,

Dave Witten

[rtestardi]

Hi David,

We have a ton of unused flash on the PIC32, but for now, I have not tuned the number of files in the filesystem to be larger on that than on the other processors. So you can only save 4 programs. After that you have to use the "purge" command to delete one or more of them. You can use the "dir" command" to see what you have saved, and the "load" and "save" commands with filenames to access the flash filesystem.

Note that by default, the "save' command, without a filename, saves to the default/current program. When you add a filename, it also gets copied to the filesystem, from where you can "load" it later. You never actually need to use a filename on the "save" command, unless you want to maintain multiple programs in flash and switch between them.

In the next release (end of next week?) I'll at least increase the number to 8 for PIC32. Hopefully I'll also get in USB host mode (data logging to USB memory sticks) and the SPI SD card interface (also for data logging).

-- Rich
_________________
Embedded Systems Made Easy: http://www.cpustick.com

[rtestardi]

I'll add one more clarification... The "memory" command does not reflect the filesystem usage, only the "current program" usage -- of flash, RAM, etc.

StickOS does a bunch of magic behind the scenes to eliminate unnecessary flash writes... When you are editing the current program, edits are staged first to RAM until you say "save". Then RAM and flash lines are merged and rewritten to flash, again as the "current program".

If you also add a filename after the "save" command, we make a copy of the current program and save it in the filesystem so you can load it later.

The implications of program edits initially being committed to RAM, and then being written to flash on explicit "save" are twofold:

1. if you lose power after making edits and before saying "save" (or "renumber"), you lose your edits, and
2. if you *want* to lose your edits, you can say "undo" and the program reverts back to its last saved state (i.e., we throw away the RAM edits).

-- Rich


-- Rich
_________________
Embedded Systems Made Easy: http://www.cpustick.com