PIC10F322 AD Project in Assembly, RS232

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

Re: PIC10F322 AD Project in Assembly, RS232

Postby Olin Lathrop » Sat Sep 06, 2014 10:18 pm

MMcLaren wrote:You're welcome to try again if you'd like, Olin. Here's the original post that I assumed you were trying to argue;

MMcLaren wrote:I haven't come across a compelling or authoritative premise to support a conclusion that CBLOCK shouldn't be used in non-relocatable programs.


I'm discussing how to write good PIC code. The archaic absolute mode has no place in that since you shouldn't be using it in the first place. Arguing about how to write "good" absolute mode code is pointless. It's like discussing whether you should be wearing cotton or wool socks when jumping off a tall cliff.

Anyone wanting to write good PIC code has to first forget about absolute mode and not look back. Then we can talk about other points that aren't even available in absolute mode, like RES. Arbitrarily saying you're not going to use a particular feature is just silly, especially when it's the number 1 most important feature for enabling good coding. Do it for religious reasons or do it just because you want to, but then don't try to argue it's merits or try to make it sound acceptable somehow to others.
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 » Mon Sep 08, 2014 7:31 am

Olin Lathrop wrote:
MMcLaren wrote:You're welcome to try again if you'd like, Olin. Here's the original post that I assumed you were trying to argue;

MMcLaren wrote:I haven't come across a compelling or authoritative premise to support a conclusion that CBLOCK shouldn't be used in non-relocatable programs.


I'm discussing how to write good PIC code.

Well, good for you. Unfortunately, it's not a discussion that I engaged willingly so please stop quoting my statement and directing your posts to me. My statement doesn't appear to have anything in common with your discussion. My statement suggests that if people are using non-relocatable programs it's perfectly acceptable to use CBLOCK in them. The statement is reasonably concise. Your statements reflect quite the opposite; "Why are you using CBLOCK? That's poor programming practice.". When someone points out that CBLOCK is perfectly acceptable when used in a non-relocatable program, you come up with a puzzling out-of-context response. I can imagine you thinking; "Darn, this guy has nerve. Of course he's right in that context. What the heck, I'm pretty good at exaggeration, deflection, changing context, making stuff up, and putting anyone who questions my authority on the defensive. I'll just ignore his context and fill a page with all the reasons why you should use RES in relocatable programs without mentioning the word 'relocatable'." When you get called on context you simply change context again; "Forget what I said about CBLOCK. What I meant to say is why is he using non-relocatable programs? That's bad programming practice. It's your fault you don't know what we're talking about. And you should be ashamed of yourself for promoting the use of non-relocatable programs and the merits of CBLOCK". Of course, I did neither, but that doesn't matter because you're deflecting. Your credibility doesn't get any better when you criticize the placement of subroutines in a guys 12-bit core program. What kind of "expert" doesn't know the 10F322 is a 14-bit core device? And if you didn't know I would think that seeing a "return" instruction would have given you a clue (if you had spent more than five seconds looking at the program).

Many of your comments and criticism appear to be hasty, poorly conceived, exaggerated, more opinion than fact, or misleading, with whimsical ever changing context to fit your needs. My non-expert advice... Don't be hasty. Take the time needed for thoughtful (context) qualified responses. No one will accept your advice as expert or authoritative if you've flittered away the credibility it requires. Finally, you can't defend a conclusion that's too vague or divine a conclusion to be true without evidence or proof.
MMcLaren
 
Posts: 18
Joined: Sun Aug 31, 2014 10:08 pm
PIC experience: Experienced Hobbyist

Re: PIC10F322 AD Project in Assembly, RS232

Postby vloki » Mon Sep 08, 2014 12:04 pm

This discussion is really absurd.
We may like or dislike Olin's attitude, but IMO he is definitely right!
Forget all that absolute coding stuff like ORG, CBLOCK ... It is antiquated.

