> AD.
>
> FOR SALE:
> Hi all
>       Is anyone interested in the following
>
> RF solutions icepic-jnr-5x  emulates 12c508/509 16c52/54/55/56/57/58. #120
>
> PIC-ICD debugger/programmer for 16f87x (advanced transdata corp). #80
>
> Microchip promate programmer.#80
>
> Dataman S4 programmer. #220
>
>                                       Regards
>                               Jonathan Miller
>
> --
> http://www.piclist.com hint: To leave the PICList
> piclist-unsubscribe-requestspammitvma.mit.edu
>
> --
> http://www.piclist.com hint: To leave the PICList
> spam_OUTpiclist-unsubscribe-requestspam_OUTspam_OUTmitvma.mit.edu
>
>
>

> What prices?
>
> ----- Original Message -----
> From: "Jonathan Miller" <RemoveMEjonathan.millerspamBeGoneRemoveMEVIRGIN.NET>
> To: <KILLspamPICLISTspamBeGoneMITVMA.MIT.EDU>
> Sent: Tuesday, March 27, 2001 12:14 AM
> Subject: [PIC]:
>
>
> > AD.
> >
> > FOR SALE:
> > Hi all
> >       Is anyone interested in the following
> >
> > RF solutions icepic-jnr-5x  emulates 12c508/509 16c52/54/55/56/57/58.

> >
> > PIC-ICD debugger/programmer for 16f87x (advanced transdata corp). #80
> >
> > Microchip promate programmer.#80
> >
> > Dataman S4 programmer. #220
> >
> >                                       Regards
> >                               Jonathan Miller
> >
> > --
> > http://www.piclist.com hint: To leave the PICList
> > @spam@piclist-unsubscribe-requestSTOPspam@spam@mitvma.mit.edu> > >
> > --
> > http://www.piclist.com hint: To leave the PICList
> > piclist-unsubscribe-requestspamBeGonespamBeGonemitvma.mit.edu> > >
> >
> >
>
> --
> http://www.piclist.com hint: To leave the PICList
> spamBeGonepiclist-unsubscribe-requestmitvma.mit.edu
>
>

>> AD.
>>
>> FOR SALE:
>> Hi all
>>       Is anyone interested in the following
>>
>> RF solutions icepic-jnr-5x  emulates 12c508/509 16c52/54/55/56/57/58. #120
>>
>> PIC-ICD debugger/programmer for 16f87x (advanced transdata corp). #80
>>
>> Microchip promate programmer.#80
>>
>> Dataman S4 programmer. #220
>>
>>                                       Regards
>>                               Jonathan Miller
>>
>> --
>> http://www.piclist.com hint: To leave the PICList
>> KILLspampiclist-unsubscribe-requestspamspam_OUTmitvma.mit.edu> >>
>> --
>> http://www.piclist.com hint: To leave the PICList
>> piclist-unsubscribe-requestRemoveMEmitvma.mit.edu> >>
>>
>>

> --
> http://www.piclist.com hint: To leave the PICList
> EraseMEpiclist-unsubscribe-requestSTOPspamRemoveMEmitvma.mit.edu

>
> As a guess, from the email address and the time it was posted.......not to
> mention the values suggested, I'd say he was in the UK and they were UKP.
>
> Of course, if they are US dollars, Australian dollars or, better still,
> Italian Lire.........I'll have the S4 and the ICD!
>
> Dan
>
>
>
>
>  (Embedded     Raymond Choat <spamrc.....spamKENAI.NET>.....spamMITVMA.MIT.EDU>
>  image moved   27/03/2001 18:01
>  to file:
>  pic29421.pcx)
>
>
>
>
>
> Please respond to pic microcontroller discussion list
>       <PICLISTspam_OUT@spam@MITVMA.MIT.EDU>
> Sent by:  pic microcontroller discussion list <.....PICLISTspam.....MITVMA.MIT.EDU>
>
>
> To:   PICLISTKILLspamEraseMEMITVMA.MIT.EDU
> cc:
> Subject:  Re: [PIC]:
>
> Security Level:?         Internal
>
>
> What prices?
>
> ----- Original Message -----
> From: "Jonathan Miller" <EraseMEjonathan.miller@spam@@spam@VIRGIN.NET>
> To: <@spam@PICLISTspamKILLspamMITVMA.MIT.EDU>
> Sent: Tuesday, March 27, 2001 12:14 AM
> Subject: [PIC]:
>
>
> > AD.
> >
> > FOR SALE:
> > Hi all
> >       Is anyone interested in the following
> >
> > RF solutions icepic-jnr-5x  emulates 12c508/509 16c52/54/55/56/57/58.
> #120
> >
> > PIC-ICD debugger/programmer for 16f87x (advanced transdata corp). #80
> >
> > Microchip promate programmer.#80
> >
> > Dataman S4 programmer. #220
> >
> >                                       Regards
> >                               Jonathan Miller
> >
> > --
> > http://www.piclist.com hint: To leave the PICList
> > spamBeGonepiclist-unsubscribe-requestRemoveMEEraseMEmitvma.mit.edu> > >
> > --
> > http://www.piclist.com hint: To leave the PICList
> > RemoveMEpiclist-unsubscribe-requestKILLspamRemoveMEmitvma.mit.edu> > >
> >
> >
>
> --
> http://www.piclist.com hint: To leave the PICList
> TakeThisOuTpiclist-unsubscribe-requestmitvma.mit.edu
>
>
>
>
>

