Converting ASM to C tool?

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?

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 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.