Surprisingly, after all your complaining about wanting a fixed time wait minus some cycles, yours doesn't do that either.
It's interesting that you would perceive my query and assessment as a complaint. I simply asked if your WAIT macro was capable of a certain function and then determined it was not. Of course you pointed out, and I acknowledged, that you have other macros which will perform the function I asked about.
Your assessment of the in-line delay macro I posted and its ability to perform a fixed delay minus some cycles may have been a little hasty. I can assure you it performs that function quite well (while letting the assembler do all the work);
- Code: Select all
;==================================================================
; inDlyCy() in-line delay Mike McLaren, K8LH, Jun'07
;
radix dec
clock equ 4 ; 4, 8, 12, 16, or 20 MHz
usecs equ clock/4 ; cycles/usec operand multiplier
inDlyCy macro delay ; 0..1027 cycles
local loop
if delay > 3
movlw delay/4
loop addlw -1 ; 4 cycle loop (14 bit core)
skpz ; done? yes, skip, else
goto loop ; loop (do another 4 cycles)
endif
if delay&2 ; delay%4 == 2 or delay%4 == 3
goto $+1 ; delay 2 additional cycles
endif
if delay&1 ; delay%4 == 1 or delay%4 == 3
nop ; delay 1 additional cycle
endif
endm
- Code: Select all
;
; example macro invocation
;
inDlyCy(470*usecs-12) ; delay 470-us minus 12 cycles
Note the new optional second parameter. That defaults to 1 cycle, so previous code using this macro without the second parameter should work identically.
Thank you. That's a very nice example of the ease at which you can modify one of your macros.
The MPASM macro facility is rather primitive. It can do some things, but other things are either difficult, awkward, or impossible. Your MPASM example wait macro does a lot less than my PREPIC macro, so it's apples versus oranges. Yours doesn't take a time value and compute the number of cycles, does no error checking for the wait time being too long (it will just silently produce the wrong delay), and couldn't emit a nice readable error message if it did.
Good points, thank you, but aren't there facilities in standard MPASM macros to do some of those things? I'll have to check but I think I may have used MPASM intrinsic macro features to check values and emit messages in the past. And I hope you can see from the example above that it's relatively easy to convert a time value to cycles. However, your points are well taken. There are plenty of things I wish I could do with MPASM macros which are impossible.
The MAPASM and ASM30 preprocessor is a executable called PREPIC. In my build environment, I write .ASPIC (and .DSPIC on 16 bit core parts) source files. These are translated by the preprocessor to produce the .ASM file for MPASM or the .AS file for ASM30, which are then translated with the Microchip assemblers as usual.
This may have been part of the reason why I dismissed your ASPIC macro language subsystem years ago. It was, and still is, difficult to justify adding components to my development environment which may have questionable value or performance and it's difficult to justify the time that would be required to vet the system. Then you have to consider if the investment is worth the return. Hopefully you realize these are practical considerations and not intended to be offensive.
Now I mostly just write PREPIC macros, whether they could have been written easily in native assembler or not.
Yes, I've noticed that over the years. <caution - attempt to inject humor> When Tom asked you to post something I screamed at the computer "No Tom! Please, don't ask him for that!" (lol).
On a more serious note. I wonder if your use of ASPIC macros is having the desired effect? That is, I realize they must have immense production value for you, but when you post a code snippet laced with ASPIC macros, would average people be inclined to spend time decrypting the code to see how it worked? Speaking for myself, I've looked at several of your snippets over the years. Often, after spending ten minutes just to realize that a couple ASM instructions could have been used instead of a cryptic macro, which would have made the code much more readable and comprehensible, I would move on to something more interesting. Don't get me wrong, I love studying code, but it just wasn't worth the effort and investment in time (for me) to study your version of something I had probably already mastered.
Olin, thank you for taking valuable time away from your other duties to indulge my questions.
Cheerful regards, Mike