Thanks Jens,
Do you perhaps have a code snipet of access to a 20 bit register? Say
DMA0SA for example.
I love working examples.
more below ...
On Wed, Apr 13, 2011 at 4:00 AM, JMGross <[email protected]> wrote:
>
> ----- Ursprüngliche Nachricht -----
> Von: Eric Decker
> Gesendet am: 12 Apr 2011 21:58:58
>
> >> The user's guide states that if you write to DMA0SA using a word
> >> instruction, the upper bits 19-16 will be cleared, so you should be
> >> fine as long as you aren't trying to DMA to/from addresses above 64KB.
>
> > yep read that. I'm explicitly trying to write the full 20 bit register.
> At some point the dma driver could support 20 bit addresses and I'm
> wondering how to do it.
>
> The 20 bit registers need to be written to with a 20 bit instruction such
> as MOVA or MOVX.A (note: there is no MOV.A)
> Source of the MOVA or MOVX.A instruction may be a 32 bit (long) variable as
> long as it is in memory.
> However, the MOVA instruciton may only take one memory operand, the other
> must be a register, so you either move the value to a register and then to
> the destination, or you use MOVX.A instruction. Both ways are same
> resulting size, bu tthe second does not clobber a register.
> The assembly instruction would be
>
> asm("movx.a %1, %0":"=m"(destination):"m"(source));
>
> The two parts behind the instruction tell the compiler to provide the
> source in a memory location (and that the destination is a memory location),
> even if it currently resides in a (or rather two) registers (register
> variable, function parameter). This is necessary, as there is no way to
> concat two registers to a 20 bit value other than writing them to a 32 bit
> memory location and then loading from there.
>
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?
> The GCC inline assembly syntax is really powerful, if you know to use it
> right (which isn't easy)
>
yep. 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.
Be careful that this instruction is not interrupted by a DMA transfer as
> this will corrupt the write. (the RMW disable flag won't work here, as the
> microcode is performing two writes which may not be interrupted)
> (It's in the 54xx errata sheet IIRC)
>
> >> Several of the peripherals on the MSP430 do not accept 8-bit access.
> >> The most recent header update from TI removed the 8-bit sub-register
> >> definitions for TimerA and TimerD[sic] on a couple chips because byte
> >> access did not work. Reference the registers through the
> >> header-defined variables rather than assuming that knowing the address
> >> is all you need.
>
> > Doing that. I'm referencing DMA0SA for example through the TI define.
> And I'm seeing two mov (16 bit) inst generated. the first hits the low
> half of SA and zeros the upper 4 bits. the 2nd mov hits
> > the upper half but does nothing.
>
> 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).
> 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.
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.
Does the 5438 behave the same way?
Also Jens, what tool chain are you using on the 5438 to access high ROM?
>
> > Seems the only way to access the upper part of 20 bit registers is via a
> movx. but I'm not sure about that because I haven't figured out how to
> generate the instruction yet.
>
> MOVA will do as well, but not for memory-to-memory operations. All other
> xxxA instructions do only register to register (but are shorter and faster
> than their yyyX.A counterparts)
>
> > Does anyone have information about the behavior of 20 bit registers.
> and I'm talking about the 2617 processor. although I'm also interested in
> any information about the cc430f5137 and/or the 5438.
>
> My experiences are with the 5438. The CC is same base family and therefore
> mostly identical (I don't think there are differences in the cpu core)
>
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.
> I don't know about the 2617, I think, at least the MSP430X instruciton set
> is identical
Same ISA. Not sure about peripheral behaviour hence the questions. We are
currently using the 2617 but are transitioning to
the 5438. I am also currently trying to integrate the tinyos support
across the three major families (x1: msp430f149/msp430f1611,
x2: msp430f2616-9, x5: cc430f5137, msp430f5438).
Right now I am testing the unified dma driver I wrote. The driver
currently 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.
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. But this 20 bit stuff with the
msp430 isn't doing much to change my opinion on the matter. And their
documentation.... well. TI has always been painfull to use. 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. From what I've
seen not much has changed. But the 5438 looks much improved from previous
iterations.
, but the DMA might differ.
>
> JMGross
>
thanks! really appreciated.
>
>
> ------------------------------------------------------------------------------
> 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
>
--
Eric B. Decker
Senior (over 50 :-) Researcher
------------------------------------------------------------------------------
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
