Need recomendations on converting C8051 assembler programs to the Propeller.

Capt. Quirk

I have been working on deconstructing a few model airplane BLDC motor programs, written by the same author.
I am doing this because I believe there are details within these programs for dealing with hobby sized BLDC
that industrial app-notes do not provide. I have excellent documentation on the structure of the program and
the trial and error process he used to create the programs. But I am lacking the information on how he used
all his timers that ran his control and error routines.

The 8051 assembly programs were written entirely in caps, so I have edited the program to make it readable, and
I have identified all the timers, control words, constants, variables, main control routines within the program. I am currently
working on the loops within the control routines. But the program is huge, and tracing the loops is tedious and mind numbing.

Is there a normal procedure for converting code to another language? or is this normally a mind numbing task that
a sane man would avoid.

Thanks

Bill M.

Gadgetman

Have you asked the author ifhe can explain the programs?

Unless the program was written in sme sort of higher-level language, it's probably not possible to convert it.

And as one who likes to deconstruct code can say; yes, most of the work really IS mind-numbing.
I start off by taking note of 'special program areas' ( 0066h is one if yo work wih Z80 CPUs as it's used for interrupts.) then look for 'code breaks'. Looking for areas with 0ffh burned io the EPROM(when an EPROM i erased, all bits are set to '1', and it was common to 'pad' code and data with 0ffh (255, or 11111111 in binary) as it didn't need burning into the EPROM. Speeded up the process...
After that, all you can really do, unless you happen to have a logic analyzer is to manually follow the code and see what happens.
Looking for IO commands in the code can give you hints as to what is 'important' and not, though.

Mostly, I suspect that you need to focus on the interrupt sections of the code, as that's where any PWM and similar stuff is likely to happen.

Mike Green

Ditto on Gadgetman's comments. The normal procedure for converting a program written in one assembly language to another different assembly language is: 1) Thoroughly understand how the original program works including hardware specific details like the use of timers, etc. 2) Essentially flowchart or rewrite the original program in an abstract high-level language with as much structure to the language as you can manage. Something Pascal-like or C-like with strong typing would be good. 3) Rewrite the program in the new device's assembly language.

The more you have in terms of original program design documentation, the easier this gets because you're essentially rewriting the original program just using the original as a guide. In general, the new processor will not have the same resources available as the original one, may have a different word size, likely will have a completely different instruction set, etc.

There have been translation programs written that take object code for one processor and translate it into object code for a different processor. Usually these are very very complex and usually work very poorly ... inefficient code produced ... often require a huge amount of hand-work where a person has to review the resulting code line-by-line and make corrections.

Capt. Quirk

Fortunately for me, the author intended the programs to be open-source. So he wrote the assembly program in the style of high level language,
with long descriptive names for all the routines, and sub-routines, variables, and he marked all the code breaks. I also found the ".inc" file, so I
have identified all the reserved words too. Most of the sub-routines are only a few lines each, many of the routines that make the "calls" have only
have about ten lines of code. It is very readable.

But, there is over 450 routines and their subs. I had been worked on a flow chart for about eight hours before I decided to ask for help. I will try and find
where his timers are causing the interrupts, fortunately his flags and the single bit reserved words are easy to recognize. I made a list of all the timers,
special functions, and reserved words. Then I searched the .pdf data sheet, and highlighted all the pages related to my list. I will read about the timers, but
I don't think I will be able to digest that information very well without completing the flow chart first.

He used five timers, a built in comparator, and 3 adc pins. He also said that the chip manufactures put to much emphases on supplying
pins for PWM motor control, when they should be adding more timers. Which I interpreted to be a good fit for the Propeller as a mixture of
Spin and PASM.

So for now I am going to go back and fourth from the flow chart and reading more about the timers, interrupts, comparator, and adc.
Depending on how bored I am with what I am working on. Unless you advise me differently.


Thanks

Sincerely

Bill Mazzacane

Mike Green

You are going to be such an expert on this program and on all the features of the 8051 version used. Keep in mind that you don't just substitute a cog or a cog counter for a timer. It all depends on how the timer is used. Similarly, you can assign a cog to deal with what would have been an interrupt, but that's not always the best solution. It depends on what the interrupt is used for.

localroger

I've done some pretty advanced 8051 .asm though it was many years ago. The 8051 has an incredibly byzantine interrupt system and the way it uses timers will not translate very directly to the Propeller's timers. (For one thing, a primary purpose of the 8051 timers is to generate timed interrupts, and the Propeller doesn't have interrupts -- at all.) There are a lot of things that program is probably doing that would be much, much easier to do with separate cogs or mixed procedural PASM code timed via WAITCNT (since the Prop is so much faster than a 8051). You're going to get nowhere fast trying to map 8051 timer and interrupt operations to low-level Propeller code. You're going to have to completely figure out how the program works, from stem to stern, THEN figure out how to implement its functions in the much different Propeller environment with a mis of PASM cogs, Propeller timer operations, and probably some Spin foreground and startup code.

frank freedman

Capt. Quirk wrote: »

Is there a normal procedure for converting code to another language? or is this normally a mind numbing task that a sane man would avoid.

Thanks

Bill M.

Do you have an operational device you can watch with and LSA and/or scope? Short of mapping out the logic and recoding...... don't know of any other way. Unless you can get your hands on the original source and port it over a function at a time......(uh no pun intended ....yet)

Frank

kwinn

@frank,based on post #4 I think he already has the source code.

@Capt. Quirk, I feel your pain, having done that for 8080/Z80 code without source code. Even with the source code it is a daunting task. At least I had an emulator program with a trace function that ran on the PC. I wonder if there is an emulator (for PC or Prop) that might be of help to you. I wish you the best of luck with it, and thank my lucky stars it's not me who has to do it ;- )

Capt. Quirk

I hope I am not misrepresenting myself, the mcu is a Silicone Labs C8051F330, and the program was written about five years ago.

Kwinn> I have looked for a free simulator, but I haven't found one that works yet.

Frank F.> The author published his test bench that he used to test his speed controllers with,and debug his code. He kept most of it very simple, except for his Oscilloscope. The simple stuff is easily reproduced. I have Viewport, and Jazzed's logic analyzer. I know that's not nearly enough to do the job right, So I was planning on asking the forum about Oscilloscopes in a few months.

LocalRoger>

You're going to have to completely figure out how the program works, from stem to stern, THEN figure out how to implement its functions in the much different Propeller environment with a mis of PASM cogs, Propeller timer operations, and probably some Spin foreground and startup code.

This is exactly what I am trying to accomplish.

Capt. Quirk

Mike Green wrote: »

Keep in mind that you don't just substitute a cog or a cog counter for a timer.
It all depends on how the timer is used. Similarly, you can assign a cog to
deal with what would have been an interrupt, but that's not always the best solution.
It depends on what the interrupt is used for.

That is good advise.

I was planning on substituting a cog counter for a timer.

John A. Zoidberg

You may need to "translate" the 8051's ASM to a higher language equivalent, like C, and then back to the Prop ASM. Converting interrupt codes to Prop's cog-type codes can never be easy, but that's a quite challenging and rewarding work.

Start with printing out the codes on a paper, and then work it out by using a pen/pencil and paper (and a bottle of beer).

Invent-O-Doc

I agree with the above. The propeller doesn't have interrupts, so your new program's architecture is going to be a lot different. Can you break it into blocks and rewrite it?

Capt. Quirk

Originally, I did think about breaking it up into blocks and using six or seven cogs--it's a really long program.
I could leave the last cog to help debug. Then work towards consolidating the whole program into two or
three cogs. But as I was getting use to the program flow, I was thinking, one cog, maybe two, and five counters.

So, when Gadgetman and Mike Green brought it up Interrupts and Timers, I wasn't concerned
about that stuff. I was merely converting a program that a lowly single core processor easily ran.
I am using the Propeller, with eight cores, it doesn't need interrupts, and it has 16 counters!

Timers vs Counters, Cogs vs Interrupts, It's a speed bump. I have never liked the idea of using a cog
as an interrupt, it's like wasting a whole Basic Stamp or SX just to wait for something to happen.
Either way, it doesn't change the goal. It's just another learning experience along the way.

localroger

If it's a really long program, it's probably comprised of much shorter relatively independent blocks. In the 8051 though everything gets commingled because of the way the interrupt system works.

You will probably find that there are several groups of periodic logic performed at different intervals or on various hardware triggers, and a top level non time critical program that runs when interrupts aren't being serviced. Your first job is to separate these various threads. You will probably have fast, time-critical stuff that has a high priority but doesn't do a lot of processing, slower still time-critical but not quite as bad logic that can be interrupted itself by the more critical stuff but that does more complex processing, obviously code to respond to hardware inputs at various levels of criticality (you need to know what it can interrupt and what it will wait for), and of course the top level stuff which will be stuff like user interfaces and recordkeeping. Once you have all these individual tasks isolated, you can start thinking about how to reassemble them in a way that keeps their priorities satisfied.