WHY MSP430?
History
The MSP430 family is a microcontroller family which is established
for approx. 10 years. However, the primary usage was in measurement
applications which are battery powered, e.g. intelligent sensors,
with or without LCD-display. Peripherals were included with these
applications in mind. In the beginnings, no UARTs were supported. And
the development tools were not very attractive for those having
smaller target quantities in mind. In short: The MSP430 was a good
choice for OEM´s.
By end of the nineties the MSP430 family and its development tools
have become attractive for a vast range of potential applications and
also for low quantities, since the cost of developent tools has been
lowered dramatically, especially due to the introduction of
JTAG-based programming & debugging in flash-based devices. Alas,
competitors in the low budget range already control these low budget
markets, especially Microchip (PIC) and later Atmel (AVR). Of course,
the oldmobile under the 8-bit controllers, the 8051-family may be
considered a part of these low-budget markets.
Changeover Cons
Given this constellation, it is very difficult for the MSP430 family
to raise its market potential, despite its significant better
properties in all relevant issues. Of course, this is due to present
usage of these competitor products and corresponding development
tools. Further, the time which was spent in learning a new
architecture is considerable (for a quick overview of MSP points of
differences, look at Architectural specifics).
And last but not least, the software pool of these products is
immense. But the fact of common usage of C lowers this as a factor of
keeping "old" products. The only problem is the conversion
of low level peripheral related modules to new modules. This site
will help you to establish such a conversion. See SW-(re)sources.
Changeover Pros
For medium to bigger projects, there is an economical argument
to switch over to MSP430, when current targets are 8051, PIC or AVR.
The creation of software will be less error-prone and provides a
better overview when MSP430 is targeted.
• An example of less susceptibility to software errors: the
16-bit architecture provides single transfer of up to 16 bit memory
or peripheral values to registers and vice versa. This allows for
variable updating in interrupt routines without the need to
temporarily disable interrupts when reading such values in the main
program. Assembler programmers traditionally are aware of this
problem and mostly do not forget to insert di & ei instructions
(or whatever these mnemonics are named). C-programmers however often
forget these pitfalls. They firstly must study the macro names of
their compiler which takes care for these interrupt enables &
disables, and secondly: they must be applied.
• Why a better overview? This is due to the linear memory organization
of the MSP430 architecture. In the past, the Harvard architecture was
praised as being economical because of providing separate address
spaces for code and data. Practically, this limits the comfortability
of maintaining (high-level) programs, especially when more than one
data space is available (PIC: RAM-banks, 8051: internal &
external data memory). This affects maintainability, portability
and reusability of programs & modules. This topic is
extensively explained here. At this point
it should be understood that long term effects are clearly gained
when switching over from 8 bit to 16 bits with linear address space.
Note that many 16 bit processors still have separate code & data spaces.
For the sake of completeness, it should be noted here that several
good architectures exists which support linear memory and good code
utizilation. Bigger projects, especially when program code is beyond
60KB are managed better with e.g.
- ARM family of controllers & cores (industry standard, licensed
by ARM);
- HC12 family of controllers (Motorola, see also HC12WEB-page).
Development kits
The development kits of TI represent a clear argument to changeover
to this controller family. When an entry to any controller right from
the start shall be made, the kits will provide best price/performance
ratio available on the market. More information here.
Hobbyists who consider using these kits should read the tips found here.
Architectural specifics compared to
common micros
• The port registers' direction (in resp. output) are commonly
specified by data direction registers. With MSP430, a "1"
represents an output. Most controllers bypass the port usage
automatically, when an associated peripheral (e.g. UART) is
activated. The MSP430 requires the programmer to specify this
explicitly in a register. By default, all shared port/peripheral pins
are selected to port usage.
• The MSP430 runs on an internal RC-based clock of approx. 800
kHz when started. For many applications, this isn´t precise
enough. A certain sequence of commands must be carried out in order
to select an external crystal clock up to 8 MHz. The sequence of
commands is quite crucial, since a mechanism exists which let the
MSP430 automatically switch back to the internal RC-clock when the
external clock is lacking. An associated error flag must be reset
prior to switching over to the external clock. A recommended sequence
of C-statements is given in the SW-resources page.
Accurate clocks are also possible without HF-Crystals. A simple
32768Hz crystal can be utilized as a time reference. Software can
adjust the RC oscillator in order to achieve a sufficient degree of
accuracy for most applications.
• There is no bit addressabe RAM- or peripheral space, contrary
to 8051, PIC and AVR. This is a matter of getting used with. Those
who want to work with single bits may define bit fields in
structures, which are associated with corresponding peripheral addresses.
However, this lack does not necessarily mean that the MSP is not
effective with bit manipulation. The assembler language supports bit
test instructions which tests bits against a mask (e.g. test if bit7
is set using the mask 0x80). This way also multiple bits can be
tested in one instruction.
• The instruction set has some peculiarities. Any basic
knowledge about this can help optimize designs right from the hardware
design start of a project. Regarding the hardware, one should try to
assign port pins that must be accessible as single bits to bits
0....3 of any port. This will facilitate immediate mode with short
constants, saving machine cycles and code space. The same applies to
software flag bits.
To understand this - and also to better understand the assembler
-, one must consider the addressing scheme of the CPU, which is
described in the MSP430 family user's guide (chapter "RISC
16-Bit CPU").
Each instruction has its opcode packed in the first word, together
with addressing/operand information bits. There exists 7 addressing
modes, but only 2 bits seem to decode this for the source field.
Further, 4 destination addressing modes are selectable. However, only
1 bit seems to decode this. Compare with the scheme for 2-operand
instructions given here (other schemes have longer opcodes):
(S/D-Reg = source/destination register 0...16; As/d = source/dest.
addressing mode; B/W = byte/word)
The crux lies in the register bank decoding for source operand and
destination operand. There are 16 registers, of which 12 are general
purpose. When one of the first four registers are targeted in source
or destination field, another addressing mode is activied. E.g.
Register 0 is the PC (Program Counter). For example, targeting R0
with indirect register autoincrement mode will inherently do
immediate addressing! It is important to realize this: the user
writes assembler with the common notation for immediate addressing
(or the C-compiler does so), but actually an indirect register access
is used.
Another example: when absolute addressing is selected, the
assembler will use indirect indexed register addressing mode with R2.
R2 actually contains the STATUS flags, but in such operation, it will
read as zero, so the final target address simply equals the index.
Then finally an example related to immediate addressing with short
constants. When the assembler sees immediate addressing (for
constant setting, adds/subtracts and bit set/reset masks), with
constants -1, 0, 1, 2, 4 or 8, it will target R2 or R3. Together with
the "As" bit field setting, the appropriate constant is
inserted instead of an extra operand word. This implies that R3
cannot be used as a register for addressing purposes. Of course, the
register exists and it can be modified and read from (as is also the
case with all special purpose registers). Please note that the
machine cycles used for these instructions using short constants is
not explicitly specified in the documentation.
Up to now all but R1 are used as special cases. R1 actually isn't
a special case: R1 is the stack pointer. So indirect or indexed R1
operations facilitate stack relative addressing (which is not listed
as one of the 7 addressing modes in the documentation).
Finally a note to those who are interested in technical details:
indirect register addressing (with or without autoincrement) is
possible only in the source operand. The destination can be targeted
indirectly only via the indexed addressing mode, which will always
"consume" an extra instruction word: The index, mostly 0.
In this case, 0 is not a short constant, because the R2/R3 constant
technique is not subject when another register which actually holds a
pointer value is given as the destination field. |
