I just included the code up to the point of setting TRISA. Afterwords, I clear the RP0 bit to go back to bank0. When I'd try to set this bit to a 1 in the TRISA register, the "Special Function Registers" window in MPLAB IDE showed TRISA to have a zero in this bit after excecuting the command to "movwf TRISA". Later in the code, I tried to read the bit from PORTA in bank0 and it was zero after Firing the asynchronous toggle to set it high. I ended up giving up on this pin for now, but I really like the idea of doing the timeslicing that rtstofer uses. Thanks for all the suggestions from everybody. Tom --- In , "Stephen D. Barnes" <stephendbarnes@h...> wrote: > According to what you state below, you are attempting to > read the TRISA register. Read Chad Russel's reply and make > sure you are reading PORTA, bit 5 and not TRISA, bit 5. > > Regards, > Stephen D. Barnes > > That would be fine and my plan, but how do i set pin 5 up > to receive > the input? No matter what I do, TRISA bit 5 stays 0 and > stimuli > applied to pin 5 in simulator do not affect the state that > is being > polled? It's as if something is locking it out from being > an input > port. > > Thanks, > Tom > > --- In , "rtstofer" <rstofer@p...> > wrote: > > > > RA5 is not a bidirectional I/O pin - see Table 5-1. In > your > > __CONFIG you turned off MCLR' so the pin is a digital > input. > > > > > > --- In , "tom_bihn" <tbihn@n...> > wrote: > > > I'm using the following line to configure the bits in > the pic: > > > __CONFIG _INTRC_OSC_NOCLKOUT & _WDT_OFF & _PWRTE_ON & > _CP_OFF & > > > _BODEN_OFF & _MCLRE_OFF > > > > > > Here is the code used up to the point that I'm writing > TRISA reg. > > > > > > clrf PORTA > > > clrf PORTB > > > movlw 0x07 > > > movwf cmcon > > > bsf STATUS,RP0 > > > movlw 5 > > > movwf OPTION_REG > > > movlw 0x20 > > > movwf TRISA > > > > > > After the last command listed, the TRISA register is > clear. I > > can't > > > seem to locate any information on why RA5 would not go > to a 1. > The > > > spec sheet did specify that it would default as a "1" > in TRISA > no > > > matter what, but when I tried a btfss PORTA,5 and > simulated an > > > asynchronous toggle in mplab simulator, it was > indicated as > clear > > > regardless of the state of the stimulus input. > > > > > > Thanks, > > > Tom > Yahoo! Groups Sponsor > > to unsubscribe, go to http://www.yahoogroups.com and > follow the instructions > > Your use of Yahoo! Groups is subject to the Yahoo! Terms > of Service.

According to what you state below, you are attempting to read the TRISA register. Read Chad Russel's reply and make sure you are reading PORTA, bit 5 and not TRISA, bit 5.

Regards,
Stephen D. Barnes

That would be fine and my plan, but how do i set pin 5 up to receive the input? No matter what I do, TRISA bit 5 stays 0 and stimuli applied to pin 5 in simulator do not affect the state that is being polled? It's as if something is locking it out from being an input port. Thanks, Tom --- In p...@yahoogroups.com, "rtstofer" <rstofer@p...> wrote: > > RA5 is not a bidirectional I/O pin - see Table 5-1. In your > __CONFIG you turned off MCLR' so the pin is a digital input.> --- In p...@yahoogroups.com, "tom_bihn" <tbihn@n...> wrote: > > I'm using the following line to configure the bits in the pic: > > __CONFIG _INTRC_OSC_NOCLKOUT & _WDT_OFF & _PWRTE_ON & _CP_OFF & > > _BODEN_OFF & _MCLRE_OFF > > > > Here is the code used up to the point that I'm writing TRISA reg. > > > > clrf PORTA > > clrf PORTB > > movlw 0x07 > > movwf cmcon > > bsf STATUS,RP0 > > movlw 5 > > movwf OPTION_REG > > movlw 0x20 > > movwf TRISA > > > > After the last command listed, the TRISA register is clear. I > can't > > seem to locate any information on why RA5 would not go to a 1. The > > spec sheet did specify that it would default as a "1" in TRISA no > > matter what, but when I tried a btfss PORTA,5 and simulated an > > asynchronous toggle in mplab simulator, it was indicated as clear > > regardless of the state of the stimulus input. > > > > Thanks, > > Tom

to unsubscribe, go to http://www.yahoogroups.com and follow the instructions

">Yahoo! Terms of Service.

