uniarch mspgcc does not support 20-bit operations, including
generation of immediate values. You can fake it by putting a constant
into the output template, but not a variable. Use -S to see what's
really generated.
Something like the following might work; it could certainly be improved.
#include <msp430.h>
void f (unsigned long addr)
{
unsigned int v1 = 0xF000 & (addr >> 4);
unsigned int v2 = 0xFFFF & addr;
__asm__ (
"mov %1, r14\n"
"rlam.a #4, r14\n"
"bisx.a %2, r14\n"
"movx.a r14, %0"
: "=m" (DMA0SA)
: "m" (v1), "m" (v2));
}
On Thu, Apr 14, 2011 at 5:25 PM, Eric Decker <cire...@gmail.com> wrote:
> 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
>
>
------------------------------------------------------------------------------
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
