Chris Liechti wrote:
Steven Johnson wrote:
It seems this project has made a rod for its back by identifying all
of the individual processor variants by number, rather than family.
Just how does binutils care if the MSP430 is an FG439 or a F1101 or
whatever, flash based or mask rom based. For that matter, why does
GCC or any other tool (maybe with the exception of the debugger
interface) care. [And the debugger is only a supposition because
knowledge about the interface is not public, but I would expect even
there, there are families. Every individual chip isnt going to be
different??]
yes, it is different, each has different Flash and RAM size, other
peripherals.
with gcc you only need to specify the cpu type on the command line
while compiling/linking and your program has the right peripherals
available.
i never include e.g. msp430x14x.h or something. io.h takes care of
everything and it can't happen that i use some peripheral that isn't
implemented on my target.
i also happen to write code that runs on different MCUs (e.g. when i
use a larger for deveopment work and a smaller for production). then i
need to use #ifdefs and only initialize the peripherals that are
actualy there.
Isnt that what i said? The differences are memory arrangement and
peripheral mix?
The only place it matters as far as I can tell is the script you pass
to the linker to set up the memory map correctly, and the include
files you use to define your peripherals.
and: with or without hardware multiplier.
Conceeded. I knew about this, but it isnt a binutils issue, because
binutils doesnt generate code. It is only a gcc issue which can choose
to use the hardware multiplier (if available) or not (whether available
or not). GNU assembler does not create code, it converts what you write,
and so doesnt know anything about hardware multipliers.
If this is the case, what is the point in specifying every model of
MSP430, when at a binary level they are all the same. The base
registers are the same. The instruction set is the same. Where the
vectors are is the same.
and here youre wrong. the interrupt vectors are different (compare 13x
and 12x) some basic peripheral registers are different (compare USART0
of 13x and 12x)
the 4x device have a whole set of different peripherals, starting with
a different clock system.
What I said was where the vectors are is the same, not what each vector
is. The vectors are always at the top of the memory map. Obviously if
the peripheral mix changes, each vectors use might change (with the
exception of the reset vector). The clocking system is just another
peripheral.
> Binutils doesnt care about the memory map.
the linker is part of binutils and the linker scripts contain the
memory map (for flash/ram/infomem etc sections). there are in the
binutils distribution.
And the linker script is a seperate file, that does not have to be
distributed with binutils. It is distinct from ld. I have never used a
standard linker script, they have always required modification to suit
my needs. Further ld doesnt care what the linker script says (provided
its syntax is correct ).
If GCC and Binutils only knew about the "MSP430" (being the only
architecture member i know of in the family). Life would appear to
be simpler and all this incessant patching the name tables in
binutils and GCC to keep up with the rapidly diversifying range of
peripherals available on the one architecture would cease.
well, if you dont like the features (automatialy the right include for
your msp, the ability to use ifdefs for different targets) then you're
free to use msp1 or msp2 as -mmcu=XX option. thge difference is that
the first one is without, the second with HW mutilpier.
As i said, I agree this is an architectural difference, but only with
respect to GCC and its automatic use of a peripheral. The hardware unit
is a peripheral, it does not add any instructions to the MSP430, so i
stand by what i said there is only one MSP430 architecture.
In the non everything in one chip world, GCC does not have variants for
every CPU board in existence, with their peripheral and memory map
peculiarities for every distinct design mapped out. if automatic things
is what you want, all it requires is a -DMSP430F419 (not literally but
for the point of illistration) for all of the things you pointed out to
work. On the side of GCC, all you need is the msp1 and msp2
distinctions to have the compiler automatically use that peripheral.
And if you have a project that runs on different chips with different
peripherals, how do you get on when USART 0 disappears, sounds like a
different program to me, even if it is based on the same code. And if
you are talking about flash/ram variants where the peripherals are the
same then that is a link script issue and nothing more.
In fact I use the MSP430 GNU tools in the way you state, with -msp1 and
-msp2 and can see no rational reason to do it any other way. Which is
why i queried the necessity of it. Im still not convinced. But im not
trying to convince you otherwise, im suer it has its uses the way it is
now. It is worth the discussion however, because the question: "what
about the MSP430F9876" (or whatever) pops up regularily. It seems a lot
of people dont understand that if MSP430F9876 is not supported as an
mcpu option, it doesnt really matter in any meaningful way. Because
neither GCC not Binutils really care what an MSP430F9876 is.
Steven