(I hope once I may be able to convince the professor at my university about that ;-)
vloki
Verified identity
 
Posts: 166
Joined: Wed May 28, 2014 8:42 am
Location: Germany
PIC experience: Professional 5+ years with MCHP products

Re: PIC10F322 AD Project in Assembly, RS232

Postby Olin Lathrop » Mon Sep 08, 2014 12:55 pm

MMcLaren wrote:My statement suggests that if people are using non-relocatable programs it's perfectly acceptable to use CBLOCK in them. The statement is reasonably concise.

And my statement is that you should never use absolute mode in the first place, and then use RES to define variables. That is concise too.

When you get called on context you simply change context again; "Forget what I said about CBLOCK. What I meant to say is why is he using non-relocatable programs? That's bad programming practice.

I'm sorry I wasn't clear enough originally. To me absolute mode is a ancient relic, and using RES instead of CBLOCK to define variables so clearly implies absolute mode, that I forgot to explicitly mention it originally. I sometimes forget that there are still people out there that write in absolute mode. My bad.

Go back to where I say that CBLOCK is bad programming and that you should use RES instead, and insert "which of course means you must use relocatable mode", then maybe my original statements will make more sense to you.

"... And you should be ashamed of yourself for promoting the use of non-relocatable programs and the merits of CBLOCK".

Exactly. You understand my point quite well now.

What kind of "expert" doesn't know the 10F322 is a 14-bit core device?

Yes, my mistake. There are a lot of new PICs that keep coming out. I hadn't realized until this thread that there was a 10F that used the 14 bit core. That's actually pretty cool.

... more opinion than fact

I listed several distinct advantages of RES over CBLOCK. Ignoring them doesn't make them go away. And saying that it's OK to use CBLOCK because you're using absolute mode is not acceptable. To be clear and concise:

Don't use absolute mode, and use RES to define 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 MMcLaren » Mon Sep 08, 2014 4:59 pm

I'm sorry I wasn't clear enough originally. To me absolute mode is a ancient relic, and using RES instead of CBLOCK to define variables so clearly implies absolute mode, that I forgot to explicitly mention it originally. I sometimes forget that there are still people out there that write in absolute mode. My bad.

Apology accepted. Thank you. I think you meant to say using RES instead of CBLOCK implies relocatable mode. You shouldn't blame people for not knowing what you mean or questioning what you mean when you excuse your conclusion with "I wasn't clear", "I forgot to mention", and "I sometimes forget". That's sloppy, unprofessional, and it diminishes your credibility.

I agree with your opinion that absolute mode is a relic. Can it be outlawed or quietly retired? I doubt it. Too many people still use absolute mode for whatever reason.

Go back to where I say that CBLOCK is bad programming and that you should use RES instead, and insert "which of course means you must use relocatable mode", then maybe my original statements will make more sense to you.

Why should I have to insert something into your conclusion? That's ridiculous. It's your faulty unqualified conclusion, not mine (lol). Man up and stop trying to blame someone else for not being a mind reader (lol).

... And you should be ashamed of yourself for promoting the use of non-relocatable programs and the merits of CBLOCK".

Exactly. You understand my point quite well now.

If your point has something to do with shifting blame then, yes, I think I have a handle on it (grin).

Olin Lathrop wrote:To be clear and concise:

That is the lesson to be learned. I hope it sticks.

May I make a simple suggestion? Why not go back and edit your original post to say what you really meant to say? That is, now that you remember people are still using absolute mode and that the program in question was absolute mode, why not politely suggest that using relocatable mode with all the advantages of the Linker and RES directive might be a better way to go. You should also probably edit out the criticism of subroutine placement in 12-bit core devices. Then you and I can delete all these silly subsequent messages and your reputation and credibility will be none the worse for wear.

Cheerful regards, Mike

<added>
Thank you for not bringing up your old "flipping hamburgers at McDonalds" anecdote.
Last edited by MMcLaren on Mon Sep 08, 2014 6:07 pm, edited 1 time 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 Olin Lathrop » Mon Sep 08, 2014 5:50 pm

