simulavr-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Simulavr-devel] OSX compilation


From: Jakob Schwendner
Subject: Re: [Simulavr-devel] OSX compilation
Date: Wed, 27 Apr 2005 10:39:37 +1000

Klaus,

thanks for your respone. First, I had to change my email address, hope
this doesn't cause any confusion.
I finally got everything to compile properly. I even got the .so to
compile (changed the -shared to '-flat_namespace -single_module
-dynamiclib -undefined suppress').
For the programm I want to simulate I still get an invalid
instruction. However, it seems to get some of the code right:

     5000 flyer.elf 0x023c: bufferIsNotFull+0x4            CPU-waitstate
     5250 flyer.elf 0x023c: bufferIsNotFull+0x4            CPU-waitstate
     5500 flyer.elf 0x023c: bufferIsNotFull+0x4            CPI R24,
0x51 SREG=[--HS-N-C]
     5750 flyer.elf 0x023e: bufferIsNotFull+0x5            STD Z, R1 R1=0x00 
     6000 flyer.elf 0x0240: bufferIsNotFull+0x6            CPU-waitstate
     6250 flyer.elf 0x0240: bufferIsNotFull+0x6            ST Z+, R24
R0=0x00 R30=0x01 Z=0x0001 R31=0x00 Z=0x0001
     6500 flyer.elf 0x0242: bufferIsNotFull+0x7            CPU-waitstate
     6750 flyer.elf 0x0242: bufferIsNotFull+0x7            OR R1, R7
R1=0x00 SREG=[--H---ZC]
     7000 flyer.elf 0x0244: bufferIsNotFull+0x8            CPI R16,
0x97 SREG=[--H----C]
     7250 flyer.elf 0x0246: bufferIsNotFull+0x9            SBC R15, R4
R15=0xff SREG=[--HS-N-C]
     7500 flyer.elf 0x0248: bufferIsNotFull+0xa            SBCI R30,
0x10 R30=0xf0 Z=0x00f0 SREG=[---S-N-C]
     7750 flyer.elf 0x024a: bufferIsNotFull+0xb            RJMP fffff64e 
     8000 flyer.elf 0xf64e: ,__data_end,_edata,__data_start+0xdf81 CPU-waitstate
     8250 flyer.elf 0xf64e: ,__data_end,_edata,__data_start+0xdf81
Invalid Instruction!

bufferIsNotFull is from the avrlib.

I tried changing the byte order in flash.cpp as you suggested, but
couldn't get any result there. I did the following:
    opcode=((MemPtr[addr])>>8)+((MemPtr[addr]&0xff)<<8);
changed to
    opcode=MemPtr[addr];

after compilation the simulator wouldn't accept any code.
I also tried to write a very simple programm:
int main(void)
{
   int a =0;
   while(1) {
      a++;
    }
   return 0;
}

compiled it. And that one didn't actually throw any errors, but left
the simulator running as it should.
I know my other programm is running fine, as it is running on an
actual atmega128. Anything I need to be aware of when compiling the
elfs?

Just at the side: How fast will the simulator run? can it perform
real-time? Where can I hook into the simulation? Don't want to use tcl
or any of the like. Would prefer to actually use the shared library in
an objective-c application. The things I need to do are:
- uart in and out
- i/o pins out
- pwm out

any way of doing this higher-order, rather than getting/setting pin values?

thanks heaps,

Jakob

> > Hi,
> >
> > I am currently trying to get simulavrxx to work on OS X 10.3.9. I have
> > read the thread on this subject earlier in this group, but it seemed to
> have
> > died without a resolution.
> > After altering the generated makefiles to manually point to libiberty and
> > the tcl stuff, the compilation went quite far and only stop at the
> > generation of simulavr.so. This is because the osx gcc doesn't know about
> the
> > -shared flag as I learned. I understand that for a shared librarary to
> work you
> > need to set some no-commons flag. Tryed that, but no joy.
> > However, I noticed that even without the .so file it actually creates a
> > simulavr executable which seems to start. It doesn't seem to accept any
> elf
> > files though (I tried the .elf files generated by avr-binutils) (says
> > something like illegal opcode found).
> > Anything you guys could help me with?
> 
> Seems to be no problem. As noticed in an also older discussion
> there is a need to detect the endianess of the host system.
> This macro whcih should be run from configure script must provide
> a macro for the compiler which can be tested and generate some
> lines of special code.
> 
> As I know Bill has started with the macro integration. After the macro
> is usable from the code I will prepare the lines in flash.cpp
> for that purpose.
> 
> If you have fun on this topic you could spend some minutes and dig into
> flash.cpp yourself. There you will find some lines where code is
> read from the libbfd and putted into the "internal avr memory". There
> are some lines (sorry, no sourcecode actually present to me)
> where low/high byte are swapped. If you remove this byte swapping
> you should be able to use the simualtor.
> 
> Please answer this mail if you tried this! All discussions stopped at the
> point where Bill and I have started to solve the problems but nobody
> tests the changes so we dropped them.
> 
> Thanks for your help!
> 
> Klaus
>




reply via email to

[Prev in Thread] Current Thread [Next in Thread]