linking imagecraft compiler with assember file

Hi,

I am using the IMAGECRAFT compiler to program the ATMEGA16 device. I'm trying to write a PC program, using Delphi, to make a monitor that will be able to manipulate SRAM memory on the ATMEGA16 device. The PC is connected via RS232 to the Device.

For example: Command entered on the PC : D 0060 10 Meaning: Display 10H Bytes starting from SRAM address 0060H The PC part of the Job is working 'fine'. The IMAGECRAFT ANSI C program running on the device is receiving the command and should start with the Display task.

Here i am stuck.

I can't find an ANSI C instruction that reads out SRAM locations.

I think the way to go is, from the ANSI C program calling an Assembler procedure, with Address 0060 has a parameter, let the assembler procedure load the byte located at address 0060, and pass it back the the ANSI C Program who will send the SRAM-data to the PC application.

Can someone help me with indications on how to interface, and link, the IMAGRCRAFT Compiler with Assembler files?

Or, other suggestions to solve my software problem are verry welcome. Kind regards, Fabrizio,

Reply to
fabrizio
Loading thread data ...

It's inherent in the language, although necessarily non-portable.

Try not a variation on:

void DisplayByte(unsigned char); // magic user function

... unsigned char *pByte; unsigned char i; ...

for (i = 0, pByte = (unsigned char *)0x0060; i < 0x10; ++i) { DisplayByte(*(pByte + i)); }

Non-portable, of course, but what's being done is non-portable as well.

It's not really needed in this application but see the help files under "Assembly Interface and Calling Conventions". Just add the .s file to the project.

--
Rich Webb   Norfolk, VA
Reply to
Rich Webb

Thanks for reply, I tested your suggestion and it work's. You are good.

Here is what i made out of it:

What you have to know upfront, is that in the ATMEGA16 device i declared and Cmd_Buffer array where the Command coming from the PC is stored has consecutive bytes. Cmd_Buffer_Poi points to the individual bytes in this array.

Example

------- Command entered on PC : D 09A0 5 Meaning: Display 5 bytes starting from SRAM location '09A0' Cmd_Buffer in Device looks like: 00,09,A0,05 Meaning: 00 Internal Code identifying Display Action 09 High byte of Address A0 Low byte of Address 05 Number of Bytes to Display

Procedure Handle_Display_SRAM is enterred with Cmd_Buffer_Poi poiting to the first '00', the Internal Code identifying Display Action

void Handle_Display_Sram(void) /* Handle the Display of SRAM data */ { unsigned int Address; unsigned char Length, i; unsigned char *Pbyte; Cmd_Buffer_Poi++; /* Point to high byte Address */ /* Find address out of Cmd_Buffer */ Address = *Cmd_Buffer_Poi 09A4 PERFECT !!!!

The Key statement is --> Pbyte = (unsigned char *)Address

Reply to
fabrizio
[snip...snip...]

The assignment operator "=" does an implied cast of the result of the right-hand-side to the type of the left-hand-side, so you are correct that the explicit cast is not required. Given the definition

unsigned char *pByte;

the expression

pByte = 0x0060;

will do what's expected by setting the value of the pointer variable to be 0x0060. The compiler should, however, emit a diagnostic complaining about assigning an integer type to a pointer.

Note also that being promiscuous with regard to pointers and integers is very much implementation specific. Usually C compilers that are targeted at embedded processors will do the right thing.

Including an explicit cast as in

pByte = (unsigned char *)0x0060;

will suppress the diagnostic from the compiler. More importantly, though, it serves as a flag to the maintenance programmer (possibly yourself in a few months) that what was written is what was intended.

--
Rich Webb   Norfolk, VA
Reply to
Rich Webb

BTW there is an excellent listserver at imagecraft which gives fastest possible support.

Rene

--
Ing.Buero R.Tschaggelar - http://www.ibrtses.com
& commercial newsgroups - http://www.talkto.net
Reply to
Rene Tschaggelar

Ok, Thanks for your comments.

Fabrizio,

Reply to
fabrizio

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.