MMcLaren wrote:... why not politely suggest that using relocatable mode with all the advantages of the Linker and RES directive might be a better way to go.

Using absolute mode or CBLOCK for defining variables is just plain stupid, irresponsible, and a bad example to put out there where others new to this might get the impression that it is acceptable somehow. Anyone that does so needs to be very publicly and visibly piled on and the example rebutted in the firmest possible way. This issue has been discussed plenty often enough for many years in many places, so there is no excuse. If someone feels insulted and embarassed as a result, OK. If they don't want to be treated like a moron next time, they shouldn't be a moron next time. If they throw a tantrum, oh well, that only reflects badly on them anyway.
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 » Mon Sep 08, 2014 7:00 pm

Olin Lathrop wrote:
MMcLaren wrote:... why not politely suggest that using relocatable mode with all the advantages of the Linker and RES directive might be a better way to go.

Using absolute mode or CBLOCK for defining variables is just plain stupid, irresponsible, and a bad example to put out there where others new to this might get the impression that it is acceptable somehow. Anyone that does so needs to be very publicly and visibly piled on and the example rebutted in the firmest possible way. This issue has been discussed plenty often enough for many years in many places, so there is no excuse. If someone feels insulted and embarassed as a result, OK. If they don't want to be treated like a moron next time, they shouldn't be a moron next time. If they throw a tantrum, oh well, that only reflects badly on them anyway.

My goodness, that's quite a tantrum, and deservedly so. Now we know how you really feel. Why did you hold this back? Why didn't you just say this in your original post? It would have saved a lot of time. Of course you're absolutely right and I'm with you 100%. These absolute code blasphemers are ruining society and we need to do something about it. You know, maybe we can form a cult, and you should be leader and defender of the faith. Man, we're gonna need an oath... and an initiation. Maybe we could form an alliance with NSA and they could force Microchip to install something in each device that would emit a signal when running absolute code. That would make it a lot easier for us to track down and deal with the blasphemers. Man, I'm excited to meet another brother of the cause. So much work ahead of us.

Hiel Olin...
MMcLaren
 
Posts: 18
Joined: Sun Aug 31, 2014 10:08 pm
PIC experience: Experienced Hobbyist

Re: PIC10F322 AD Project in Assembly, RS232

Postby vloki » Mon Sep 08, 2014 7:33 pm

Hiel ?
vloki
Verified identity
 
Posts: 166
Joined: Wed May 28, 2014 8:42 am
Location: Germany
PIC experience: Professional 5+ years with MCHP products

Re: PIC10F322 AD Project in Assembly, RS232

Postby viki2000 » Wed May 04, 2016 2:56 pm

Here is the full working tested code in ASM for 10F322 about ADC from here:
http://www.microchip.com/forums/m881560-p3.aspx
It is written by Dan, not by me.
It reads internal temperature sensor value of 10F322 and fixed voltage reference and using a software UART sends data to PC to a serial terminal:
Code: Select all
;
; File: main.asm
; Target: PIC10F322
; IDE: MPLABX 3.05
; Assembler: MPASM v5.62
;
; Additional files:
;   P10F322.INC
;   10F322_g.lkr
;
; Description:
;   
;   Demo application to show reading the PIC10F322 ADC on
;   two channels, FVR and Temp Indicator.
;   
;   System clock is the Fast Internal Oscillator at 8MHz.
;
;   Default baud rate is 9600.
;
;   Wait for serial input on PORTA bit 1, the PGC pin.
;   The default ADC report display is about once per second.
;
;   When a byte is received it is checked for these characters:
;
;     'A' ADC display ON/OFF
;     '6' ADC in TI
;     '7' ADC in FVR
;     '?' show this message
;
;   Note: Characters are case sensitive and are UPPER CASE.
;
;   Data is sent using a bit-bang UART on PORTA bit 0, PGD.
;
;   Using the PGD/PGC pins for a TTL serial interface allows
;   the use of a PICkit2 as a serial to USB interface. The
;   PICkit2 does not support programming the PIC10F322.
;
    list      p=10F322            ; list directive to define processor
    #include <p10F322.inc>        ; processor specific variable definitions
     
    __CONFIG   _WRT_OFF & _BORV_24 & _LPBOR_OFF & _LVP_OFF & _CP_OFF & _MCLRE_ON & _PWRTE_OFF & _WDTE_OFF & _BOREN_OFF & _FOSC_INTOSC

    list    r=dec
    errorlevel -302

