In article <608b6569.0408151919.52735af6@posting.google.com>, 
larwe@larwe.com says...
> Hi!
> 
> > I suggest you look at the MSP430F16xx series. Pin compatible (Ti did 
> > well here) and includes reset/BOR circuitry as well as DMA channels and 
> 
> Hmm, interesting info - thanks. I'll grab the datasheets for these
> parts.
> 
> > popular compilers by a very large margin. Crossworks is probably the 
> > most efficient, and has a USB downloader, but you've already mentioned 
> > that as too expensive off home brew. Quadravox and Imagecraft offer a 
> 
> The nice folks at Rowley have given me some assistance on that front,
> and my Olimex shipment arrived yesterday (from sparkfun.com in CO;
> great turnaround time). I've started playing with it, familiarizing
> myself basically. The Crossworks IDE is rather "busy" - I'm still
> getting used to all the buttons and widgets. BTW I can't wait for
> their Linux version to come out...
> 
> The reason I want to use C is that the algorithms I've written are
> already in C, and should be fairly portable. The MSP430 is not being
> called upon to do any significant navigation, BTW; that's handled by
> the 32-bit controller. MSP is doing the grunt work.
> 

I used the same approach.  The MSP430F149 became an excellent real-time
clock and real-time data collection  engine (with an external 16-bit 
adc).  An Atmel ARM chip did the FP math and handled the user interface.

I used the Imagecraft C compiler from early Beta.  There were some
small glitches---addressed with excellent response times in every
case.  There still may be some  optimization issues---but none
serious enough that I feel I should recompile code that has
been working well for a year now.

My next app will be a little less demanding in the user interface
department, and I plan to put it all in the MSP430.  At this point,
I've worked through the oddities of the MSP430 to the point that
I really look forward to this project.

BTW,  I did use an external reset generator, and it DID add
signifcantly to the sleep mode current.  But then so did
all the various voltage regulators the ARM chip and the 
flash memory.

Mark Borgerson

Hi!

> I suggest you look at the MSP430F16xx series. Pin compatible (Ti did 
> well here) and includes reset/BOR circuitry as well as DMA channels and 

Hmm, interesting info - thanks. I'll grab the datasheets for these
parts.

> popular compilers by a very large margin. Crossworks is probably the 
> most efficient, and has a USB downloader, but you've already mentioned 
> that as too expensive off home brew. Quadravox and Imagecraft offer a 

The nice folks at Rowley have given me some assistance on that front,
and my Olimex shipment arrived yesterday (from sparkfun.com in CO;
great turnaround time). I've started playing with it, familiarizing
myself basically. The Crossworks IDE is rather "busy" - I'm still
getting used to all the buttons and widgets. BTW I can't wait for
their Linux version to come out...

The reason I want to use C is that the algorithms I've written are
already in C, and should be fairly portable. The MSP430 is not being
called upon to do any significant navigation, BTW; that's handled by
the 32-bit controller. MSP is doing the grunt work.

Lewin Edwards wrote:
> Hi all,
> 
> Spin time... I've tested out enough of my sub electronics to be able to
> start optimizing. I'm contemplating the MSP430F149 or F135 as a
> candidate to replace a few 8-bit micros [that are currently way
> under-utilized anyway]. This is a dual-purpose project; saving power and
> also learning the MSP430 as I will be using it extensively in the coming
> years at work.

I'd skip these first generation flash parts. A lot of early MSP430 parts 
have a problem with their POR function. Supposedly the POR will operate 
at 0.4V. The problem is that even low value ceramic caps used for 
decoupling will hold the supply voltage at around 0.8V once power is 
removed, causing the micro to latch. If you don't care about current 
consumption this can be got around simply with a bleed resistor, other 
wise you need some type of external reset circuit. Most of these draw 
more current than the micro in low power applications.

