PIC10F322 AD Project in Assembly, RS232

(instructions, reset, WDT, specifications...) PIC10F2xx, PIC12F5xx, PIC16F5x

Re: PIC10F322 AD Project in Assembly, RS232

Postby Tom Maier » Tue Sep 02, 2014 7:12 pm

I've worked in industry and scientific research and I taught college for a while (electronics and programming). I've seen environments where there is good team cooperation and I've also seen environments that were very poison. In the poison environments there is one or more people who are hyper-critical and they suppress any creativity in the rest of the group. Those are the groups that fail. Nothing gets done because everybody is hiding under their desks to avoid conflict.

I knew I had the right mix in a class room when all the students would be shouting out answers, right or wrong. They were all awake, paying attention, and contributing. Often they would design the circuit or program with little help from me because they were going so fast that the best I could do was to document where they were going with it. It often took months to get the students to be that way, after the horribly oppressive environment of high school.
User avatar
Tom Maier
Verified identity
 
Posts: 179
Joined: Mon May 26, 2014 2:37 pm
PIC experience: Professional 5+ years with MCHP products

Re: PIC10F322 AD Project in Assembly, RS232

Postby MMcLaren » Tue Sep 02, 2014 8:32 pm

Olin Lathrop wrote:
Tom Maier wrote:Hey Olin, Why don't you post something?


OK, here is a example WAIT macro like I mentioned. This is for a PIC 10F204:


Hi Olin,

I apologize ahead of time for going slight off-topic.

May I ask you a couple questions about your WAIT macro for 12-bit core, please?

1) Is the macro generating multiple instances of that basic 3 cycle loop for larger delays? If so, what is the maximum number of instances the macro can produce?

2) Are you subtracting one cycle from the calculated total number of delay cycles because the macro lacks the capability to specify "subtract 'n' number of cycles" in the macro parameter?

Let me explain question number two. Let's say I need a delay of 250 microseconds minus 5 cycles. In my "cycle-accurate" delay subsystems the macro parameter would be (250*usecs-5). Here's a usage example;

Code: Select all
;
;  beep task, generate a 32-msec 2000-Hz tone on the piezo speaker.
;
beep
        movlw   128             ;
        movwf   beepctr         ; 128 x 250-us = 32-ms
bloop
        DelayCy(250*usecs-5)    ; 250-usecs minus 5 cycles in loop
        movlw   1<<spkr         ; bit mask for piezo spkr on RB7
        xorwf   PORTB,F         ; toggle piezo pin
        decfsz  beepctr,F       ; done? yes, skip, else
        goto    bloop           ;



This code produces a precise 2000-Hz tone of 32-ms duration using almost any clock by accounting for the number of instruction cycles in the loop. Can I use your WAIT macro in a similar manner where I can easily account for those loop cycles by specifying them in the delay parameter? If not, would you be kind enough to show me what the delay parameter would be for a delay of 470 microseconds minus 12 cycles for your WAIT macro (Fosc = 8-MHz), please? Would the parameter be 464e-6 or 4635e-7?

Thank you in advance.

Cheerful regards, Mike
MMcLaren
 
Posts: 18
Joined: Sun Aug 31, 2014 10:08 pm
PIC experience: Experienced Hobbyist

Re: PIC10F322 AD Project in Assembly, RS232

Postby Olin Lathrop » Wed Sep 03, 2014 12:41 am

MMcLaren wrote:1) Is the macro generating multiple instances of that basic 3 cycle loop for larger delays? If so, what is the maximum number of instances the macro can produce?

In this quick example I only implemented a single loop with a maximum number 256 iteration. If you look carefully at the section that writes the loop, you will see a check that produces a error if the wait is too long for that.

2) Are you subtracting one cycle from the calculated total number of delay cycles because the macro lacks the capability to specify "subtract 'n' number of cycles" in the macro parameter?

In this simple example, I was subtracting one cycle because that happens anyway. The delay betwen adjacent instructions is 1 cycle, so if you want 1 cycle between instructions you don't need to add any additional wait.

If you look at SOURCE > PIC > STD.INS.ASPIC and SOURCE > DSPIC > STD.INS.DSPIC in my PIC development environment, you will find macros that do waits exactly like what you are suggesting. Often you want to wait a specific time, but also have some other code you can throw into the wait. You therefore want to specify the time to wait, minus some number of instructions to wait. My general wait macros do exactly that. The second argument is the number of cycles to not wait, and is usually optional.

Here is my BUSYWAIT macro, from STD.INS.DSPIC:

Code: Select all
////////////////////
//
//   Macro BUSYWAIT time [, cycles]
//
//   Causes a busy-wait for time TIME minus CYCLES instruction cycles.  TIME is
//   in units of seconds.  Explicit code will be written that wastes the
//   indicated time, so this macro should only be used for very short waits.
//
//   The total wait time is rounded to the nearest whole instruction cycles.
//
/macro busywait
  /if [exist -1 arg] then
    /show "Dumb place for a label, moron.  The " [qstr [ucase [arg -1] " macro does"
    /show "not support a label."
         .error  "Label"
    /stop
    /endif
  /var local time real = [arg 1] ;time to wait in seconds
  /var local mincy integer = 0
  /if [exist 2 arg] then
    /set mincy [arg 2]
    /endif
  /var local cy integer      ;final number of instructions to wait

  /set cy [rnd [* time freq_inst]] ;instructions to wait due to TIME
  /set cy [- cy mincy]       ;minus CYCLES
         waitcy  [v cy]      ;write the instructions to do the wait
  /endmac


Code: Select all
        DelayCy(250*usecs-5)    ; 250-usecs minus 5 cycles in loop

As you can see, I do something similar, but let the macro convert between units of seconds and units of instruction cycles.

Can I use your WAIT macro in a similar manner where I can easily account for those loop cycles by specifying them in the delay parameter? If not, would you be kind enough to show me what the delay parameter would be for a delay of 470 microseconds minus 12 cycles for your WAIT macro (Fosc = 8-MHz), please? Would the parameter be 464e-6 or 4635e-7?


You shouldn't have to know. This is something the computer doing the build should do for you. I always have the preprocessor constant FREQ_INST defined, which is the instruction cycle frequency in Hz. From that, preprocessor math can do the conversion to cycles without that being in your code directly. That also makes the code automatically adjust if you decide to use a different clock frequency.
User avatar
Olin Lathrop
Verified identity
 
Posts: 48
Joined: Fri May 30, 2014 3:38 pm
Location: Littleton, MA USA
PIC experience: Professional 5+ years with MCHP products

Re: PIC10F322 AD Project in Assembly, RS232

Postby MMcLaren » Wed Sep 03, 2014 4:53 am

Olin Lathrop wrote:
MMcLaren wrote:Can I use your WAIT macro in a similar manner where I can easily account for those loop cycles by specifying them in the delay parameter? If not, would you be kind enough to show me what the delay parameter would be for a delay of 470 microseconds minus 12 cycles for your WAIT macro (Fosc = 8-MHz), please? Would the parameter be 464e-6 or 4635e-7?

You shouldn't have to know. This is something the computer doing the build should do for you. I always have the preprocessor constant FREQ_INST defined, which is the instruction cycle frequency in Hz. From that, preprocessor math can do the conversion to cycles without that being in your code directly. That also makes the code automatically adjust if you decide to use a different clock frequency.

It seems your WAIT preprocessor language macro lacks the capability I described. If I understand WAIT operation correctly from your description, I couldn't specify a single WAIT parameter that would generate my 470 microsecond minus 12 clock cycle delay at different clock speeds. I would have to use something like WAIT(458e-6) with Fosc 4-MHz, or use WAIT(464e-6) with Fosc 8-MHz, or use WAIT(467e-6) with Fosc 16-MHz. Clearly, the WAIT macro isn't a good fit for the type of delays I described, though I understand now that you have other macros that will fulfill the requirement.

May I impose once more to ask about your ASPIC preprocessor language, please? It seems you have a lot more capability in the format of parameters compared to standard MPASM macros. How is that possible? Is the ASPIC preprocessor an application of some sort?

TIA... Cheerful regards, Mike

<added>

While I'm sure your ASPIC preprocessor macro language is very useful and a very productive tool for you, the language and syntax seems rather esoteric. It doesn't seem any more intuitive now than it did when I looked at it ten years ago. For example, it's not obvious (to me) how your WAIT macro is any better or worse than a similar standard MPASM macro (example below, 14-bit core), except that I can actually understand the MPASM macro (grin).

Code: Select all
;==================================================================
;  inDlyCy() in-line delay             Mike McLaren, K8LH, Jun'07
;
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

Last edited by MMcLaren on Wed Sep 03, 2014 1:08 pm, edited 2 times in total.
MMcLaren
 
Posts: 18
Joined: Sun Aug 31, 2014 10:08 pm
PIC experience: Experienced Hobbyist

Re: PIC10F322 AD Project in Assembly, RS232

Postby Ian.M » Wed Sep 03, 2014 6:53 am

@Olin,
RTFM, or in this case the PIC10F322 datasheet (DS41585A).

This is *NOT* a baseline part.

I agree CBLOCK sucks, but what other alternatives are there if you want the total control absolute assembler gives?
Ian.M
Verified identity
 
Posts: 94
Joined: Wed May 28, 2014 12:47 am
PIC experience: Professional 1+ years with MCHP products

Re: PIC10F322 AD Project in Assembly, RS232

Postby Olin Lathrop » Wed Sep 03, 2014 1:27 pm

MMcLaren wrote:It seems your WAIT preprocessor language macro lacks the capability I described. ... though I understand now that you have other macros that will fulfill the requirement.

Exactly. I wrote that macro to illustrate a different point. However, modifying it to take a optional argument that is the number of cycles to wait less then the specified time is trivial:

Code: Select all
////////////////////////////////////////////////////////////////////////////////
//
//   Macro WAIT sec [, cycles]
//
//   Wait the indicated time from the previous instruction until the next
//   instruction is executed.  SEC is amount of time to wait in seconds.  The
//   preprocessor constant FREQ_INST must be previously defined to indicate the
//   instruction clock frequency.
//
//   The optional CYCLES argument is the number of instruction cycles less to
//   wait than the time specified by SEC.  CYCLES defaults to 1.
//
//   The actual wait will be rounded to the nearest number of whole instruction
//   cycles.
//
//   The variable WAITCNT is trashed.
//
/var new labeln integer = 0  ;for making unique number per macro invocation

/macro wait
  /var local sec real = [arg 1] ;desired wait time in seconds
  /var local nwcy integer = 1 ;number of cycles not to wait
  /if [exist 2 arg] then
    /set nwcy [arg 2]
    /endif
  /var local nwait integer   ;number of cycles left to wait
  /var local ii integer      ;scratch integer
  /var local r real          ;scratch floating point

  /set labeln [+ labeln 1]   ;make unique 1-N number of this macro invocation

  /set nwait [rnd [* sec freq_inst]] ;make cycles specified by SEC
  /set nwait [- nwait nwcy]  ;minus the cycles to explicitly not wait
  /if [<= nwait 0] then      ;no cycles to wait ?
    /quitmac
    /endif

  /set r [/ nwait freq_inst] ;actual additional wait time, seconds
  /write
  /write "         ;  Wait " [eng r] "s (" nwait " cycles)"
  /write "         ;"
//
//   Do long waits by spinning in a loop.  This loop waits 3 cycles for each
//   iteration plus 4 overhead cycles.
//
  /if [>= nwait 7] then      ;at least one iteration to wait ?
    /set nwait [- nwait 4]   ;account for loop entry/exit overhead cycles
    /set ii [div nwait 3]    ;determine number of loop iterations
    /set nwait [- nwait [* ii 3]] ;update cycles left to wait
    /if [> ii 255] then      ;too many iterations for this algorithm ?
      /show "  Wait time of " [eng sec] "s is too long for the WAIT macro"
         error   Wait
         end
      /stop
      /endif
         movlw   [and [+ ii 1] 16#FF]
         movwf   waitcnt
waitloop[v labeln]
         decfsz  waitcnt
         goto    waitloop[v labeln]
    /endif
//
//   Wait two cycles at a time by using GOTO $+1
//
  /block
    /if [< nwait 2] then     ;not enough cycles left for this method ?
      /quit
      /endif
         goto    $+1
    /set nwait [- nwait 2]
    /repeat
    /endblock
//
//   Wait the remaining cycles by explicit NOPs.
//
  /block
    /if [<= nwait 0] then    ;no cycles left to wait ?
      /quit
      /endif
         nop
    /set nwait [- nwait 1]
    /repeat
    /endblock
  /endmac


This time I didn't test it, didn't even try to build it, so can't say for sure it is correct. Note the new optional second parameter. That defaults to 1 cycle, so previous code using this macro without the second parameter should work identically.

May I impose once more to ask about your ASPIC preprocessor language, please? It seems you have a lot more capability in the format of parameters compared to standard MPASM macros. How is that possible? Is the ASPIC preprocessor an application of some sort?

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.

While I'm sure your ASPIC preprocessor macro language is very useful and a very productive tool for you, the language and syntax seems quite alien to me.

Any new language is going to seem strange. Like all such things, it's no longer strange once you learn it.

The PREPIC syntax was dictated in part by having to live around the MPASM and ASM30 syntax. This was done by having preprocessor commands start with a slash, and inline functions be enclosed in brackets. Once you realize that the inline functions use a operator-first notation, things aren't really all that hard to understand. For example, old HP calculators were famous for using "reverse polish", which is operator-last. To add 5 and 7 you'd say "5 7 +". With PREPIC you say "+ 5 7", which makes parsing simple and the whole structure highly regular.

For the details see http://www.embedinc.com/pic/prepic.txt.htm

It doesn't seem any more intuitive to me now than it did when I looked at it ten years ago. For example, it's not obvious (to me) how your WAIT macro is any better or worse than a similar standard MPASM macro (example below, 14-bit core), except that I can actually understand the MPASM macro (grin).


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. Surprisingly, after all your complaining about wanting a fixed time wait minus some cycles, yours doesn't do that either.

PREPIC features that my macro makes use of that MPASM can't do include floating point arithmetic and optional arguments. MPASM macros are also rather bad at string manipulation, there are problems with LOCAL, etc. Now I mostly just write PREPIC macros, whether they could have been written easily in native assembler or not.
User avatar
Olin Lathrop
Verified identity
 
Posts: 48
Joined: Fri May 30, 2014 3:38 pm
Location: Littleton, MA USA
PIC experience: Professional 5+ years with MCHP products

Re: PIC10F322 AD Project in Assembly, RS232

Postby Olin Lathrop » Wed Sep 03, 2014 1:31 pm

Ian.M wrote:RTFM, or in this case the PIC10F322 datasheet (DS41585A). This is *NOT* a baseline part.

I agree CBLOCK sucks, but what other alternatives are there if you want the total control absolute assembler gives?


Now you need to RTFM, in this case the MPASM manual. The RES directive is the only way in MPASM to actually allocate memory, as apposed to defining constants that only you know are meant to be the addresses of variables.
User avatar
Olin Lathrop
Verified identity
 
Posts: 48
Joined: Fri May 30, 2014 3:38 pm
Location: Littleton, MA USA
PIC experience: Professional 5+ years with MCHP products

Re: PIC10F322 AD Project in Assembly, RS232

Postby Tom Maier » Wed Sep 03, 2014 3:54 pm

Olin,

I challenged you to post a completed project. How's it going with that?

It's due by tomorrow. I'll be deducting 20% off the grade per day you are late.

Hurry!
User avatar
Tom Maier
Verified identity
 
Posts: 179
Joined: Mon May 26, 2014 2:37 pm
PIC experience: Professional 5+ years with MCHP products

Re: PIC10F322 AD Project in Assembly, RS232

Postby Olin Lathrop » Wed Sep 03, 2014 4:24 pm

Tom Maier wrote:I challenged you to post a completed project. How's it going with that?

I have no intention of doing that. Commenting on someone else's project in no way obligates one to produce a project themselves. Actually I do have several complete projects on my web site, although most of them are pretty old by now.

Have you fixed the CBLOCK yet in your code? How is it going with that?

Really, Tom, you should stop acting like a child about this. You posted something, and I pointed out both good and bad things in it. Reasonable reactions include providing learned arguments in rebuttal, agreeing and fixing, saying this way is your preference regardless of downsides, etc. However, throwing a tantrum isn't one of them.

Whether you like a response has nothing to do with it. Yes the comment about CBLOCK was meant to kick you in the butt since this is a topic that has been discussed many times in many places for many years and is, frankly, irresponsible engineering. Looks like it worked. Methinks you know CBLOCK for this purpose is bad programming, hence the trantrum to attempt to deflect attention. If you didn't known, you would have asked why or tried to explain why it's OK.
User avatar
Olin Lathrop
Verified identity
 
Posts: 48
Joined: Fri May 30, 2014 3:38 pm
Location: Littleton, MA USA
PIC experience: Professional 5+ years with MCHP products

Re: PIC10F322 AD Project in Assembly, RS232

Postby Tom Maier » Wed Sep 03, 2014 4:48 pm

Olin,

It's not just me, you have a reputation of pissing people off. And in your own mind you believe it is because you are some kind of legend. Your legendary status is for causing trouble, not for your contributions. You were kicked off the microchip site, right?

A sign of intellegence is the ability to recognise patterns and not keep making the same mistakes. Do you see any patterns over the past years? Maybe you don't see the mistakes? What does that imply?

I've worked with world renowned people over my life, and NONE have shown the pompous attitude that you display. You have no reason to be pompous. People who are achievers don't NEED to be pompous because they already have the kudos and they feel secure about who they are. You believe that if you act like a putz and try to imtimidate people that you will be respected, but that isn't how you receive respect. I think your issues come from the fact that you feel insecure about who you are and you feel good about kicking others, because you think that if you can get ahead, then you will drag others down.

When you learn to respect yourself, you will not need to do that anymore and you will find that people will be able to respect you. Otherwise you are going round-and-round the carousel.
User avatar
Tom Maier
Verified identity
 
Posts: 179
Joined: Mon May 26, 2014 2:37 pm
PIC experience: Professional 5+ years with MCHP products

PreviousNext

Return to 12-Bit Core

Who is online

Users browsing this forum: No registered users and 1 guest

cron