| ??? 01/09/07 16:55 Read: times |
#130516 - similar concept to MAC routines, locking to binary Responding to: ???'s previous message |
you might also have a look at how the Multiply Accumulate Unit would be accessed here:
"MACROs for using the MAC unit on c8051f12x devices" http://www.cygnal.org/ubb/Forum10/HTML/000014.html The handling of the MAC unit there is probably similar to what you have to do on your device: - Setting mode - Setting up some (16 bit) arguments in SFR - Starting engine - insert some NOPs until stuff is done - expect 32 bit result in SFR (or some ready bit) By the use of macros you can avoid considerable overhead (loading arguments, procedure call, .., return) and have better control anyway. A note on binary only libraries: As long as your code just implements functionality like the one outlined above there should be NONE. Why? Let's look at your original post with respect to binary objects: your C code would lead to ?C?LLDPTR being linked. I'm pretty positive that this would not give the result you expect (the mcs51 architecture does not support SFR access by pointer). This is a very simple problem and single stepping through the code could immediately pin down the problem, but this certainly is nothing that you'd want to do for more complex code. So even your short (about 10 lines blank stripped) C code is affected by a binary only object and seems to have hindered yourself (and caused additional work (at least for readers of this forum to whom I hereby apologize)) Why again? Also your code handles Interrupt Enable (with restoring EA to its previous state) and needs overhead to do so. How do you know that the programmer does not always know the previous state of EA and thus can get away with simply clearing/setting EA? Or that he has handled IRQ locking on a higher level? Or he rather wants to use the IRQ mask for locking? Or that he can do without IRQ locking at all because the program flow guarantees there is no conflict? Or that in his case IRQs are reenabled too early (after setting up the engine but before reading the result) Or that he f.e. only needs to touch the high byte of the argument between two subsequent runs of the engine? Maybe I have misread your previous postings but: If you want to enable programmers to make the most of your device then locking to a binary only interface seems a bad idea. Greetings, Frieder |
