||3 years ago|
|core||3 years ago|
|ex||3 years ago|
|flib||3 years ago|
|fr2433||3 years ago|
|fr2476||3 years ago|
|g2553||3 years ago|
|README.md||3 years ago|
|terminal||3 years ago|
This stuff is supposed to run on mecrisp forth on MSP430 chips. Mainly the classic MSP430G2553, but I've also experimented with the newer MSP430FR2433 and MSP430FR2476 (there is a Launchpad for both of these).
It is not very well organised, so you'll just need to find your way about it. I've not "deployed" any actual sensor using this, so ... ymmv.
My main concern (because sensors) is power consumption. So some pros and cons.
This is an amazing one. There is a DIP version of this chip, and with
Matthias Koch's venerated
lowpower version of mecrisp it runs prompt
on less than 2uA (requires external 32768 crystal but no caps). The biggest
downside is space: it's got only 16kB of flash (of which 11kB takes mecrisp),
and 512 bytes of RAM (of which about 200 is available for the program). It is
mostly enough for a deployed sensor though (just), but development is a bit
painful (can't really
compiletoram, so lots of flash writes). Also the prompt
is only 9600 baud.
The first con is that it only comes in QFN or smaller packages, so it is a pain to build own boards. But it is very small (physically). The cool feature about this one is FRAM instead of flash - no penalty in writing to it any time. This particular one has 16kB of it, so again only 4.5kB space for programs; but it has 4kB of RAM, which is quite enough for development and testing.
For me the biggest downside of this one is the clock system and the power
consequences. There is an internal REFO 32768Hz clock which kicks in
when there is no external crystal, and consumes 15uA of power come what may.
lpm3 is about 16uA,
lpm4 goes down to 1.5-2uA but only external
interrupts for wakeup.) The external crystal requires caps, and even with it
it is quite a pain to make the MCU use it and switch off REFO. Possible though.
lpm3 pretty nice, just like on g2553. However I couldn't quite
make the prompt lowpower (like on g2553), because I didn't find a way to
make the UART use the external crystal (XT1) for timing. So it gets shut down
lpm3, and while it does wake up on RX, the data is garbled. Maybe
with lower baud rate?
Same as fr2433, except 64kB FRAM (only 32kB is below
$FFFF though, so
mecrisp only actively uses that), and 8 kB RAM. Also REFO only uses 1uA here,
so one can get reasonably low power in
lpm3 without any components - about 3uA.
Comes also in QFP-48 package, so hand solderable.
The main downside here is the price.
More-less like jcw's embello, and the parent dir:
fr2433 directories contain material which is only for the
respective chips - the "high-level" files. Most of the actual "meat" is
flib, and subdirectories:
- MCU specific words in the so-named subdirectories;
drivershas some a bit higher level drivers which should be applicable more generally, as long as the base words are available;
mecrisphas files directly from the mecrisp tarball;
templateshas some files with constants in, and a python script which can then produce constant-free versions (constants are replaced by their values), so as to save a little bit of flash space.
core directory contains mecrisp hex files, to be flashed onto the chip.
-xt1 versions require an external 32768Hz crystal to work.
The subdirectories contain mecrisp sources which produce the ones which
are not part of the standard mecrisp distribution. To build, get a mecrisp
tarball, unpack, and copy these source dirs to
mecrisp-source, go inside,
assemble will build the
hex. This of course requires the
assembler; on Arch Linux the package is
mas in AUR.
(The FR2433 mecrisp actually runs on the FR2476 straight without modifications, but the memory sizes are wrong, and some irq names are wrong.)
Finally, note that there are a lot of
includes in the files. You can use
../scripts/resolve_includes.py to recursively resolve all the
a given file and produce a single file with everything in it.
Power consumption on MSP430G2553
With my minimal g2553 circuit, I was getting 50-500uA consumption, while on a Launchpad, same chip, was doing around 1.5uA. (This is Mecrisp lowpower, with some basic init; btw without the init it was taking about 30uA.)
Turns out it's all about the pins setup. They seem to need to be tied to something, floating really ups the consumption. Just making them all outputs on my bare board got the consumption to the expected 1.5uA. But on my sensor board, I needed to tie them specifically low.