#define FOSC (8000000)
#define FCYC (FOSC/4)

; With an 8MHz oscillator the low end
; of range is limited to 9600 baud.
; The fastest reliable is 38400 baud.
#define BAUD (9600)
#define T0_RELOAD (256-(FCYC/BAUD))

#define ADC_DELAY_COUNT (50000)

RESET_VECTOR CODE  0x000
        goto    start

ISR_DATA    UDATA
WREG_SAVE   res     1
STATUS_SAVE res     1
PCLATH_SAVE res     1
;
; Application wide status flags
App_Status  res     1
#define RX_DataAvailable App_Status,1
#define RX_FamingError App_Status,2
#define RX_OverrunError App_Status,3
#define ADC_Sample App_Status,4
#define ADC_Show_Sample App_Status,5
;
; Serial data
TX_Data     res     1
RX_Data     res     1
UART_State  res     1

#define TX_START    (11)
#define RX_START    (16)
#define TXD_BIT     LATA,0
#define RXD_BIT     PORTA,1
;
; Interrupt vector
;
ISR_VECTOR  CODE    0x004
        movwf   WREG_SAVE
        movf    STATUS,W
        clrf    STATUS
        movwf   STATUS_SAVE
        movf    PCLATH,W
        movwf   PCLATH_SAVE
        clrf    PCLATH
;
; TIMER0 ISR
;   This is a bit banged half duplex UART
;
; Note:
;   The TIMER0 interrupt uses a PC relative
;   jump table to process the transmitter state.
;   This jump table must be within a 256 byte
;   program memory page.
;
ISR_TMR0:
        btfsc   INTCON,TMR0IE
        btfss   INTCON,TMR0IF
        goto    ISR_TMR0_Exit

        bcf     INTCON,TMR0IF
        movlw   T0_RELOAD+3
        addwf   TMR0,F

        decfsz  UART_State,W      ; skip if transmitter is empty
        goto    UART_DoState
;
; TX empty
;
TX_State_0:
        bcf     INTCON,TMR0IE     ; Disable interrupt when TX empty
;
; Stop bit
;
TX_State_1:
        bsf     TXD_BIT
        goto    ISR_Exit

UART_DoState:
        andlw   0x0F            ; This prevents a crash but does not prevent
        movwf   UART_State      ; data errors when UART_state is corrupted.
        addwf   PCL,F
        goto    TX_State_0      ; TX empty
        goto    TX_State_1      ; stop
        goto    TX_State_2      ; data 7
        goto    TX_State_3      ; data 6
        goto    TX_State_4      ; data 5
        goto    TX_State_5      ; data 4
        goto    TX_State_6      ; data 3
        goto    TX_State_7      ; data 2
        goto    TX_State_8      ; data 1
        goto    TX_State_9      ; data 0
        goto    TX_State_10     ; start
        goto    TX_State_1      ; stop
        goto    TX_State_1      ; stop
        goto    TX_State_1      ; stop
        goto    RX_State_0      ; RX Stop bit
        goto    RX_State_1      ; RX Data bit
;
; Start bit
;
TX_State_10:
        bcf     TXD_BIT
        goto    ISR_Exit
