Just a note about micro's

[Ian Rogers]

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]

Just goes to show it's about time they brought out a micro which knows what the programmer intended, rather than coded .

 

[MrDEB]

YES a voice activated pic that will code as per your voice commands!!
great idea

 

[Pommie]

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]

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]

.....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]

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]

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]

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]

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]

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]

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]

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]

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.