Converting ASM to C tool?

www.microapl.co.uk/index.html

"It is a long and tedious process it seems to make sure they are identical and function identically."

Would it not be simpler, then, to just keep it as assembler and call it from 'C'...?

I've really just started to apply the C version of it because for me I like being able to look at it and since I'm going to be using a .net app to read data streams from the 8051, so that will help me keep the code dare I say "clean" between the two apps. I'm using an 89S8252 to make the job cleaner. Some of the asm is very specific to my MPU project that has various "modules" both wireless and serial.

I saw the C to asm that keil supplies, but does someone have a snippet of code that can show the execution of a C call to asm function.....I'm a little hazy.

So I guess I'm being a bit lazy to not want to go and recode the whole mess. My C is rusty since I haven't used it in 10 years since I was a Cherry Semiconductor and with everything else going on......well you know......;)

You are going to interface your embedded system with a .NET application, and you think you should punish the little embedded guy by forcing it to be programmed just as if it was a PC? May I remind you that this is a 8051 thread and not an ARM thread?

You normally don't write in assembler unless you have to, because of longer development times and higher maintenance costs. Are you sure that the original reasons for choosing assembler instead of C are not still valid?

To call assembly from C, you simply use the normal C syntax for a function call. This assumes, of course, that the assembly function was written using the C calling conventions.

If not, there's no way to call the function, because it wasn't designed to be callable from C. (You could hack some special cases such as void (void), or try to inline the call setup and hope the code generator doesn't interfere, but why?) If the assembly doesn't conform to Keil C calling conventions and isn't structured, then it will be hard for a tool to convert to C to any good effect. (It won't help to create a C program that simply apes the assembler line-by-line; if the tool cannot extract higher level control structures and meaningful identifiers, then the code won't get any more readable, and might be less.)

I'm sure, my 8051 is monitoring things like ADC temp IC's, voltage metering, and transmitting serial data to wireless modules. I intend to have .net front end that can call the flash routine so that if the user wants to have some control over the 8051 like can't C to F or whatever, that the .net app can read the serial stream and give the user some feedback. I am also toying with labview to have similiar results. There is more than one 8051 in the system so I've dedicated certain 51's for task specific functions.

But again most of the asm is already written, I just want to convert it to C since it would be easier for me to read than retrace all my steps. I also have a partner I'm bringing in on the project and is fairly good with C vs. asm...so if I can unify both sides of the equation, it just makes life a bit easier.

Does that make sense?

Did you write the assembler part?

Why did you write in assembler in the first place, if you don't have space or timing requirements to use assembler?

I wrote it in assembly because the design I used was mirrored from a fully functional smart chip semicoductor control system. My buddy gave me the schematics of the design and the rom files. He wrote the handlers and system constructs for the machine and he have me the source code so I could learn the system.

I used that baseline in asm to write my older code. They didn't use C on that design, so I had no reason to write in such. That was in 1992. I've recently pulled this system from the ashes since it has a new goal for a project that someone has asked me to get off the ground. Just trying to make life a bit easier......and I don't think I even knew about Keil back in the day.

Seems like I'm going backwards, but it will pay off in the long run, so hence the push for me to rewrite my functional existing code to something I'm alot more comfortable with.

"I'm using an 89S8252 to make the job cleaner."

What do you mean by that - in what way, "cleaner"?
"Cleaner" than what?

"Some of the asm is very specific to my MPU project"

That is in the very nature of embedded systems - it will be no different if you you 'C' instead of assembler!

"does someone have a snippet of code that can show the execution of a C call to asm function"

Just look at the assembler generated by the compiler!
Either use the SRC option to have the compiler produce an assembly output, or just step through it in the simulator!

"My C is rusty..."

So what language will you be using for your .NET application...?

"I intend to have .net front end that can call the flash routine"

No, you can't call 8051 functions remotely!

You need to provide a command/control interface - the PC sends a command, the 8051 does the necessaries, then the 8051 returns its response.

"like can't C to F or whatever"

Pardon??

" the .net app can read the serial stream and give the user some feedback"

This must be the key to it:

As far as the .NET app is concerned, it is just talking to a serial stream - it sends command to it, and receives responses from it in accordance with your interface specification.
There is no need for the .NET app to have any knowledge whatsoever of how the remote unit is implemented - whether it's an 8051, another PC, written in 'C', or assembler, or whatever.

Similarly, the 8051 just receives commands on its serial stream, acts accordingly, and sends its response(s).
Again, there is no need for the 8051 to have any knowledge whatsoever of how the remote unit is implemented - whether it's a PC, another 8051, or whatever.