[Top][All Lists]
[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
>