Anyone know how to get 20 bit immediate in gcc extended asm?
ie.
__asm__ __volatile__ ("movx.a %1,%0":"=m" (DMA0SA):"i" (0xefefeUL));
which unfortunately generates...
__asm__ __volatile__ ("movx.a %1,%0":"=m" (DMA0SA):"i" (0xefefeUL));
3b12: 00 18 f2 40 fe fe d2 01 movx.a #65278,
&0x001d2;#0x0fefe
Can the msp430X instruction set even access a 20 bit immediate field?
Or do I have to initialize a long in memory first then load it using movx.a?
eric
On Wed, Apr 13, 2011 at 12:23 PM, JMGross <msp...@grossibaer.de> wrote:
>
> ----- 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
> Mspgcc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
>
--
Eric B. Decker
Senior (over 50 :-) Researcher
------------------------------------------------------------------------------
Benefiting from Server Virtualization: Beyond Initial Workload
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve
application availability and disaster protection. Learn more about boosting
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
