• Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

Just a note about micro's

Status
Not open for further replies.

Ian Rogers

User Extraordinaire
Forum Supporter
Most Helpful Member
The following kicked me in the nethers twice lately...

I've been doing this for eon's now so I should know better... One of my products has a quadrature counter and I use a pic18 to decipher.... As some of you know, I have recently gone wireless... This means the code in the pic18 has changed to decipher the signal from a serial connection from the module... Anyhwo!!! I have spent two days with 4 dead pics... After banging my head off every wall I could find, I finaly admitted that 4 dead micro's weren't dead.... I have moved to the nano powered k series and the osc settings are next to weird, so herein MUST be the problem.... Transfixed I went gray and bald in quick succession.. I have tried EVERY osc combination....... Nope!!!!

As the code works exceptionally well on a non k derivative, I became blinkered... Aha!!! Then I remembered just under 4 months previous when all the wireless started...

The old encoder fed into the int pin... I have removed the section in the interrupt handler for said deciphering BUT!!!!!!!! I forgot to switch the interrupt off.... As the int pin was floating AND I never clear the flag..... Hey it never comes out of the interrupt...ever!!!

Absolutely nothing to do with being a k series at all....

Just to show how it kills the "joy of programming" Listen and learn....
 

alec_t

Well-Known Member
Most Helpful Member
Just goes to show it's about time they brought out a micro which knows what the programmer intended, rather than coded :).
 

MrDEB

Well-Known Member
YES a voice activated pic that will code as per your voice commands!!
great idea
 

Pommie

Well-Known Member
Most Helpful Member
I've been caught out many times due to being fixated on one particular thing. Maybe a check list can be written for common problems.
With oscillator problems, wouldn't single stepping from the beginning have identified that it wasn't the problem?

Mike
 

MrDEB

Well-Known Member
I use the K series pics for the Christmas ornaments and the first thing I do is program an led blinking code. This has evaded many problems that I had in the past.
Start small and add sections of code as you go.
In the code for my game hub where a port pin is taken LOW and an led is turned on until a second press.
Jonsea solved the issue but I tried using instead of a BYTE called pressed I just went swt = 0
won't work as I discovered. Pommie suggested a code that I plan on try out. I like to disamble code and discover what each section does.
 

JonSea

Well-Known Member
Most Helpful Member
.....I like to disamble code and discover what each section does.

Oh? When are you going to start doing that???

It was obvious to me in the statement

If S1 = Pressed then....

that any idiot would know that Pressed was a variable, equal to 0 or 1 depending on how the switch was wired. Guess I assumed wayyyy too much.
 

Ian Rogers

User Extraordinaire
Forum Supporter
Most Helpful Member
With oscillator problems, wouldn't single stepping from the beginning have identified that it wasn't the problem?
Normally!! But I mainly sim the code first with Proteus... This didn't show up in software sim...
 

misterT

Well-Known Member
Most Helpful Member
Avr-libc implements a default interrupt routine. If you do not assign any ISR to an interrupt, it jumps to the default and back. Usually empty routine, but you can do some error reporting also.
 

Ian Rogers

User Extraordinaire
Forum Supporter
Most Helpful Member
Avr-libc implements a default interrupt routine. If you do not assign any ISR to an interrupt, it jumps to the default and back. Usually empty routine, but you can do some error reporting also.
The trouble here with pic's... There is only two interrupts... Low and high And I'm already using them... If there was a default, it still wouldn't go to it!!
 

MrDEB

Well-Known Member
in reply to post # 6
I tried using s1 = 0 and discovered I needed the pressed variable n order for the code to work.
Found out that the variable pressed was required.
What I was wanting to do was use a FOR NEXT loop instead of coding all 8 or 10 switch / led combos. I believe it is referencing to as dimensioning an array?

WHILE true
for x = 0 to 7
IF Swt(x) = pressed
THEN
TOGGLE (led(x))
DELAYMS(500)
END IF
next
 

JonSea

Well-Known Member
Most Helpful Member
in reply to post # 6
I tried using s1 = 0 and discovered I needed the pressed variable n order for the code to work.
Found out that the variable pressed was required.
What I was wanting to do was use a FOR NEXT loop instead of coding all 8 or 10 switch / led combos. I believe it is referencing to as dimensioning an array?

WHILE true
for x = 0 to 7
IF Swt(x) = pressed
THEN
TOGGLE (led(x))
DELAYMS(500)
END IF
next
Yes, you've said that about two dozen times. It won't work in Swordfish. What part of that is difficult to understand?
 

Cicero

Active Member
I'm surprised you didn't pick this up with a debugger? For problems like this I'd normally let the code run and click pause at random intervals, if it always stops in the interrupt there's something whack keeping it in there.
 

Ian Rogers

User Extraordinaire
Forum Supporter
Most Helpful Member
I'm surprised you didn't pick this up with a debugger? For problems like this I'd normally let the code run and click pause at random intervals, if it always stops in the interrupt there's something whack keeping it in there.
There wasn't an issue with debbuging as I use Proteus... Software exhibits different results... ie.. variables are all 0 and interrupts are not fired as the switch on is clean.... If the INT pin is floating then the software doesn't see any jitter whereas in real life it does...

If I'd have used the pickit3 to debug, well then yes! I would have been far more successful...
 

Cicero

Active Member
There wasn't an issue with debbuging as I use Proteus... Software exhibits different results... ie.. variables are all 0 and interrupts are not fired as the switch on is clean.... If the INT pin is floating then the software doesn't see any jitter whereas in real life it does...

If I'd have used the pickit3 to debug, well then yes! I would have been far more successful...
Oh sorry, I get ya. I should've read all the replies as well, would've seen your #7.
 
Status
Not open for further replies.

EE World Online Articles

Loading
Top