I usualy use a 16F877 because it has a lot of pins. This allows me to use various outputs to signal events within the software. I can look at the bits with LEDs, a logic probe or a scope. I often set an LED when the code enters a subroutine and clear it on exit. This allows me to see when it is called and how long it takes to execute. I also use serial I/O to send various messages to the PC. The other thing I like to do is partition the program into separate modules and often these are 'tasks'. I built a controller for my 15' electric boat. There are several tasks that are time sliced such as the A/D conversion, throttle, steering and LED blinking (slow when the deadman switch is inactive and fast when it is active). So, I have an array of info for each task such as RunMe(task)which, when non-zero indicates a task should be executed, Delay(task) which contains the number of ticks until the task should be scheduled and Period(task) which contains the number of ticks between execution. The 1 millisecond interrupt handler wanders through the arrays deciding which tasks are ready to go and increments RunMe(task) when true. The main code contains only initialization and dispatching. The dispatcher looks through the RunMe(task) array and if non-zero, decrements the value and calls the appropriate task code. Now I know this seems like a long way around but it really makes the coding quite modular and very simple to debug. Tasks worry about themselves, perhaps interact with some external signals or flags and then they return. I usually try to keep them down to less than the 1 mS time slice and repeat them as needed, perhaps every 10 mS but certainly a delay of up to 65535 milliseconds is achievable without a separate counter. When tasks first start they can have an initial delay - this staggers the execution: TasksInit: banksel Delay Create 0, 0, 5 ; Task 0 - Start A2D conversion Create 1, 1, 5 ; Task 1 - Get A2D result Create 2, 2, 20 ; Task 2 - Throttle handler Create 3, 3, 20 ; Task 3 - Steering handler Create 4, 4,1000 ; Task 4 - LED On Create 5, 44,1000 ; Task 5 - LED Off Create 6,504,1000 ; Task 6 - LED On if DeadmandSwitch active (low) Create 7,544,1000 ; Task 7 - LED Off banksel 0 return ; bank 0 selected on return The Create macro looks like this: ;Macro to set up task info in RAM Create MACRO TaskIndex,DelayTime,PeriodTime movlw LOW(DelayTime) movwf Delay+TaskIndex+TaskIndex movlw HIGH(DelayTime) movwf Delay+TaskIndex+TaskIndex+1 movlw LOW(PeriodTime) movwf Period+TaskIndex+TaskIndex movlw HIGH(PeriodTime) movwf Period+TaskIndex+TaskIndex+1 clrf RunMe+TaskIndex ENDM The loop in the main code looks like this: Loop: ; process tasks Task 0,StartA2DConversion Task 1,GetA2DResult Task 2,ThrottleHandler Task 3,SteeringHandler Task 4,LEDOn Task 5,LEDOff Task 6,LEDOnDeadmanSwitch Task 7,LEDOff goto Loop and the Task macro looks like this: ;Macro to build task test and execution code Task MACRO TaskIndex,TaskName LOCAL L1 Task#v(TaskIndex): movf RunMe+TaskIndex,W bz L1 call TaskName decf RunMe+TaskIndex,F L1: ENDM Again, I know it seems like a long way around but it is quite easy to build code in modules and this makes debugging go a lot faster. More important, it is easier to prove that the code should and will work.

