----- Ursprüngliche Nachricht -----
Von: Eric Decker
Gesendet am: 13 Apr 2011 15:00:48
> Do you perhaps have a code snipet of access to a 20 bit register? Say
> DMA0SA for example.
> I love working examples.
Not for the DMA. I don't use assembly here as I (yet) never had to deal
with a source or destination above 64k.
But I have something I wrote for accessing upper flash as data storage.
static inline unsigned char FlashReadByte (unsigned long address){
unsigned char result;
unsigned int sr, flash;
__asm__ __volatile__ ("mov r2,%0":"=r"(sr):);
// save SR before disabling IRQ
_DINT();
__asm__ __volatile__ ("movx.a %1,%0":"=r"(flash):"m"(address));
__asm__ __volatile__ ("movx.b @%1, %0":"=r"(result):"r"(flash));
__asm__ __volatile__ ("mov %0,r2"::"r"(sr));
// restore previous SR and IRQ state
return result;
// aligned address -> low-byte contains result
}
>> asm("movx.a %1, %0":"=m"(destination):"m"(source));
> When would one use the
> asm("movx.a %1, %0":"=m"(destination):"m"(source));
> form. I'm confused as to what to put in for destination and source
> and how this can reference 20 bit registers while still obstensibly
> refering to memory locations.
> Or is the above a 20bit memory to memory move? And if destination/source
> are in registers, gcc will
> still do the right thing, doing a 20 bit move. Is that correct?
Yes. Peripheral registers are jsu tmemory locations.
And by using the 'm' qualifier, I tell the compiler to provide the
parameters given in the brackets (normal C symbols) in a memory
location and substitute the placeholders %0 and %1 by the proper
value/symbol and addressing mode. If needed, the compiler will
put the values on stack right before the asm statement and use a #0(SP)
addressing mode or something similar. However, the compiler does not
check nor know whether this addressing mode is available for the instruction.
And sometimes you still have to trick a bit.
In the above
"movx.b @%1, %0":"=r"(result):"r"(flash)
I tell the compiler that I expect the value flash in a register
and then let the compiler put the register name behind the @ for an
indexed access.
And in the following line (from a block copy function)
__asm__ __volatile__ ("movx %0, @%1"::"m"(*source),"r"(flash));
I tell the compiler to provide a memory access to the value source points to.
The compiler generates
302 008a 4018 AF49 movx @r9, @r15
where R9 is the compiler-chosen place for the source pointer (which I
later increment with
__asm__ __volatile__ ("incd %0":"=r"(source):"0"(source));
(the"0" means same operand and type from the first destination is also the
source)
It's rather complex and sometimes irritating, yet really powerful.
> I've read a bit out on the web and that has helped. But I find to
> really learn it requires examples
> which aren't very plentiful in the tinyos msp430 code.
Indeed, the most examples are rather x86 specific and the mspgcc decumentation
is no real help for learnign the msp specific implementation.
>> Yep. in mspgcc, those registers are defined using sfra macro, but this only
>> defines them as volatile unsigned long word. The compilers default action
>> will be a normal 2*16 bit access.
>That is what I'm seeing. If I try to write say DMA0SA (defined using sfra
>as a ulong) it generates a write to the low 16 which behaves
>fine (including a zero of the upper bits) and then a write to the upper
>which doesn't do anything.... (both using simple mov (16 bit)
>instructions).
Yes, the sfra macro is mostly useless for register declarations.
But maybe once the compiler natively supports 20 bit instructions,
teh macro might be altered / extended with an additional qualifier
which tells the compiler to do a 20 bit access instead of 2*16.
maybe for register variables too
But it is a long way to go. Once you use 20 bit registers and 20 bit
data access, you also need to save and restore registers on 20 bit.
Which enlarges the push/pop and complicates many other things
Hence the DINT in the code above. To avoid the ISRs
clearing my upper 4 bits.
>> BTW: the DMA config registers (with the DMA triggers) are 16 bit acess
>> only. The original documentation as well as the TI defines provided _L and
>> _H aliases which didn't work (which was the original reason that
>> brought me to the E2E community.
>I figured that out the hard way. I came up with an algorithm for dealing
>with the differences between the x2 and x5 dma engines but it involved
>referenceing the trigger control words as bytes (which is implied by the
>existence of _L and _H definitions). But it didn't work.
Same for me. That was the reason why I joined the TI E2E community.
Yet nobody there could help me, so I too figured it out myself.
And later they changed the documentation because of my 'discovery'.
Well, now I'm one of the four gurus there and contributor of the year 2010.
With free lifetime supply of all MSP related tools. It was worth the sweat :)
> At least on the 2617 part (x2) anything in the 0x01xx address space MUST be
> referenced using 16 bit references. I'm pretty sure that anything in the 8
> bit I/O area has to be referenced using byte instructions. I'm fairly
> confident about that. But verification would be good.
Yes, the 8 bit I/O is only connected to the lower 8 bit of the data bus,
while the 16 bit I/O has the LSB of the address bus unconnected.
> Does the 5438 behave the same way?
No. It does not have any 8 or 16 bit I/O area anymore.
It depends on the individual module how it is connected to the
address and data bus. Sometimes both things work, sometimes
only 8 or only 16 bit.
e.g. in teh system module, you can write 8 bit to the password part
of the first register and then do 8 or 16 bit accesses to any
module register without password. THen you write a wrong password
and all is locked again. Or you do a direct 16 bit write including the
password.
> Also Jens, what tool chain are you using on the 5438 to access high ROM?
My own functions. Like the one above.
I don't put code there (my projects are way smaller than the 40k flash below
64k, especially if I can put tables above)
I use 64k to 128k as backup space for uploadign new firmware versions
through the existing firmware and their communicaitons channels,
then I copy the complete firmware down to <64k.
The area above 128k is free for data tables and text strings (which
need to be copied down to ram before being used with printf).
Below, I don't use any 430X mode for the compiler.
I modified the linker scripts to provide separate segments in the extended flash
and manually put the table sthere with the segment attribute.
Works fine.
The compiler I use is still the old mspgcc3 (last windows build).
However, for flashing I need to use the (free) elprotronic tool, as msp430-jtag
cannot address the 54xx at all due to the changed jtag protocol.
> My understanding is the differences between the cores (2617 vs. 5438) is in
> instruction timings. The big differences are
> in the way port addressing is done (willy nilly vs. base registers) and
> interrupt mapping. The 5438 makes a bunch more sense.
> And it looks like they moved the I/O space into normal memory so it behaves
> consistently. But I haven't played with it yet.
Yes. The memorty space has been unified and the interrupt handling is more
consistent. Module enabling and interrupt flags have moved into the module
registers and the interrupt vectors have been cleaned up a bit (especially
for the USCI)
> Right now I am testing the unified dma driver I wrote. The driver
> rrently is 16 bit only and will stay that way for the time
> being. Not too much call for DMAing into high ROM. But I got curious
> about how the 20 bit support works.
Same here for my DMA module. Well, perhaps when sending a stored
webpage or image from flash to an SPI display or such...
> All I can say is TI makes damn good h/w, great low power stuff etc. But
> they have always really really really screwed up system architecture. The
> 5438 architecture is much much improved.
Ever worked with a PIC? THAT's s screwed system architecture.
> But this 20 bit stuff with the msp430 isn't doing much to change
> my opinion on the matter.
They wanted it downward compatible as much as possible.
It's always a problem when expanding past 16 bit address bus but wanting
to stay a fast 16 bit processor.
Well, the PICs I used were 14 bit processors :)
> And their documentation.... well.
> TI has always been painfull to use.
It's not that bad, really. I've seen much worse. The problem is that you need
to figure out the modular philosophy behind their document structure.
Once you've gotten used to it, you'll find everything you need. Mostly.
> I been doing
> computers well before there were tiny little computers and used TI stuff
> very early on, like when they first got into computers.
Remember the TI99/4a? I loved to play Tombstone City on it.
> From what I've seen not much has changed.
> But the 5438 looks much improved from previous iterations.
Definitely.
> but the DMA might differ.
perhaps, a bit. But it's great to have DMA at all.
And you can do really nice things with it besides just
shuffling data.
Including auto-reprogramming of comm modules, math
algorithms (with the hardware multiplyier) and other things.
What I'm missing is
1) more DMA channels (3 is not enough for some ideas I have)
2) a way to program the DMA using DMA :)
3) two-step transfers: reading from a 16 bit source and do two
8-bit writes. However, if the 16 bit source can be read in two 8
bit reads (and many can), then this can be done aleady.
4) more possible triggers.
JMGross
------------------------------------------------------------------------------
Forrester Wave Report - Recovery time is now measured in hours and minutes
not days. Key insights are discussed in the 2010 Forrester Wave Report as
part of an in-depth evaluation of disaster recovery service providers.
Forrester found the best-in-class provider in terms of services and vision.
Read this report now! http://p.sf.net/sfu/ibm-webcastpromo
_______________________________________________
Mspgcc-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