;
; Data bits
;
TX_State_9:
TX_State_8:
TX_State_7:
TX_State_6:
TX_State_5:
TX_State_4:
TX_State_3:
TX_State_2:
        btfss   TX_Data,0
        bcf     TXD_BIT
        btfsc   TX_Data,0
        bsf     TXD_BIT
        rrf     TX_Data,F
        goto    ISR_Exit
;
; RX Stop bit
;
RX_State_0:
        btfss   RXD_BIT         ; Skip if stop bit present
        bsf     RX_FamingError
        btfsc   RX_DataAvailable ; Skip if data buffer available
        bsf     RX_OverrunError
        bsf     RX_DataAvailable ; Assert new data arrived
        bcf     INTCON,TMR0IE     ; Disable interrupt when RX complete
        goto    ISR_Exit
;
; RX Data bit
;
RX_State_1:
        btfsc   RXD_BIT         ; CARRY always zero when state starts
        setc                    ; Set CARRY if RX data is ZERO
        rrf     RX_Data,F       ; Shift in bit
        skpc                    ; CARRY is set when all 8 bits arrived
        incf    UART_State,F    ; Stay in RX data bit state until byte received
        goto    ISR_Exit
ISR_TMR0_Exit:

;
; Interrupt On Change ISR
;   This is a bit banged UART receive start bit
ISR_IOC:
        btfsc   INTCON,IOCIE
        btfss   INTCON,IOCIF
        goto    ISR_IOC_Exit

        movf    PORTA,W         ; Clear miss match
        clrf    IOCAF           ; Clear IOC assert
        btfsc   RXD_BIT         ; Skip if RXD is a Start Bit (LOW)
        goto    ISR_Exit

        movlw   T0_RELOAD+30    ; Add start bit ISR overhead
        movwf   TMR0
        bcf     INTCON,TMR0IF
        bsf     INTCON,TMR0IE

        movlw   0x80            ; Set to receive 8 bits of RX data
        movwf   RX_Data
        movlw   RX_START        ; Set UART to receive data bits state
        movwf   UART_State
        bcf     INTCON,IOCIE    ; Disable RX start bit interrupt

        goto    ISR_Exit
ISR_IOC_Exit:
;
; Handle ADC interrupt
;
ISR_ADC:
        btfss   PIE1,ADIE       ; must be enabled to wake from sleep
        goto    ISR_ADC_Exit

        btfss   PIR1,ADIF       ; must be enabled to wake from sleep
        goto    ISR_ADC_Exit
        bcf     PIR1,ADIF
        btfss   ADC_Sample
        bsf     ADC_Sample
        goto    ISR_Exit
ISR_ADC_Exit:

ISR_Exit:
        movf    PCLATH_SAVE,W
        movwf   PCLATH
        movf    STATUS_SAVE,W
        movwf   STATUS
        swapf   WREG_SAVE,F
        swapf   WREG_SAVE,W
        retfie
;
; PutC
;   put a character out serial port
;
Putc:
        btfsc   INTCON,TMR0IE     ; skip when UART not busy
        goto    Putc
        bcf     INTCON,IOCIE    ; cannot receive when sending

        movwf   TX_Data
        movlw   TX_START        ; select UART start send state
        movwf   UART_State

        movlw   T0_RELOAD
        movwf   TMR0
        bcf     INTCON,TMR0IF
        bsf     INTCON,TMR0IE
        return
;
; Wait for UART transmit to complete
;
WaitForSend:
        btfsc   INTCON,TMR0IE     ; skip when UART not busy
        goto    WaitForSend

        return
;
; Put HEX nibble
;
PutHexNibble:
        call    GetHexChar
        call    Putc
        return
;
; Look up ASCII character to low 4-bits in W
; Input: HEX nibble low 4-bits of W
; Output: W = ASCII character of HEX value
;
GetHexChar:
        andlw   0x0F
        movwf   PCLATH
        xorlw   HIGH(HexTable)
        xorwf   PCLATH,F
        xorlw   HIGH(HexTable)
        addlw   LOW(HexTable)
        skpnc
        incf    PCLATH,F
        movwf   PCL