Thanks for taking the time to look at it.One theory I had was that maybe since applying full Vdd will put it into LVP mode, the simulator ignores a high placed on the pin in the simulator. That still won't explain why it goes to 0 unless you write FF to the TRISA after clearing all memory and doing a reset...I decided just to leave pin 5 as a nc pin for now. You say you seldom use the simulator. Do you use an ICD instead? What do you recommend for best efficiency? I'm not too concerned with cost unless it gets to be over $500. I figure if I really want to learn pics and other micros, I'll need to spend a little money at the start. Thanks for all the help, Tom --- In , "rtstofer" <rstofer@p...> wrote: > > Well, the datasheet has an apparent conflict. Example 5-1 says > TRISA.5 always reads '1' and Example 9-1 says it always reads '0'. > Table 14-8 shows the bit as not just uninitialized but non- > existant. In the simulator it reads '0'. > > That said, what difference does it make? No matter what you set > TRISA.5 as, so long as the comparators are shut off, PORTA.5 is > digital input. The value in TRISA is unimportant so long as PORTA > works. > > Now, as to getting the stimulus to work on RA5 - I have no idea. I > messed about with it but I very seldom use the simulator. I will > use it to be certain that code segments work - like table lookup, > code pages, indexed arrays, etc. I have never used it with > stimulus - more to learn when I have time. > > --- In , "tom_bihn" <tbihn@n...> wrote: > > That would be fine and my plan, but how do i set pin 5 up to > receive > > the input? No matter what I do, TRISA bit 5 stays 0 and stimuli > > applied to pin 5 in simulator do not affect the state that is > being > > polled? It's as if something is locking it out from being an input > > port. > > > > Thanks, > > Tom > > > > --- In , "rtstofer" <rstofer@p...> wrote: > > > > > > RA5 is not a bidirectional I/O pin - see Table 5-1. In your > > > __CONFIG you turned off MCLR' so the pin is a digital input. > > > > > > > > > --- In , "tom_bihn" <tbihn@n...> wrote: > > > > I'm using the following line to configure the bits in the pic: > > > > __CONFIG _INTRC_OSC_NOCLKOUT & _WDT_OFF & _PWRTE_ON & _CP_OFF > & > > > > _BODEN_OFF & _MCLRE_OFF > > > > > > > > Here is the code used up to the point that I'm writing TRISA > reg. > > > > > > > > clrf PORTA > > > > clrf PORTB > > > > movlw 0x07 > > > > movwf cmcon > > > > bsf STATUS,RP0 > > > > movlw 5 > > > > movwf OPTION_REG > > > > movlw 0x20 > > > > movwf TRISA > > > > > > > > After the last command listed, the TRISA register is clear. I > > > can't > > > > seem to locate any information on why RA5 would not go to a 1. > > The > > > > spec sheet did specify that it would default as a "1" in TRISA > > no > > > > matter what, but when I tried a btfss PORTA,5 and simulated an > > > > asynchronous toggle in mplab simulator, it was indicated as > > clear > > > > regardless of the state of the stimulus input. > > > > > > > > Thanks, > > > > Tom

I always look at the pin schematics. Microchip does not always spell out every little nuance. If TRISA bit RA5 is set to one, the input is tied low. If set to zero, the input is tied to the input latch. Chad --- tom_bihn <> wrote: > That would be fine and my plan, but how do i set pin 5 up to receive > the input? No matter what I do, TRISA bit 5 stays 0 and stimuli > applied to pin 5 in simulator do not affect the state that is being > polled? It's as if something is locking it out from being an input > port. > > Thanks, > Tom > > --- In , "rtstofer" <rstofer@p...> wrote: > > > > RA5 is not a bidirectional I/O pin - see Table 5-1. In your > > __CONFIG you turned off MCLR' so the pin is a digital input. > > > > > > --- In , "tom_bihn" <tbihn@n...> wrote: > > > I'm using the following line to configure the bits in the pic: > > > __CONFIG _INTRC_OSC_NOCLKOUT & _WDT_OFF & _PWRTE_ON & _CP_OFF & > > > _BODEN_OFF & _MCLRE_OFF > > > > > > Here is the code used up to the point that I'm writing TRISA reg. > > > > > > clrf PORTA > > > clrf PORTB > > > movlw 0x07 > > > movwf cmcon > > > bsf STATUS,RP0 > > > movlw 5 > > > movwf OPTION_REG > > > movlw 0x20 > > > movwf TRISA > > > > > > After the last command listed, the TRISA register is clear. I > > can't > > > seem to locate any information on why RA5 would not go to a 1. > The > > > spec sheet did specify that it would default as a "1" in TRISA > no > > > matter what, but when I tried a btfss PORTA,5 and simulated an > > > asynchronous toggle in mplab simulator, it was indicated as > clear > > > regardless of the state of the stimulus input. > > > > > > Thanks, > > > Tom __________________________________