I suggest you look at the MSP430F16xx series. Pin compatible (Ti did 
well here) and includes reset/BOR circuitry as well as DMA channels and 
a pair of 12 bit DACs. RAM sizes up to 10k. If you're doing navigation 
I'd select a version with the hardware multiplier, it makes a big 
difference.

> 
> However, at home I would like to work with "free" tools; mspgcc and
> preferably a homebrew or low-cost JTAG dongle like Olimex's. Any
> comments on the Olimex wiggler? How about their F149 breadboard? They're
> so cheap that I've ordered one of each to play with, but I'd like to
> know if there is any known flakiness.

 From what I see in the MSP430 yahoo group mspgcc has a fairly loyal 
band of followers, but it would seem to be the least efficient of the 
popular compilers by a very large margin. Crossworks is probably the 
most efficient, and has a USB downloader, but you've already mentioned 
that as too expensive off home brew. Quadravox and Imagecraft offer a 
good compromise, Imagecraft is the cheapest, but, purely from other 
peoples posts, again doesn't seem quite as good at optimisation as 
quadravox or crossworks, although I understand Richard is working on a 
new optimiser.  Quadravox offer better support (in my personal 
experience) than is reasonable to expect, so, at this precise point in 
time would be my personal choice for a home brew compiler if 
optimisation wasn't a big issue.

But there's always assembler, a joy to behold on the MSP430. My own 
navigation systems are written entirely in assembler on a 149, it is 
incredible just how much work the thing will handle.

Al

> What's mspgcc like? I know about IAR Kickstart, but 2K isn't enough, and
> anyway, where I work we're also in the process of ditching all IAR tools
> (including their MSP430 toolchain) due to bugs, poor support and crazy
> pricing.
> 
> Also, how reliable is the whole gcc toolchain running under Linux? (I'm
> thinking in particular the JTAG flashing here).

Lewin A.R.W. Edwards wrote:

>> Never mind the spin Lewin. Is it not time for an update (either here or
>> the E-2 pages of your website.
> 
> Yeah, yeah, yeah, I know ;) Proof of my laziness is that I didn't even
> update the site yet to reflect the fact that the book is finished and
> available for pre-order on amazon (but I wouldn't advise anyone to
> pre-order it anyway - last time around the ASIN changed between
> preorder and release time, and preorders got canceled).

I wasn't implying laziness on your part (being too busy maybe but never 
lazy) ;>
 
>>         * How did it work out with the camcorder synchronisation
>>         * Have you now an overall block schematyic for the sub
>>         * Have you progressed the missile launch capability
>>         * Do we really have to wait for the book ;>
> 
> The book won't answer all of these questions; the camcorder module
> isn't in there, for example. The book isn't really "the sub", because
> I didn't have time to solve all the mechanical problems (and they're
> beyond the book's scope anyway). The book talks about how I lashed
> together some of the realtime modules and bolted them onto a
> Linux-based x86 SBC, and it also goes into some theory and talks about
> other topics such as encryption and very simple machine vision
> concepts (and example V4L code).

So we will wait the web-site updates then.
 
[%X]

> Anyway, to summarize a few points of interest:
> 
> 1. The problem of sealing rotating shaft egress points is extremely
> difficult for a vehicle the size of E-2. Partly, the small motors
> don't have the torque to overcome the friction in a suitable stuffing
> gland, but mostly it's just much easier as you make the vessel bigger,
> because you have more time to respond to leaks. My best thinking right
> now is to move to hydraulics throughout. (Yes I know people here
> advised this a long time ago. Some mistakes you just have to make on
> your own). I'm still researching what's involved here. It's a total
> pain in the ass to work with these mechanical components because (this
> is my firm belief) no two tubular items in the entire universe have
> the same pipe diameter or threading. The cheap hydraulic pistons,
> power units and motors are also quite large and cumbersome.

You could probably run a magnetic coupling through a stainless steel sheet. 
The sheet keeps the water out but allows magnetic force lines to penetrate 
and drag round the coupled shaft. I wil explain in more detail privately if 
you wish.
 
