Just for practice in learning GC Basic, I whipped up a circuit to light the elements of a ten-element LED bar display, sweeping them back and forth. Note that I am doing this in dot mode (only one element lit at a time) thus keeping the current under the max ratings of the PIC16F88. All ten cathodes are ganged and terminate through a single 330 ohm resistor to ground. Port lines B.0 through B.7 and A.0 and A.1 directly drive the display. Here's the code:
;A program to sweep 10 elements of an LED bar graph.
;In this direct connection circuit, only one LED
;element may be lit at a time to stay under max current.
;********************* Configuration **********************
#chip 16F88, 4 ;PIC16F88 running at 4 MHz
#config mclr=off ;reset handled internally
#config osc=int ;use internal clock
;************************ Constants ************************
#define bitsLow PortB ;low eight bits of display here
#define bitsHigh PortA ;high two bits of display here
;************************ Program *************************
pgm:
dim pattern as word alias patternHigh, patternLow ;LED pattern
wait 1 ms ;let the PIC settle down
do
pattern = 1 ;begin with 1st LED
for i = 1 to 10 ;ten LEDs in display unit
bitsLow = patternLow ;set two parts separately
bitsHigh = patternHigh
wait 100 ms ;pause a bit
rotate pattern left simple ;get set for the next one
next
pattern = 256 ;now sweep backwards
for i = 9 to 2 step -1 ;9th to 2nd element
bitsLow = patternLow
bitsHigh = patternHigh ;set two parts separately
wait 100 ms ;pause a bit
rotate pattern right simple ;get set for the next one
next
loop ;repeat in perpetuity
end
It's not terribly interesting, but it was a chance to learn about DIM, WORD and ALIAS. I was delighted to see that all of these work, and also that GC Basic automatically set the ports for digital output.
But look at the attached code, if you would. Notice the WAIT 1 ms command at the outset. After several hours of poking around, I found I had to have this. Without that line, the project started up in a mixed-up manner. Sometimes all LEDs were lit, or perhaps a mixture. And then after a slight pause the circuit began operating as expected.
I'm conjecturing that at power-on reset a slight delay is needed (1 ms was what I found worked) for Ports A and B to settle down or for the ports or registers to stabilize.
Does that sound reasonable?
Note that I'm using the internal !MCLR and internal clock. I'm still slogging through the PIC16F88 data sheet but was hoping some experienced person here had ever noticed this.
Again, I'm guessing the internal oscillator needs this brief delay to come up to speed, or perhaps the ports need to settle.
What do you think?
Thomas Henry
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You could try turning on the power up timer in your config section - that will hold the chip in reset for about 72ms while the supply voltage stabilises. It defaults to off according to the data sheet.
At the moment the chip is probably executing code as soon as there is sufficient voltage for the core to work but maybe not enough for the peripherals to function or not enough time for everything to initialise.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2012-02-24
Hi,
Thanks for the suggestion which was a good one. I played with the power-up timer flag, but with no joy. After a couple more hours, I figured out that what I had observed was a red herring. I believe the answer lies elsewhere. In particular, my experiments suggest that the problem may lie with the GC Basic routine which handles the automatic pin direction setting. Accordingly, I've moved this problem to a new thread.
Thanks again,
Thomas Henry
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi all,
Just for practice in learning GC Basic, I whipped up a circuit to light the elements of a ten-element LED bar display, sweeping them back and forth. Note that I am doing this in dot mode (only one element lit at a time) thus keeping the current under the max ratings of the PIC16F88. All ten cathodes are ganged and terminate through a single 330 ohm resistor to ground. Port lines B.0 through B.7 and A.0 and A.1 directly drive the display. Here's the code:
It's not terribly interesting, but it was a chance to learn about DIM, WORD and ALIAS. I was delighted to see that all of these work, and also that GC Basic automatically set the ports for digital output.
But look at the attached code, if you would. Notice the WAIT 1 ms command at the outset. After several hours of poking around, I found I had to have this. Without that line, the project started up in a mixed-up manner. Sometimes all LEDs were lit, or perhaps a mixture. And then after a slight pause the circuit began operating as expected.
I'm conjecturing that at power-on reset a slight delay is needed (1 ms was what I found worked) for Ports A and B to settle down or for the ports or registers to stabilize.
Does that sound reasonable?
Note that I'm using the internal !MCLR and internal clock. I'm still slogging through the PIC16F88 data sheet but was hoping some experienced person here had ever noticed this.
Again, I'm guessing the internal oscillator needs this brief delay to come up to speed, or perhaps the ports need to settle.
What do you think?
Thomas Henry
You could try turning on the power up timer in your config section - that will hold the chip in reset for about 72ms while the supply voltage stabilises. It defaults to off according to the data sheet.
At the moment the chip is probably executing code as soon as there is sufficient voltage for the core to work but maybe not enough for the peripherals to function or not enough time for everything to initialise.
Hi,
Thanks for the suggestion which was a good one. I played with the power-up timer flag, but with no joy. After a couple more hours, I figured out that what I had observed was a red herring. I believe the answer lies elsewhere. In particular, my experiments suggest that the problem may lie with the GC Basic routine which handles the automatic pin direction setting. Accordingly, I've moved this problem to a new thread.
Thanks again,
Thomas Henry