Well, the datasheet has an apparent conflict. Example 5-1 says TRISA.5 always reads '1' and Example 9-1 says it always reads '0'. Table 14-8 shows the bit as not just uninitialized but non- existant. In the simulator it reads '0'. That said, what difference does it make? No matter what you set TRISA.5 as, so long as the comparators are shut off, PORTA.5 is digital input. The value in TRISA is unimportant so long as PORTA works. Now, as to getting the stimulus to work on RA5 - I have no idea. I messed about with it but I very seldom use the simulator. I will use it to be certain that code segments work - like table lookup, code pages, indexed arrays, etc. I have never used it with stimulus - more to learn when I have time. --- In , "tom_bihn" <tbihn@n...> wrote: > That would be fine and my plan, but how do i set pin 5 up to receive > the input? No matter what I do, TRISA bit 5 stays 0 and stimuli > applied to pin 5 in simulator do not affect the state that is being > polled? It's as if something is locking it out from being an input > port. > > Thanks, > Tom > > --- In , "rtstofer" <rstofer@p...> wrote: > > > > RA5 is not a bidirectional I/O pin - see Table 5-1. In your > > __CONFIG you turned off MCLR' so the pin is a digital input. > > > > > > --- In , "tom_bihn" <tbihn@n...> wrote: > > > I'm using the following line to configure the bits in the pic: > > > __CONFIG _INTRC_OSC_NOCLKOUT & _WDT_OFF & _PWRTE_ON & _CP_OFF & > > > _BODEN_OFF & _MCLRE_OFF > > > > > > Here is the code used up to the point that I'm writing TRISA reg. > > > > > > clrf PORTA > > > clrf PORTB > > > movlw 0x07 > > > movwf cmcon > > > bsf STATUS,RP0 > > > movlw 5 > > > movwf OPTION_REG > > > movlw 0x20 > > > movwf TRISA > > > > > > After the last command listed, the TRISA register is clear. I > > can't > > > seem to locate any information on why RA5 would not go to a 1. > The > > > spec sheet did specify that it would default as a "1" in TRISA > no > > > matter what, but when I tried a btfss PORTA,5 and simulated an > > > asynchronous toggle in mplab simulator, it was indicated as > clear > > > regardless of the state of the stimulus input. > > > > > > Thanks, > > > Tom

That would be fine and my plan, but how do i set pin 5 up to receive the input? No matter what I do, TRISA bit 5 stays 0 and stimuli applied to pin 5 in simulator do not affect the state that is being polled? It's as if something is locking it out from being an input port. Thanks, Tom --- In , "rtstofer" <rstofer@p...> wrote: > > RA5 is not a bidirectional I/O pin - see Table 5-1. In your > __CONFIG you turned off MCLR' so the pin is a digital input. > --- In , "tom_bihn" <tbihn@n...> wrote: > > I'm using the following line to configure the bits in the pic: > > __CONFIG _INTRC_OSC_NOCLKOUT & _WDT_OFF & _PWRTE_ON & _CP_OFF & > > _BODEN_OFF & _MCLRE_OFF > > > > Here is the code used up to the point that I'm writing TRISA reg. > > > > clrf PORTA > > clrf PORTB > > movlw 0x07 > > movwf cmcon > > bsf STATUS,RP0 > > movlw 5 > > movwf OPTION_REG > > movlw 0x20 > > movwf TRISA > > > > After the last command listed, the TRISA register is clear. I > can't > > seem to locate any information on why RA5 would not go to a 1. The > > spec sheet did specify that it would default as a "1" in TRISA no > > matter what, but when I tried a btfss PORTA,5 and simulated an > > asynchronous toggle in mplab simulator, it was indicated as clear > > regardless of the state of the stimulus input. > > > > Thanks, > > Tom

RA5 is not a bidirectional I/O pin - see Table 5-1. In your __CONFIG you turned off MCLR' so the pin is a digital input. --- In , "tom_bihn" <tbihn@n...> wrote: > I'm using the following line to configure the bits in the pic: > __CONFIG _INTRC_OSC_NOCLKOUT & _WDT_OFF & _PWRTE_ON & _CP_OFF & > _BODEN_OFF & _MCLRE_OFF > > Here is the code used up to the point that I'm writing TRISA reg. > > clrf PORTA > clrf PORTB > movlw 0x07 > movwf cmcon > bsf STATUS,RP0 > movlw 5 > movwf OPTION_REG > movlw 0x20 > movwf TRISA > > After the last command listed, the TRISA register is clear. I can't > seem to locate any information on why RA5 would not go to a 1. The > spec sheet did specify that it would default as a "1" in TRISA no > matter what, but when I tried a btfss PORTA,5 and simulated an > asynchronous toggle in mplab simulator, it was indicated as clear > regardless of the state of the stimulus input. > > Thanks, > Tom

I'm using the following line to configure the bits in the pic: __CONFIG _INTRC_OSC_NOCLKOUT & _WDT_OFF & _PWRTE_ON & _CP_OFF & _BODEN_OFF & _MCLRE_OFF Here is the code used up to the point that I'm writing TRISA reg. clrf PORTA clrf PORTB movlw 0x07 movwf cmcon bsf STATUS,RP0 movlw 5 movwf OPTION_REG movlw 0x20 movwf TRISA After the last command listed, the TRISA register is clear. I can't seem to locate any information on why RA5 would not go to a 1. The spec sheet did specify that it would default as a "1" in TRISA no matter what, but when I tried a btfss PORTA,5 and simulated an asynchronous toggle in mplab simulator, it was indicated as clear regardless of the state of the stimulus input. Thanks, Tom