>
> what sort of MCLR circuit would you guys recommend in a noisy environment (electrically noisy).
>
> what i have right now is just MCLR tied to +5 via 10k resistor, and that works fine, but i'm getting resets every now
> and then and i suspect something on the MCLR line.  can't really look at it with a scope because my scope leads are
> picking up noise as well.
>
> i have to be able to do ICSP with whatever i end up with.
>
> thanks for your comments,
>

>I have a problem with interupts, I cannot use the call command.
>my code is as follows:
>
>         org     0x004            ; interrupt vector location
>
>         bcf     STATUS,RP0
>         bcf     STATUS,RP1
>         movwf   w_temp            ; save off current W register contents
>         movf    STATUS,0         ; move status register into W register
>         movwf   status_temp       ; save off contents of STATUS register
>
>         BCF     PCLATH,3
>         BCF     PCLATH,4
>;       call    test
>;       BSF     PCLATH,3
>;       BCF     PCLATH,4
>;       call    keypad
>
>         movf    status_temp,0     ; retrieve copy of STATUS register
>         movwf   STATUS            ; restore pre-isr STATUS register contents
>         swapf   w_temp,1
>         swapf   w_temp,0          ; restore pre-isr W register contents
>         bcf     INTCON,RBIF
>         retfie                    ; return from interrupt
>
>test
>         nop
>         return
>
>What I want to do is eventually call the keypad module. At this stage I
>cannot even call test. If the code is as is my program works (it runs
>through and initalises a LCD amongst other things.) If I unrem the call test
>line the program doesnt run - ie the LCD display doesnot get initalised.
>
>I am using the RBIF to interrupt.

>I have a problem with interupts, I cannot use the call command.
>my code is as follows:
>
>         org     0x004            ; interrupt vector location
>
>         bcf     STATUS,RP0
>         bcf     STATUS,RP1
>         movwf   w_temp            ; save off current W register contents
>         movf    STATUS,0         ; move status register into W register
>         movwf   status_temp       ; save off contents of STATUS register
>
>         BCF     PCLATH,3
>         BCF     PCLATH,4
>;       call    test
>;       BSF     PCLATH,3
>;       BCF     PCLATH,4
>;       call    keypad
>
>         movf    status_temp,0     ; retrieve copy of STATUS register
>         movwf   STATUS            ; restore pre-isr STATUS register

>         swapf   w_temp,1
>         swapf   w_temp,0          ; restore pre-isr W register contents
>         bcf     INTCON,RBIF
>         retfie                    ; return from interrupt
>
>test
>         nop
>         return
>
>What I want to do is eventually call the keypad module. At this stage I
>cannot even call test. If the code is as is my program works (it runs
>through and initalises a LCD amongst other things.) If I unrem the call

> Tnx in advance
> Fernando BArros
>
> __________
> http://www.IOL.pt
> Todo o mundo passa por aqui!
>
> --
> http://www.piclist.com hint: To leave the PICList
> RemoveMEpiclist-unsubscribe-requestRemoveMERemoveMEmitvma.mit.edu

> [PIC]:
>
> I was wondering if anybody could help me.
> I have been given the task of investigating PIC's and more specifically whether one could be used to interface a number of serial ports into ONE
> serial or USB output.
>
> I need to produce a short report on my findings, but can't seem to find any basic information about what a pic is.
>
> Any information would be gratefully received, but please bare in mind that I have no experience whatsoever with PIC's and only limited experience with
> micro's (Z180).
>
> Thanks for your time,
>
> Malcom........
>

