Shop OBEX P1 Docs P2 Docs Learn Events
Propeller Assembly for beginners - Page 6 — Parallax Forums

Propeller Assembly for beginners



  • HarpritHarprit Posts: 539
    edited 2011-07-30 13:24
    Do you mean the last PASM command in each cog (for each cog) or
    the last PASM command in the entire program?
  • HarpritHarprit Posts: 539
    edited 2011-07-30 13:35
    You have me flummoxed. Allow me to reveal by gullibility.
    Are you just putting me on or do you really not have access to a scope?
    I've worked with some programmers I could believe that about (but would rather not).

    It going to take me a while to implement all the great ideas revealed by Stephan and Jazzed
    so hang on for a day or two for the next post in which I hope the frequency of a signal will be
    controlled by a potentiometer. You'll need a scope to look at it or reduce the frequency to hear it..

  • jazzedjazzed Posts: 11,803
    edited 2011-07-30 14:02
    Harprit wrote: »
    Do you mean the last PASM command in each cog (for each cog) or
    the last PASM command in the entire program?

    I'm not sure I get the question. As an overview though:

    A DAT section is used per COG - that is each COG should have it's own DAT section.
    Each new DAT section should start with ORG (or ORG 0).

    A PASM program for one COG goes into one DAT section and can be made of up to 496 instructions, long, and res. Instructions are all longs, longs used as variables all should have labels (names), some instructions have labels.

    RES variables should be at the end of each DAT section. RES variables should have names. To keep ensure the combination of instructions, longs, and res are in the range of 496, use the fit directive at the end i.e. "fit 496".

    Does that help at all?
  • HarpritHarprit Posts: 539
    edited 2011-07-30 14:21

    Yes it does indeed. Very much so.
    I thought that is what was meant but I was not absolutely sure. One needs to be absolutely sure.
    Each Cog is independent and needs it constants and res 1 variables listed at its tail end.

  • mindrobotsmindrobots Posts: 6,506
    edited 2011-07-30 18:18

    A pleasure to flummox you!! :lol:

    I've never owned a scope (until recently) and never really learned how to use one. I imagine they could be quite useful!!

    My formal electronics education is lacking (nonexistent) in some areas.....

    I do have a recently purchased DSO Nano pocket scope some place in a box in my office but I haven't had/taken the time to do anything with it yet.

    I do have an old logic probe I made from a kit way back when that I've used.....

    I've somehow survived through my building stages without a scope.....

    I'm 75% software (and I guess 25% blinking lights!!)
  • potatoheadpotatohead Posts: 10,260
    edited 2011-07-30 19:29
    I don't think a scope is mandatory for the beginner. Nice to have, but not mandatory.
  • HarpritHarprit Posts: 539
    edited 2011-07-30 19:30
    @Mindrobots/Rick (off subject)

    Now that was really funny.

    I'm a materials guy myself, and my readers are often disappointed when I cannot help them with their electronic problems.
    However I do really, really like to build stuff. I built a fully aerobatic single place airplane when I was 25!
    Probably the youngest guy ever to do so singlehandedly. And I did not know how to fly and I did not know much about
    aeroplanes and had never built anything that complicated before. Rudy Frasca of the Frasca flight simulators taught me
    how to fly. A lot of it has to do with just plain hanging in there. Not quitting.

    So this PASM beginner's book might get done yet. I'm getting lots of great help from some great guys on this forum.
    I'm even starting to understand some of it!! Amazing.

  • HarpritHarprit Posts: 539
    edited 2011-07-31 10:44
    Why will the 4 lines not go on and off in this program
      long  Shared
    PUB Main 
    cognew(@newCog, @Shared)
    Org 0
                 mov  dira, pin_07
    :loop        mov  outa,  pin_off
                 call  #pause
                 mov  outa, pin_on 
                 call  #pause 
                 jmp  :loop
    pause         mov      time, delay     'the delay subroutine
                  add      time, #$Ff       'delay added to skip past underflow of CNT
    delay_loop    sub      time, #1 wz     'sub 1 from time and set flag if 0
            if_nz jmp      #delay_loop     'if flag not 0 go back to take4                   
    pause_ret    ret
    pin_07    long %00000000_00000000_00000000_11111111
    pin_off   long %00000000_00000000_00000000_00000000 
    pin_on    long %00000000_00000000_00000000_11110000
    delay     long  4000
    mem       res   1
    time      res   1

  • JonnyMacJonnyMac Posts: 8,997
    edited 2011-07-31 10:50
    You do understand that all cog outputs are OR'd together, hence any cog can make an IO pin go high, despite what's happening in other cogs. You have two cogs manipulating IO pins and there's bound to be a conflict that causes confusing results.

    You're also missing # in your jmp #:loop line.

    And -- if I may, as you're insisting on writing a book for beginners -- suggest that you also include good formatting and documentation habits (which your code does not yet illustrate). I find that beginners create a lot of problems through sloppy formatting that ends up hiding logic errors.

    Putting my money where my big mouth is, this is how I would have constructed that code (this works on Demo and QuickStart boards)
                    org     0
    newcog          mov     dira, PINS_23_16                        ' make P23..P16 outputs
    :loop           mov     outa, ON_23_20                          ' activate P23..P20
                    mov     timer, DLY_TICKS                        ' set delay
                    call    #delay                                  ' hold a bit
                    mov     outa, ON_19_16                          ' activate P19..P16
                    mov     timer, DLY_TICKS
                    call    #delay
                    jmp     #:loop
    delay           add     timer, cnt                              ' sync with system counter
                    waitcnt timer, #0                               ' let it expire
    delay_ret       ret
    PINS_23_16      long    $00_FF_00_00
    ON_23_20        long    $00_F0_00_00
    ON_19_16        long    $00_0F_00_00
    DLY_TICKS       long    80_000_000 >> 2                         ' 1/4 second @ 80MHz                                 
    timer           res     1

    Note that the waitcnt instruction eliminates the need for running loops to create delays.
  • HarpritHarprit Posts: 539
    edited 2011-07-31 11:00
    @ JonnyMac

    Well I did think I understood that.
    Cog0 sets pin 0 as an output and does not bother any other pins
    Cog1 also sets Pin 0 as an output also there should be no conflict on pin 0 and does blink just fine.
    The 4 pins are pins 4 to 7 and they are independent of cog0

    I diagnosed the problem as in the delay routine of Cog1. Am I all wet? Is the delay part OK?

  • HarpritHarprit Posts: 539
    edited 2011-07-31 11:14
    That was it
    I'll work on the formatting

    Thanks for the additional code
    Its great to see a pro do it, that is what is missing most of the time, so simple stuff is never seen by beginners.
  • JonnyMacJonnyMac Posts: 8,997
    edited 2011-07-31 11:29
    Cog0 sets pin 0 as an output and does not bother any other pins
    Cog1 also sets Pin 0 as an output also there should be no conflict on pin 0 and does blink just fine.

    I understand that; I just want to make sure that you understand that if either of the cogs make the pin high it will go high; this is useful (for signal gating) but can confuse beginners unless you are very careful in your explanation.
    I diagnosed the problem as in the delay routine of Cog1. Am I all wet? Is the delay part OK?

    Not in my book. Why would use use loop counting when you have waitcnt which is far more effective? If you're going to teach Propeller programming, take advantage of Propeller features. And if you insist on counting down, you could simplify with djnz.
    pause           mov     time, delay                             ' set delay
                    djnz    time, $                                 ' decrement to 0
    pause_ret       ret                                             ' return

    Herein lies the oft-stated problem of being a beginner and writing a beginner's book: your lack of experience could cause your readers to suffer more than you ever intend. Sure, they'll learn along the way, but better they learn from your mistakes instead of by repeating them.
  • HarpritHarprit Posts: 539
    edited 2011-07-31 12:20

    The problem for me is that I have to start the beginners very slowly for I lose them. That I know.
    There are a million ways to get this done better and faster but if no one is reading the material after 10 pages,we
    did not get it done and we can all go home.
    As for the book. Lets wait and see what I come up with and see if it helps and if it meets your standards.
    You are judging it from the code I write today. That is my learning process, not the finished product.
    I hope that you will be pleasantly surprised. The beginners will like the book (and no doubt there will be some carping)
    That's the way it is. Any one who can do it better is most welcome. This thing has been kicking around for a while.
    I am talking high school kid, not engineers with expertise is C++. Amazon me, My books get 5 stars. See what they say.
    From the experts....NO BOOKS YET. I don't think that you would rather that I quit?

  • JonnyMacJonnyMac Posts: 8,997
    edited 2011-07-31 14:06
    Let me turn this around. I'm an actor, seeking to make a full-time living in the entertainment business. Should I take lessons from a youngster who's done a couple gigs in community theater or from a seasoned stage and screen veteran with dozens of movies, plays, and hundreds of TV episodes to his credit? Who do you think can give me the best guidance toward a career as a full-time actor? Someone who isn't, or someone who actually is? Of course, I'll stick with an expert (which I do; the second description above is of my acting teacher, a 45-year show-biz veteran).

    I'm suggesting you develop some serious expertise before presenting yourself as one; whether you mean it to or not, your name on the cover of a book sets you up as an "expert."
    My books get 5 stars.

    Sorry, not from me. When asked, I steered a newbie AWAY from your Spin book because I felt it had too many errors and taught many bad habits. Mind you, this is just my opinion -- and if it matters, I've been writing for Nuts & Volts since 1997 and get a lot of very nice email about the column. I have my own book on Spin in the works, we'll see how it fairs. In fact, I'll sign a copy for you; that way you don't have to pay for the book and if I get famous, you can eBay my autograph for extra cash! ;)
  • HarpritHarprit Posts: 539
    edited 2011-07-31 14:20

    I used to subscribe to Nuts and Volts and always made it a point to read you stuff because, and I hate to say this, your stuff was simple enough for a novice like me to read and to understand. As I remember it was mostly PIC stuff. The stuff you guided me to on the propeller (that you had authored) was very good because I could understand it.

    To follow up on your actor analogy, I am not aiming at professional programmers, my audience is tinkerers and beginners. If you want to be a profession programmer who writes compilers and search engines, you need a decent degree from a reputable school. Maybe even a math minor in set theory. There are a few good free lance programmers but they are not going to be reading my book. I am sure your book will be above the level of my audience and I very much look forward to reading your book. Let me know when you need my address. And good luck and best wishes on you success. And I hope you get really really famous.

    Hurry up on your book, I'm 71 and it could be curtains any day now!

  • StefanL38StefanL38 Posts: 2,292
    edited 2011-07-31 14:54
    I think if there is a continous accompaniment of experts the book will be very good in the end.

    Harprit is a beginner himself. This means he will encounter a lot of of the traps a beginner will step into.
    Experts know the traps very well and as more as they get experts the more these experts are blind for those traps
    They code it right without thinking anymore about it.

    Especially about the command waitcnt:

    What's so hard about understanding waitcnt stops the whole cog: Until the value "timer" is matched by the system-counter.

    This leads me to an idea: How about using the propeller itself to illustrate how the propeller-hardware works?
    How about coding a program that shows a model of the systemcounter counting up all the time (as a model is enough lets say from 0-99 wrapping around to 0)
    Then a model of an animated cog executing commands and if the command WaitCnt is executed stopping the animation until the systemcounter matches the "timer"-value
    and then the cog-animation continues.

    Next best solution would be to create some graphics that are "snap-shots" of this animation
    - executing normal commands
    - executing the WaitCnt
    - stop until match
    - executing commands again.

    It is all just a matter of how much time and effort are you taking on explaining anything.

    Harprit if your product includes explanations like this the readers will call for 10 stars.

    Anyway a waitcnt stops the whole cog. There are situations where a delay is needed and other things should run at the same time at high speed in the same cog
    This is the place for using a counter like you did in the code above.

    I have a more general question too: You are in an early stage of the book-project. The example-codes that you are posting are they just for your own learning ahead of explaining or
    do you want to start your book with the code-samples you have posted?

    If second it would be good to have headlines what the code will do or which new things (compared to the code-example before) the code includes.
    keep the questions coming
    best regards

  • HarpritHarprit Posts: 539
    edited 2011-07-31 15:21

    Right now everything is my learning process. It will be very different as I myself start to understand the system.

    I fully understand your point about experts coding it right the first time. They do not appreciate what the novice is going through in his mind. For him it has to be made simple. As you stated everything has to be illustrated and explained. I will try to do that as per your suggestions. You are a teacher so your opinions are very important.

    Just follow and see what happens. It will be OK.


    Though there have been some extremely helpful suggestions and posts, there have also been some posts by experts that are totally missing what beginner's need. IMHO.

    I am pretty sure you recommended the Parallax book in place of mine. If you think that book is for beginners, you have another think coming. I think experienced programmers are so eager to show what great stuff can be done with the propeller that they lose track of any teaching that might get done. I too think it is a fantastic engine but the learners don't say "Tell me what a great chip this is'". They say "I don't know where to start, can you help me?" Lets try to help them.
  • JonnyMacJonnyMac Posts: 8,997
    edited 2011-07-31 15:33
    The stuff you guided me to on the propeller (that you had authored) was very good because I could understand it.

    I appreciate that feedback; especially being a self-taught programmer. That said, I didn't start writing about programming until I had about 17 years of practical (nothing earth-shattering, but real-wold nonetheless) experience. I've waited this long to write a whole book on Spin because I really wanted to make sure I was good at the [practical] stuff that I like to teach.
    As I remember it was mostly PIC stuff.

    SX perhaps, using SX/B (which I helped with), but never the PIC. I've only used a PIC a couple times, and neither time was a lot of fun (hence I have never written about it).
    it has to be made simple.

    This statement is frequently [ab]used as an excuse for "quick and dirty" which I always say -- even in print -- is never quick and always dirty. In the end, your name is going on the book and you have to be responsible for its content. I am merely suggesting you can point newbies to the dangers of a cliff without pushing them off of one.
  • HarpritHarprit Posts: 539
    edited 2011-07-31 15:45

    My SPIN book has over 120, yes well over 120 pages, pages of SPIN Code in it and each and every line is commented so that a beginner can understand it. There is nothing quick about that and no one has complained that there was any dirtiness or slop. Quite the contrary. On the other hand none of the experts has come anywhere near providing that level of coding and commenting. NOT even CLOSE. In most programs not even half the lines are commented. I suppose beginners will just have to divine what those lines mean.

    So I very much look forward to a very well coded and commented book from you. In every way as good as the stuff you sent me.

  • K2K2 Posts: 691
    edited 2011-07-31 15:58
    StefanL38 wrote: »
    ...Especially about the command waitcnt...waitcnt stops the whole cog:

    This resonates with me. Waitcnt is featured too often in code examples in the PM, and at the expense of more important matters. It's almost a worthless thing. The project I'm working on right now has 862 lines of code and not one Waitcnt. I couldn't possibly afford to stop execution in any of the cogs...not unless I can also stop The World.
    Harprit wrote:
    I suppose beginners will just have to divine what those lines mean.

    Sing it sister!
  • JonnyMacJonnyMac Posts: 8,997
    edited 2011-07-31 16:02
    My code is always clean and well-commented -- you know that from seeing my listings. To be fair (to me, that is), you cannot count magazine listings as they are in 2-column format and there is barely enough room in a column for code, hence no comments in magazine listings but there is a lot of descriptive text in my column. All of the programs I write -- whether they're published or not -- are documented; for reasons I just explained, sometimes the comments don't make it to print. This is why I work so hard at crafting code that is easy to follow; self-commenting to the degree I can.

    I hope you will avoid newbie (quick and dirty) traps the fill your Spin code: things like embedding pin numbers, e.g.,
    dira[16] := 1

    Yes, it's quick. Yes, it works. Until someone comes along and has to change the layout and then has to look through the code to find all instances of the above line to fix them. Sure, there is global search-and-replace, but if one is smart enough to use that I have to assume that one is smart enough to create named constants where the are appropriate.
    dira[LED] := 1

    The other issue I take with your code is inconsistent formatting. Variables, for example: sometimes they're all lower case (even with two words in name), sometimes camel-case, sometimes start with an uppercase letter. The same inconsistencies exist with constant naming and method naming.

    Again, it's your book, do as you will. I just think you owe it to your readers to produce a good book. Working code is just a start. You do newcomers no kindness by teaching them (through examples) bad habits. Even hobbyist programmers can learn to code well.
    I am pretty sure you recommended the Parallax book in place of mine.

    The only book I've ever recommended is the PE Labs book by Andy Lindsay, though I have the same "quick and dirty" commentary about it. Getting past that, there is useful code and it sufficiently coddles those that still send their laundry home to mother. <smirk> I'm not the coddling type.

    I will bow out now as I don't think there is anything else I can offer.
  • JonnyMacJonnyMac Posts: 8,997
    edited 2011-07-31 16:22
    not one waitcnt. I couldn't possibly afford to stop execution in any of the cogs.

    That's not unheard of, but it is rare. Still, if you have any kind of timing constraints then you are using other -- dare I say more sophisticated and less beginner-friendly -- mechanisms. Peter Van der Zee is a master at programming timing-centric code without every stopping (he's scary good).

    For example, I wanted to get my own grip on jmpret (it stumped me; remember, I'm an actor) until I just rewrote a demo for myself. This [silly] code does fairly precise timing of blinky LEDs without using waitcnt (again, not my original code, I just rewrote to "make it mine.").
                            org     0
    entry                   mov     outa, #0                        ' initialize to both off
                            mov     dira, led1mask                  ' make LED1 pin an output
                            or      dira, led2mask                  ' make LED2 pin an output
                            mov     led2code, #led2                 ' setup ping-pong multitasking
                            mov     timer1, cnt                     ' initialize timers
                            mov     timer2, timer1
    led1                    or      outa, led1mask                  ' led 1 on
                            add     timer1, led1ontix               ' set led 1 on time
    :wait1on                jmpret  led1code, led2code              ' let led 2 have some time
                            mov     t1, timer1                      ' copy timer
                            sub     t1, cnt                         ' compare with system cnt
                            cmps    t1, #0                  wc, wz  ' timer expired?
            if_a            jmp     #:wait1on                       ' loop if not done
                            andn    outa, led1mask                  ' led 1 off
                            add     timer1, led1offtix              ' set led 1 off time
    :wait1off               jmpret  led1code, led2code              ' let led 2 have some time
                            mov     t1, timer1                      ' copy timer                
                            sub     t1, cnt                         ' compare with system cnt   
                            cmps    t1, #0                  wc, wz  ' timer expired?            
            if_a            jmp     #:wait1off                      ' loop if not done
                            jmp     #led1               
    led2                    xor     outa, led2mask                  ' toggle led 2
                            add     timer2, led2hctix               ' set led 2 half-cycle time
    :wait2                  jmpret  led2code, led1code              ' let led 1 have some time
                            mov     t2, timer2                      ' copy timer
                            sub     t2, cnt                         ' compare with system cnt
                            cmps    t2, #0                  wc, wz  ' timer expired?
            if_a            jmp     #:wait2                         ' loop if not done
                            jmp     #led2 
    ' --------------------------------------------------------------------------------------------------
    led1mask                long    0-0                             ' pin mask for LED 1
    led1ontix               long    0-0                             ' on timing (ticks) for LED 1
    led1offtix              long    0-0                             ' off timing (ticks) for LED 1
    led2mask                long    0-0                             ' pin mask for LED 2  
    led2hctix               long    0-0                             ' half-cycle timing (ticks) for LED 2     
    timer1                  res     1                               ' state timers
    timer2                  res     1
    led1code                res     1                               ' jump vectors
    led2code                res     1
    t1                      res     1                               ' work vars
    t2                      res     1
                            fit     496

    Definitely not for beginners, but I will be presenting this demo (among others) at DefCon next week while giving an overview presentation on the Propeller.
  • kuronekokuroneko Posts: 3,623
    edited 2011-07-31 17:30
    K2 wrote: »
    [waitcnt] It's almost a worthless thing. The project I'm working on right now has 862 lines of code and not one Waitcnt. I couldn't possibly afford to stop execution in any of the cogs...not unless I can also stop The World.
    Isn't that a bit like saying my code has 700+ lines and not a single waitvid? If you don't need a particular instruction then dont' use it :)

    I could agree with you on most examples being worthless but then I think examples aren't necessarily the best way to get the message across anyway.
  • kuronekokuroneko Posts: 3,623
    edited 2011-07-31 18:11
    Harprit wrote: »
    I diagnosed the problem as in the delay routine of Cog1. Am I all wet? Is the delay part OK?
    The delay routine - while odd - does what it says on the tin. Your problem here is the jump using a register instead of a label. Register $001 (:loop) contains a reference to register $00C (pin_off) which is your real jump target. Given that you only have a small amount of SPIN code there isn't much in the way to stop execution (nops, some conditionals) your code runs until it hits the SPIN stack marker ($FFF9FFFF)A which is now interpreted as code (waitvid). The video h/w isn't initialised so the waitvid hangs (LEDs on).

    Simple test, I initialised it (video h/w) before the rogue jump which allows execution to continue. The program counter wraps and restarts your program which then looks like it continues normally. But there are other side effects which stop execution again later (from the looks of it cnt dependent). Nothing to worry about right now. Just fix the jump target.

    A This is due to the fact that the cog is always initialised with the same amount of longs even if your program has only say 20 lines. So any code/data following your program in hub memory (SPIN methods in this case) will make it into cog memory and is potentially interpreted as code.
  • K2K2 Posts: 691
    edited 2011-07-31 19:16
    kuroneko wrote: »
    Isn't that a bit like saying my code has 700+ lines and not a single waitvid? If you don't need a particular instruction then dont' use it :)

    For sure! I've got nothing against the existence of a Waitcnt instruction, just its exclusivity in PM coding examples. It's frustrating primarily when something you do need is nowhere to be found.

    Probably due to too few brain cells or insufficient interconnections, unlike you I really do like examples. Not puerile examples, but real world examples appropriately documented for the propeller neophyte.

    @Jon: I'm a novice to the propeller, but not to real-time embedded control. In fact that's pretty much my only frame-of-reference wrt programming. I try to keep it that way. :)
  • frank freedmanfrank freedman Posts: 1,982
    edited 2011-07-31 20:05
    Harprit wrote: »
    In this book, I will assume that you have a serious interest in learning PASM. The book will follow the format, and the programs that were delivered in my book on learning SPIN. I will assume that you have the following resources available to you.

    xor outa, pin
    this instruction inverts the signal on pin 16 each time through the loop.


    This code may not work for me as listed here. I may be off on this one, but reaching deep into the gray matter, into the 8080/Z80 days, a fast trick to clearing the accumulator was to use XOR A producing all ZEROs in the accumulator. Refer to the logic truth table for XOR on p103 fig 2.56, Digital Logic and State Machine Design, Comer 3rd Ed. or other favorite reference. You can not perform a toggle function by an XORing a signal with itself. An XOR function is a difference detector. The only way to do this would be the PASM equivalent of negating the pin value on each pass through the loop to achieve the toggle function.


    @localroger, I also have the Z80 book (paperback 4th printing 1980), and the aforementioned Comer book for hardware design. Built my long gone IMSAI 8080 one board at a time.....
  • jazzedjazzed Posts: 11,803
    edited 2011-07-31 20:18
    This code may not work for me as listed here.
    Hi Frank. Welcome to the forum! Hope you enjoy visiting here.

    Harprit's original listing had this in it: "Pin Long |<16"
    The odd syntax means "Pin Long 1 << 16" and PASM is case insensitive.

    So in that case "xor outa, pin" should toggle the destination register outa bit 16.

  • HarpritHarprit Posts: 539
    edited 2011-07-31 20:21
    OK Guys, lets agree to leave it here and get back to what beginners need.

  • idbruceidbruce Posts: 6,197
    edited 2011-07-31 21:16

    I must admit that I am not following along with your example, however I am following this thread. My advice, don't get discouraged, I personally applaud your efforts, because there needs to be better documentation and well commented examples pertaining to PASM. From my own personal perspective, I would much rather buy a book written by an expert as compared to a novice, but that does not mean that a novice has nothing to contribute. Some of the most ingenious code I have ever seen was written by novices. Sure there were some improper coding techniques contained within the code, but nonetheless brilliant work.

    To be perfectly honest, whatever the field of interest, many of the worlds experts on any given subject are often filled with a lot of hot air and some self-perceived idea of greatness, which is a big turn off for me, especially when I am attempting to learn something from the ground up. And there are many times when the so called expert truly has no concept of the facts. For example, several years ago I was unemployed, and having a high degree of interest in patents, I applied for a position as a paralegal for a patent attorney. During an interview, I showed this expert patent attorney a patent application that I had written. As he is flipping through the pages of the patent application, he insults me by saying that the drawings will never meet the United States Patent And Trademark Offices regulations. The fact of the matter is, he didn't know his Smile from a whole in the ground, because the drawings had already received approval from the USPTO. He was wrong about the proper margins required for drawings and he was wrong about a specific technique that I used in my drawings. I did not say anything at the time, but I thought to myself that I would never hire this idiot as my patent attorney. Needless to say, the margin requirements had changed and this expert was unaware of the changes, and as far as the technique used within the drawings, I took advantage of the USPTO rules and regulations and did something that I am certain is very rare in patent documents or has never been done before, but it still met the criteria of the USPTO, and a patent was granted.

    Additionally, while being a far cry from what I consider being an expert electrician, I have a very fair degree of skill and knowledge in this trade. Every once in a while the new kid on the block will teach me a thing or two.

    So I say to you Harprit, "Go for it!". Even if you do not succeed in this endeavor, hopefully you will draw enough attention to this thread to where some serious action will be taken.

  • frank freedmanfrank freedman Posts: 1,982
    edited 2011-07-31 21:31
    Harprit wrote: »
    @ kuroneko

    I got out my demo board and ran your program.
    I eliminated the last two lines of your program as I could not understand what they did.
    I still works but I wondered of I had missed something. Did I do it right?
    Can one say that the RES area has to list all variables that will be used in the program and
    that all constants have to be listed as " value long 2000" which means that these are
    the equivalent of the VAR and CON areas of a SPIN program?

    I really appreciate your crisp input.


    Though I intend to learn to use a debugger later on, I am not sure that they are useful beginner's tools.
    Too long a learning curve to allow them to use them effectively in the beginning stages.
    Besides they want to learn PASM not debuggers. I think that comes later.
    I may change my mind and (at this stage) I may well be wrong.
    I say this because with all its mistakes in it, beginners still like my very simple SPIN book very much.
    The criticisms are from people who already know SPIN rather well, but then the book is not for them!
    I would like the PASM book to be similarly received.


    Yes, debuggers do have a learning curve. Which in my own experience is why I try to find a way to learn it early. If I can not probe or scope what is going on, then I am only guessing in the dark. And anyhow, no matter the scope or LSA you may own or have access to, it can not track the internal workings of your logic. Only a good trace can do that. You should consider using debugging along with your example code so that anyone wanting to actually follow the flow of the logic and its effects can see clearly what happens at each step in the trace. This will also serve to enhance the understanding of "unexpected features". Debugging is in many ways similar to the thought process of troubleshooting a misbehaving system.
Sign In or Register to comment.