> 2. I now have a very good idea of exactly how much processing power I
> need to do all the things I want to do. I've tested the algorithms in
> vitro on the x86 SBC and am ready to scale them down to a real
> embedded platform. (Yes, I now have several 486, Geode and Via C3 SBCs
> for sale ;) It will still be a small tribe of micros, but the tribe
> only has three members (compared to the fourteen micros in the older
> design): processing unit, control unit and energy module. The
> processing unit does image processing and some other math-intensive
> tasks. The control unit (where I'm considering the MSP430) does
> navigation and sequences the other units. The energy module combines
> what used to be the energy module and recovery modules in the old
> design - it handles acoustic and optical beacon, emergency recovery
> procedures, and charge monitoring.
> 
> The camcorder module is actually an accessory. It goes in the payload
> bay, optionally. I have an encoder that works pretty well on a regular
> audio tape recorder but I'm fighting AGC on the camcorder, kind of
> laid that aside for a bit.
> 
> 3. I moved house and now have a lot more space to work in, but still
> no convenient space for heavy tasks such as welding.
> 
> Oh, and:
> 
> 4. I'm taking a bit of a rest and trying to spend more time with my
> wife for a while, as we have hardly seen each other in months (it
> feels like).

Sounds like sokme serious "away from the sub" time coming up. 
 
> I can't get used to not having deadlines beating on me when I get
> home... weird feeling. Doubtless it will change soon enough, though.

Thanks for the update anyway. Sounds like things are moving on quite nicely.

-- 
********************************************************************
Paul E. Bennett ....................<email://peb@a...>
Forth based HIDECS Consultancy .....<http://www.amleth.demon.co.uk/>
Mob: +44 (0)7811-639972 .........NOW AVAILABLE:- HIDECS COURSE......
Tel: +44 (0)1235-811095 .... see http://www.feabhas.com for details.
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************

Lewin A.R.W. Edwards wrote:


> (this
> is my firm belief) no two tubular items in the entire universe have
> the same pipe diameter or threading. 

That's why they make TIG welders (:

> Never mind the spin Lewin. Is it not time for an update (either here or the 
> E-2 pages of your website. 

Yeah, yeah, yeah, I know ;) Proof of my laziness is that I didn't even
update the site yet to reflect the fact that the book is finished and
available for pre-order on amazon (but I wouldn't advise anyone to
pre-order it anyway - last time around the ASIN changed between
preorder and release time, and preorders got canceled).

>         * How did it work out with the camcorder synchronisation
>         * Have you now an overall block schematyic for the sub
>         * Have you progressed the missile launch capability
>         * Do we really have to wait for the book ;>

The book won't answer all of these questions; the camcorder module
isn't in there, for example. The book isn't really "the sub", because
I didn't have time to solve all the mechanical problems (and they're
beyond the book's scope anyway). The book talks about how I lashed
together some of the realtime modules and bolted them onto a
Linux-based x86 SBC, and it also goes into some theory and talks about
other topics such as encryption and very simple machine vision
concepts (and example V4L code).

The problem is that the book is now a generation behind my current
thinking, and by the time it actually gets PRINTED it will be two
generations behind. I couldn't afford to put the "latest and greatest"
into the book because frankly it is very bleeding-edge and thus
doesn't work very well yet (and as it was, I got the ms to the
publisher almost two months later than the official deadline; only
just lucky enough to squeak by for a 2004 release date). The stuff in
the book all works reliably (I hope - I had a Godawful time with
people testing it all out and getting different results), and it's all
on-topic material. I won't be writing a sequel, though - further
development information will be published on my web site. If or when I
do a third book, it will be on an unrelated or peripherally related
topic.

Anyway, to summarize a few points of interest:

1. The problem of sealing rotating shaft egress points is extremely
difficult for a vehicle the size of E-2. Partly, the small motors
don't have the torque to overcome the friction in a suitable stuffing
gland, but mostly it's just much easier as you make the vessel bigger,
because you have more time to respond to leaks. My best thinking right
now is to move to hydraulics throughout. (Yes I know people here
advised this a long time ago. Some mistakes you just have to make on
your own). I'm still researching what's involved here. It's a total
pain in the ass to work with these mechanical components because (this
is my firm belief) no two tubular items in the entire universe have
the same pipe diameter or threading. The cheap hydraulic pistons,
power units and motors are also quite large and cumbersome.

2. I now have a very good idea of exactly how much processing power I
need to do all the things I want to do. I've tested the algorithms in
vitro on the x86 SBC and am ready to scale them down to a real
embedded platform. (Yes, I now have several 486, Geode and Via C3 SBCs
for sale ;) It will still be a small tribe of micros, but the tribe
only has three members (compared to the fourteen micros in the older
design): processing unit, control unit and energy module. The
processing unit does image processing and some other math-intensive
tasks. The control unit (where I'm considering the MSP430) does
navigation and sequences the other units. The energy module combines
what used to be the energy module and recovery modules in the old
design - it handles acoustic and optical beacon, emergency recovery
procedures, and charge monitoring.

The camcorder module is actually an accessory. It goes in the payload
bay, optionally. I have an encoder that works pretty well on a regular
audio tape recorder but I'm fighting AGC on the camcorder, kind of
laid that aside for a bit.

3. I moved house and now have a lot more space to work in, but still
no convenient space for heavy tasks such as welding.

Oh, and:

4. I'm taking a bit of a rest and trying to spend more time with my
wife for a while, as we have hardly seen each other in months (it
feels like).

I can't get used to not having deadlines beating on me when I get
home... weird feeling. Doubtless it will change soon enough, though.

Lewin Edwards wrote:

> Hi all,
> 
> Spin time


Never mind the spin Lewin. Is it not time for an update (either here or the 
E-2 pages of your website. 

        * How did it work out with the camcorder synchronisation
        * Have you now an overall block schematyic for the sub
        * Have you progressed the missile launch capability
        * Do we really have to wait for the book ;>

-- 
********************************************************************
Paul E. Bennett ....................<email://peb@a...>
Forth based HIDECS Consultancy .....<http://www.amleth.demon.co.uk/>
Mob: +44 (0)7811-639972 .........NOW AVAILABLE:- HIDECS COURSE......
Tel: +44 (0)1235-811095 .... see http://www.feabhas.com for details.
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************

Hi Alf,

>     How's tricks?

I haven't turned any recently :)

Finally I have all the contract work, writing, proofreading and
miscellaneous other responsibilities out of the way. For the first
time in more than a year, I'm a free man and can do some aimless
personal projects again. I'm sure someone will soon come along with a
project that's just too tempting to refuse, but in the meantime I'm
playing with the MSP!

> The Olimex F149 header boards are pretty good.  I've designed boards with a
> dual pad-out to take either the processor or the Olimex breadboard.  Down
> here in Australia, the boards had a shorter lead time!!!

That's pretty crazy. I think I'll order a waffle once I start
prototyping, just in case. For now I have 3 samples on order from TI,
and another 5 pieces from Digi-Key.

> robust, I used the demo for a while.  It's not as efficient time and memory
> footprint wise as the IAR compiler, but I've heard that both of them are
> streets (20%-30%) ahead of mspgcc.  This may be old information though.

I don't doubt that. I'm not going to be pushing the envelope with this
chip, though. I need to read two ADXL202s (currently I do that the
digital way, but I guess I could do it analogishly if I had to), some
temp sensors (currently those are analog but could go to I2C),
pressure sensors (analog), a GPS and a couple of other miscellaneous
things. The MSP won't break a sweat even using a suboptimal compiler.

Plus two reversible PWM motor outputs and two 4-pole stepper drives.
However it looks like these will be replaced by a single output to
switch off/on a hydraulic power unit, and a few solenoid valve
outputs.