HexTable:
        DT      '0','1','2','3','4','5','6','7'
        DT      '8','9','A','B','C','D','E','F'
PUTS_DATA UDATA
prString    res 2
RPUTS_CODE CODE
;
; Print an ASCII zero terminated sring from CODE space
;
rPuts:
    movf    prString+1,W
    iorwf   prString,W
    skpnz
    return
    call    rPutsGetChar
    iorlw   0
    skpnz
    return
    call    Putc
    incf    prString,F
    skpnz
    incf    prString+1,F
    goto    rPuts
;
; Fetch a character from CODE space
;
rPutsGetChar:
    movf    prString+1,W
    movwf   PCLATH
    movf    prString,W
    movwf   PCL
;
; Main application data
;
MAIN_DATA    UDATA
;
; ADC data
ADC_Value   res     1
;
; Process ADC delay
ADC_Delay   res     2
;
;
;
MAIN_CODE CODE
;
; Do a very simple command processor
;
ProcessCharacter:
        bcf     RX_DataAvailable

        movlw   'A'             ; see if it is a toggle ADC display request
        xorwf   RX_Data,W
        skpnz
        call    ToggleAdcDisplay

        movlw   '6'             ; see if it is a select ADC channel Temperature Input
        xorwf   RX_Data,W
        movlw   B'00011000'     ; Select Temp Indicator as ADC input
        skpnz
        call    SetADC_Channel

        movlw   '7'             ; see if it is a select ADC channel Fixed Voltage Reference
        xorwf   RX_Data,W
        movlw   B'00011100'     ; Select FVR as ADC input
        skpnz
        call    SetADC_Channel
;
; This must be here and must be the last input checked
;
        movlw   '?'             ; see if it is a usage request
        xorwf   RX_Data,W
        skpz
        goto    EnableStartBitDetect

ShowSignOnMessage:
        movlw   LOW(PowerOnMessage)
        movwf   prString
        movlw   HIGH(PowerOnMessage)
        movwf   prString+1
        call    rPuts
        call    WaitForSend
;
; Enable RX start bit detect
;
EnableStartBitDetect:
        movf    PORTA,W
        bcf     INTCON,IOCIF
        bsf     INTCON,IOCIE
        return
;
; Select ADC channel
;
SetADC_Channel:
        bcf     PIE1,ADIE   ; disable ADC interrupt for channel change
       
        xorwf   ADCON,W
        andlw   B'00011100' ; Channel select mask
        xorwf   ADCON,F

        bsf     PIE1,ADIE   ; enable ADC interrupt

        return
;
; Turn the ADC display on or off
;
ToggleAdcDisplay:
        clrc
        btfss   ADC_Show_Sample
        setc
        skpc
        bcf     ADC_Show_Sample
        skpnc
        bsf     ADC_Show_Sample
        return
;
; Process ADC sample
;
ProcessAdcSample:
        btfsc   ADCON,GO_NOT_DONE ; Skip if ADC conversion is complete
        return
;
; Delay between ADC outputs because
; if we send too fast the UART receiver
; gets no cycles to detect a start bit.
;
        movf    ADC_Delay,W
        iorwf   ADC_Delay+1,W
        skpnz
        goto    DisplayAdcSample
        decf    ADC_Delay,F
        skpnz
        decf    ADC_Delay+1,F
        return

DisplayAdcSample:
;
; Reload delay count
;
        movlw   LOW(ADC_DELAY_COUNT)
        movwf   ADC_Delay
        movlw   HIGH(ADC_DELAY_COUNT)
        movwf   ADC_Delay+1
;
; Read all 8-bits of the ADC
;
        movf    ADRES,W
        movwf   ADC_Value

        bcf     ADC_Sample          ; Clear process flag for ADC

        btfss   ADC_Show_Sample
        return

        call    ShowAdc             ; Display ADC value
        call    EnableStartBitDetect
        return