> -----Original Message-----
> From: Joakim Ferdinandsson [@spam@joakim.ferdinandssonSTOPspamALLTRONIC.SE]
> Sent: 07 September 2001 11:29
> To: TakeThisOuTPICLISTTakeThisOuTRemoveMEMITVMA.MIT.EDU
> Subject: [PIC]:
>
>
> Hello!
>
> I have a mindbuzz.
> I am writing a code in mplab (assemblercode, not C) and have a 1 byte
> register in memory called count.
> My question is: Is there a instruction or code that moves the
> adress of
> a labelled register to the W-register or the FSR-register and not the
> value in the register. I mean something like MOVFW "LABEL" but for the
> adress to the register called "LABEL" and not the value in it.
>
> --
> http://www.piclist.com#nomail Going offline? Don't AutoReply us!
> email spam_OUTlistservspam.....mitvma.mit.edu with SET PICList DIGEST in the body
>
>

> > Doesn't Microchip make PIC's with DSP's ?
>
> Not yet.
>
>
> ********************************************************************
> Olin Lathrop, embedded systems consultant in Littleton Massachusetts
> (978) 742-9014, RemoveMEolinspamEraseMEembedinc.com, http://www.embedinc.com
>
> --
> http://www.piclist.com hint: To leave the PICList
> STOPspampiclist-unsubscribe-request.....mitvma.mit.edu
>
>
>
>

> e.g.
>
> one     call    three
>
> three   movlw   0x02       ;do something - load temp with a number
>         movwf   temp
>
> four    decfsz  temp,f     ;then do a test or comparison
>         goto    one
>
> return                     ;from the call three
>
> In the above, the return is never reached, but the calls keep stacking
> up
> Wouldn't the stack fill up with return addresses?

> Olin Lathrop wrote:
>
>>
>> > If you know the depth of your entry point you can use this
>> technique to
>> > flush the stack :-) Which can be handy if you need to abruptly exit a
>> call
>> > path.
>>
>> How is messing about with the stack more "handy" than doing a GOTO?
>>
>
> Is it really even possible to 'flush' the stack?
>
> The limited number of PIC types that I have worked with don't have any
> way
> (other than calls and returns) of affecting the stack.
>
> Do some PIC types provide direct stack pointer control?
>
> Regards, Bob
>
> _________________________________________________________________
> Get your FREE download of MSN Explorer at
> http://explorer.msn.com/intl.asp
>
> --
> http://www.piclist.com#nomail Going offline? Don't AutoReply us!
> email spamlistservmitvma.mit.edu with SET PICList DIGEST in the body
>
>
>

> up the stack.
>
> You need to be more clever than GOTO to handle abrupt exceptions in a
> deterministic fashion.
>
>
> ExceptionGenerator:
>         ;Error Detected
>         GOTO    ExceptionHandler
>         ;No Error
>         RETURN
>
> TryGOTOExceptionHandler:
>         ;try{
>                 CALL ExceptionGenerator
>                 ;Code Not Reached
>         ;}catch(Exception e){
>         ExceptionHandler:
>                 RETURN

>         ;}
>
>         RETURN
>
>
> ;=========
> MAIN
>         CALL    TryGOTOExceptionHandler
>         GOTO    MAIN

>         RETURN  ;Never Reach Here
>
> CallWithAbruptExitDepth3                        ;Build up a stack path
>         CALL    OKNowAbruptlyExitTheCallPath
>         RETURN  ;Never Reached
>
> CallWithAbruptExitDepth2
>         CALL    CallWithAbruptExitDepth3        ;Build up a stack path
>         RETURN  ;Never Reached
>
> CallWithAbruptExitDepth1
>         CALL    CallWithAbruptExitDepth2        ;Build up a stack path
>         RETURN  ;Never Reached
>
>
> CallWithRegularReturn
>         ;Code Here
>         RETURN
>
> MAIN
>         CALL    CallWithAbruptExitDepth1
> MAIN.OnException.AbruptHandler
>         CALL    CallWithRegularReturn
>
>         GOTO    MAIN
>
>         END

>
> My programmer and comparison pages can be found here:
>
> http://www.finitesite.com/d3jsys
> http://www.finitesite.com/d3jsys/16F628.html
>
> > As a very simple starting point, I thought I would just try and write any
> >command and read it back to verify it. So I follow this procedure:
> >
> > output 6 bits of 0x2 - 00 0010 (load program data)
> > output a start bit - 0
> > output 14 bits of any command
> > output a stop bit
> > output 6 bits of 0x8 - 00 1000 (cycle program command)
> > output 6 bits of 0x4 - 00 0010 (read program data command)
>
> How long did you wait between the program command and the read program data?
> For the 16F84 you must wait at least 10ms after the beginning of a write
> before you can read.
>
> If possible slow the programming down so that you can see the state of each
> bit as it's transmitted. If possible separate the input into RB7/DATA from
> the output from RB7/DATA with a switch so that you can ensure that the output
> driver comes on when you issue the read.
>
> Are you sure that you are clocking on the correct edge?
>
> There are a lot of issues when first bootstrapping your programming