;
; Display ADC value
;
ShowAdc:
        swapf   ADC_Value,W
        call    PutHexNibble
        movf    ADC_Value,W
        call    PutHexNibble

        movlw   0x0D
        call    Putc
        movlw   0x0A
        call    Putc

        call    WaitForSend
        return
;
; Power On Reset starts here
;
start:
;
; Set internal oscillator to 8 MHz
;
        movlw   0x60
        movwf   OSCCON      ; Set internal oscillator to 8MHz

        clrf    INTCON      ; Disable interrupts
;
; Set all outputs to zero
;
        movlw   0x01
        movwf   LATA       ; Set TXD high
        clrf    TRISA
        movlw   0x07
        movwf   PORTA      ; Set TXD high

        clrf    ANSELA      ; Make all GPIOs digital I/O
        clrf    WPUA        ;
        clrf    IOCAN       ;
        clrf    IOCAP       ;
        clrf    IOCAF       ;

        movlw   0x5F        ; Set OPTION register
        movwf   OPTION_REG  ; TIMER0 clocks source is FCYC
                ; Pull-ups enabled

        clrf    PIE1        ; Disable all peripheral interrupt sources
        bcf     TRISA,0     ; Make RA0(TXD) an output
        bsf     TRISA,1     ; Make RA1(RXD) an input
        bsf     WPUA,1      ; Enable pull up on RXD (RA1)
        bsf     IOCAN,1     ; Enable interrupt on change of RXD (RA1)

;
; Initialize UART state
;
        bcf     INTCON,TMR0IE
        clrf    UART_State
;
; Initialize application status flags
;
        clrf    App_Status
;
; Setup FVR and Temp Indicator
;
        movlw   B'10110001'
        movwf   FVRCON
;
; Setup ADC
;
        bsf     PIE1,ADIE   ; must be enabled to wake from sleep
       
        movlw   B'11111000' ; Set ADC clock as FRC, select Temp Indicator as input channel
        movwf   ADCON
        bsf     ADCON,ADON
        bcf     PIR1,ADIF
        bsf     INTCON,PEIE
;
; We wake from sleep because the ADC
; interrupt request is asserted.
;
        bsf     INTCON,GIE
;
; Show the ADC value by default
;
        bsf     ADC_Show_Sample
;
; Print the power on message
;
        call    ShowSignOnMessage
;
; This is the main process loop
;
ProcessLoop:
;
; Check process flags and sleep when idle
;
        btfsc   INTCON,TMR0IE
        goto    ProcessAwake    ; do not sleep when UART is running

        btfsc   RX_DataAvailable
        goto    ProcessAwake    ; do not sleep when UART RX data is available

        btfsc   ADC_Sample
        goto    ProcessAwake    ; do not sleep when ADC is sampling

        bsf     ADCON,GO_NOT_DONE ; start an ADC conversion
        sleep                   ; sleep and wait for an interrupt
        nop
        nop
;
; Process loop is awake
;
ProcessAwake:
        btfsc   RX_DataAvailable
        call    ProcessCharacter

        btfsc   ADC_Sample
        call    ProcessAdcSample

        goto    ProcessLoop

PowerOnMessage:
        dt      "PIC10F322 Analog input demo",13,10
        dt      "Samples ADC inputs TI, FVR",13,10
        dt      "Type:",13,10
        dt      " 'A' ADC ON/OFF",13,10
        dt      " '6' ADC in TI",13,10
        dt      " '7' ADC in FVR",13,10
        dt      " '?' show this message",13,10
        dt      0
        end
viki2000
 
Posts: 5
Joined: Fri Apr 29, 2016 9:17 am
PIC experience: Experienced Hobbyist

Previous

Return to 12-Bit Core

Who is online

Users browsing this forum: No registered users and 1 guest

cron