>
> Not enough information to determine yet. One last question: are you hooking
> up the LED directly to the RB6/RB7 lines or do you have a buffer between the
> I/O lines and the LEDs. Because if you have the LED hooked up directly it's
> quite possible that they are screwing up your data to and from the PIC.
>
> Hope this helps,
>
> BAJ
>
> --
> http://www.piclist.com hint: PICList Posts must start with ONE topic:
> [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads
>

> > On Sun, Jul 21, 2002 at 05:45:27PM -0400, Jai Dhar wrote:
> > > HI,
> > >
> > > I'm trying to code and make my own pic programmer for a 16f84.
> >
> > Three quick comments/questions:
> >
> > 1) Is this a learning project or are you building a programmer in prep for
> > doing PIC development. If it's the latter then your time is probably better
> > spent building/using on of the many programmers and software that's
> available.
> >
> > 2) What is your hardware for programming. The algorithm may not be relevant
> > if the hardware for programming is incorrect.
> >
> > 3) (The usual for me) Have you heard of the 16F628. It's like a 16F84 but
> only
> > much, much better and much, much cheaper. And it can even help you right
> where
> > you are because the programmer for it can be simplified vs. a 16F84
> programmer.
> >
> > My programmer and comparison pages can be found here:
> >
> > http://www.finitesite.com/d3jsys
> > http://www.finitesite.com/d3jsys/16F628.html
> >
> > > As a very simple starting point, I thought I would just try and write any
> > >command and read it back to verify it. So I follow this procedure:
> > >
> > > output 6 bits of 0x2 - 00 0010 (load program data)
> > > output a start bit - 0
> > > output 14 bits of any command
> > > output a stop bit
> > > output 6 bits of 0x8 - 00 1000 (cycle program command)
> > > output 6 bits of 0x4 - 00 0010 (read program data command)
> >
> > How long did you wait between the program command and the read program data?
> > For the 16F84 you must wait at least 10ms after the beginning of a write
> > before you can read.
> >
> > If possible slow the programming down so that you can see the state of each
> > bit as it's transmitted. If possible separate the input into RB7/DATA from
> > the output from RB7/DATA with a switch so that you can ensure that the output
> > driver comes on when you issue the read.
> >
> > Are you sure that you are clocking on the correct edge?
> >
> > There are a lot of issues when first bootstrapping your programming
> algorithm.
> >
> > And as I said before if it's for a learning exercise the great! However if
> you
> > just want to get the job done, it's probably better to use someone else's
> > software.
> >
> > >
> > > After I issue the last command, I cycle the clock 16 times and monitor RB7
> > > for voltage changes, and I do'nt get anything. I know I'm sending/clocking
> > > RB6 and RB7 correctly because I have led's hooked up. What am I doing
> wrong?
> >
> > Not enough information to determine yet. One last question: are you hooking
> > up the LED directly to the RB6/RB7 lines or do you have a buffer between the
> > I/O lines and the LEDs. Because if you have the LED hooked up directly it's
> > quite possible that they are screwing up your data to and from the PIC.
> >
> > Hope this helps,
> >
> > BAJ
> >
> > --
> > http://www.piclist.com hint: PICList Posts must start with ONE topic:
> > [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads
> >
>
>
> ---------------------------------------------
> This message was sent using Endymion MailMan.
> http://www.endymion.com/products/mailman/
>
> --
> http://www.piclist.com hint: PICList Posts must start with ONE topic:
> [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads
>

> On Mon, Jul 22, 2002 at 01:01:26AM +0000, Jai Dhar wrote:
> > This is purely for learning and my own development.
>
> Cool. Just wanted to make sure that your time wouldn't be better spent in
> other phases of development.
>
> >Now, I know that I have
> > sufficient time between each pulse since I have it clocking on 1 second
> > intervals.
>
> OK.
>
> > I am using a 16f84 connected to D0 and D1 of a parport. I manually
> > step up the MCLR voltage to +12V before I start programming. I have also
> > monitored every D0/D1 pulse to make sure they coincide with the correct
> > instructions, and they do. So I must be sending out the wrong instructions

> > me any further?
>
> The LEDs will kill the process because they will consume all of the available
> current from the parallel port. Also you're missing another critical aspect
> which is that the RB7/DATA pin from the PIC is both an input and an output
> during the programming process. If you tie a parallel port output directly to
> pin RB7 then you'll get two very bad effects: You won't be able to read the
> RB7 output and you'll burn out the buffers on both the PIC and the parallel
> port.
>
> There's a third issue in the mix: The voltage that your parallel port