Trying to inch my way to the finish line w/ a 16F1829.........

OK! I have gotten most of what I needed to work, I think.... I am having a few snags though really close to the end. This is a self acquire satellite dish. (I still need to write the code for aiming, but that's just a "where am i, count and move"... should be easy enough) I finally have the homing sequence down. I went down a rabbit hole not realizing where the azimuth limit switch was. Once I found it, it shortened my process immensely. However, now that I'm trying to test the new homing code and write the stow code, I am having a couple issues.

1. My external interrupt is not interrupting. This goes to the encoders on the dish and is receiving 5v+ pulses when the dish moves in any direction. I am verifying this with a scope. But PIC doesn't recognize and gives me Move Error. (Which it should cuz I want it to stop if it can't see where it's going)

2. My serial connection is losing characters. Every line is missing random characters. I would say 5% - 15% lost on average.

3. They way I have it set up now is to wait on the serin command for an input. I am using a terminal at the moment, but I am going to have a handheld device with 4 buttons and a LCD, as well as the ability to connect with it from a smartphone app. The handheld will have it's own MC, but since i want to have different style user implements, all the 'intelligent stuff' has to be done on this one on the unit itself. My question is, can anyone help me figure out a decent way to implement these different interfaces simultaneously? I was kicking around an idea of using an interrupt for serial and have all commands live at the same time since I easily have 72 single char I can send without complicating it further. But if I do it that way, I'll have to code in so many safeties so users dont do stuff in the wrong order..... ya I'm kinda stumped. lol

4. I only started working with MC's about two months ago, so I was also wondering if anything jumps out at anyone about something I could do more easily, or make this more reliable.

'************************************************* ***************
'* Name : Galaxy Main
'* Author : John Moore
'* Notice : Copyright (c) 2010
'* : All Rights Reserved
'* Date : May 4, 2014
'* Version : 1.2
'* Notes :
'* :
'************************************************* ***************


INCLUDE "DT_INTS-14.bas"
INCLUDE "ReEnterPBP.bas"
INCLUDE "Elapsed_TICKS.bas"
include "modedefs.bas"


#CONFIG
__config _CONFIG1, _FOSC_HS & _WDTE_OFF & _PWRTE_OFF & _MCLRE_ON & _CP_OFF & _CPD_OFF & _BOREN_OFF & _CLKOUTEN_OFF & _IESO_OFF
__config _CONFIG2, _PLLEN_OFF & _LVP_OFF


#ENDCONFIG


DEFINE OSC 20


ASM
INT_LIST macro ; IntSource, Label, Type, ResetFlag?
INT_Handler TMR1_INT, _ClockCount, PBP, yes
INT_Handler INT_INT, _doEncoder, PBP, yes
endm
INT_CREATE ; Creates the interrupt processor
ENDASM


@ INT_ENABLE TMR1_INT ; Enable Timer 1 Interrupts
@ INT_ENABLE INT_INT


GOSUB ResetTime ' Reset Time to 0d-00:00:00.00
GOSUB StartTimer


ADCON1 = 7
INTCON = %11111000
UP var PORTC.0
TRISC.0 = 0
low up
DOWN var PORTC.1
TRISC.1 = 0
low down
WEST var PORTC.2
TRISC.2 = 0
low west
EAST var PORTC.7
TRISC.7 = 0
low east
RX var PORTB.6
TRISB.6 = 1
TX var PORTB.5
TRISB.5 = 0
azLIMIT var PORTC.6
TRISC.6 = 1




newtime var word
oldtime var word
Sencoder0Pos var word
Eencoder0Pos var word
Aencoder0Pos var word
Enewposition var word
Eoldposition var word
Enewvel var word
Eoldvel var word
elPOS var word
elHOMEpos var word
elSTOWpos var word
Anewposition var word
Aoldposition var word
Anewvel var word
Aoldvel var word
azPOS var word
azSTOWpos var word
azHOMEpos var word
cereal var word
bugprint var word
apple var word
apple = 0
stowed var word
stowed = 0
slow var word
wsave var byte $70 SYSTEM
wsave1 var byte $A0 SYSTEM
wsave2 VAR BYTE $120 SYSTEM
wsave3 VAR BYTE $1A0 SYSTEM
velocity var word[10]
vnt var word
cnt var byte
HEL var byte
HAZ var byte
b0 var byte
i var byte


goto MainMenu


Disable
doEncoder:
IF up = 1 THEN Eencoder0Pos = Eencoder0Pos + 1
IF down = 1 THEN Eencoder0Pos = Eencoder0Pos - 1
IF west = 1 THEN Aencoder0Pos = Aencoder0Pos + 1
IF east = 1 THEN Aencoder0Pos = Aencoder0Pos - 1
@ INT_RETURN


CLR:
For i = 0 to 30
serout TX, 2, [10]
next i
return


Startup:
pause 5000
'gosub CLR
serout tx, 2, ["Running Startup Procedures!", 13, 10]
serout tx, 2, ["PLEASE WAIT....", 13, 10]
pause 250
Eencoder0Pos = 15491
serout TX, 2, ["Eencoder0Pos Before is: ", #Eencoder0Pos, 13, 10]
Eoldposition = Eencoder0Pos
high down
pause 1000
gosub allSTOP
serout TX, 2, ["Eencoder0Pos After is: ", #Eencoder0Pos, 13, 10]
Enewposition = Eencoder0Pos
serout TX, 2, ["Eoldposition is: ", #Eoldposition, 13, 10]
serout TX, 2, ["Enewposition is: ", #Enewposition, 13, 10]
IF Eoldposition = Enewposition THEN
stowed = 1
apple = 1
'gosub CLR
serout TX, 2, ["Startup Sequence Good!", 13, 10]
serout TX, 2, ["Continuing to Main Menu...", 13, 10]
goto MainMenu
ENDIF
IF Enewposition < Eoldposition THEN
stowed = 0
apple = 0
high up
pause 1000
gosub allSTOP
gosub CLR
pause 100
serout TX, T9600, ["Startup Error!", 13, 10]
pause 100
serout TX, T9600, ["Dish will need homing before move will be allowed!", 13, 10]
pause 100
serout TX, T9600, ["Continuing to Main Menu...", 13, 10]
pause 5000
goto Mainmenu
ENDIF


MainMenu:
gosub CLR
pause 200
serout TX, T9600, ["******** MAIN MENU ********", 13, 10, 10]
pause 200
serout TX, T9600, [" 1. Start Homing Sequence", 13, 10]
pause 200
serout TX, T9600, [" 2. Manual JOG Mode", 13, 10]
pause 200
serout TX, T9600, [" 3. Auto-Acquire Satellite", 13, 10]
pause 200
serout TX, T9600, [" 4. Stow Dish for Travel", 13, 10, 10]
pause 200
serout TX, T9600, ["Enter Your Selection:"]
pause 500
Serin RX, T9600, b0
If b0 = "1" then goto HomeDish
If b0 = "2" then goto JogMenu
If b0 = "3" then goto ACQUIRE
If b0 = "4" then goto Startup
goto MainMenu


HomeDish:
gosub CLR
serout TX, T9600, ["******** HOME DISH ********", 13, 10, 10]
serout TX, T9600, [" 1. Start Homing Sequence", 13, 10, 10]
serout TX, T9600, [" 2 Abort Homing", 13, 10, 10]
serout TX, T9600, ["Enter Your Selection:"]
Serin RX, T9600, b0
if b0 = "2" then goto MainMenu
homeloop:
IF b0 = "1" THEN
gosub HomeEL
gosub HomeAZ
HAZ = 1
IF (HEL = 1) AND (HAZ = 1) THEN
gosub clr
serout TX, T9600, ["HOME PROCESS WAS SUCCESSFUL!", 13, 10]
goto MainMenu
ENDIF
IF (HEL = 0) OR (HAZ = 0 ) THEN
gosub clr
serout TX, T9600, ["DIS HOME PROCESS CAN SUCK MY DICK!", 13, 10]
goto MainMenu
ENDIF
ENDIF
pause(200)
goto homeloop
goto HomeDish


HomeAZ:
gosub clr
serout TX, T9600, ["HOMING AZIMUTH - PLEASE WAIT..", 13, 10]
PAUSE(500)
Aencoder0Pos = 0
HIGH WEST
PAUSE(250)
IF Aencoder0Pos = 0 THEN
gosub allSTOP
high EAST
PAUSE(250)
gosub allSTOP
PAUSE(500)
Aencoder0Pos = 0
high WEST
PAUSE(500)
IF Aencoder0Pos = 0 THEN goto moveerror
ENDIF


loop4:
if azLIMIT = 0 then
loop5:
pause 100
if azLIMIT = 0 then goto loop5
if azLIMIT = 1 then
gosub allSTOP
Aencoder0Pos = 0
high EAST
pause 3000
gosub allSTOP
HAZ = 1
return
endif
endif
if azLIMIT = 1 then
low WEST
high EAST
loop6
pause 100
if azLIMIT = 1 then goto loop6
if azLIMIT = 0 then
pause 3000
low EAST
high WEST
goto loop4
endif
endif



HomeEL:
gosub clr
serout TX, T9600, ["HOMING ELEVATION - PLEASE WAIT..", 13, 10]
PAUSE(500)
Eencoder0Pos = 0
HIGH up
PAUSE(250)
IF Eencoder0Pos = 0 THEN
gosub allSTOP
high down
PAUSE(250)
gosub allSTOP
PAUSE(500)
Eencoder0Pos = 0
high up
PAUSE(500)
IF Eencoder0Pos = 0 THEN goto moveerror
ENDIF
loop3:
pause 250
Eoldposition = Enewposition
Enewposition = Eencoder0Pos
IF Enewposition > Eoldposition THEN goto loop3
if Eoldposition = Enewposition then
gosub allSTOP
elPOS = 0
Eencoder0Pos = 3665
pause(500)
high down
pause(5000)
GOSUB allSTOP
gosub clr
serout TX, T9600, ["HOMING ELEVATION WAS SUCCESSFUL!", 13, 10]
HEL = 1
return
ENDIF
goto loop3


JogMenu:
gosub CLR
high TX
serout TX, T9600, ["***** JOG MENU *****", 13, 10, 10]
serout TX, T9600, ["U - UP", 13, 10]
serout TX, T9600, ["D - DOWN", 13, 10]
serout TX, T9600, ["E - EAST", 13, 10]
serout TX, T9600, ["W - WEST", 13, 10]
serout TX, T9600, ["S - ALL STOP", 13, 10]
SEROUT TX, T9600, ["X - MAIN MENU", 13, 10, 10]
serin RX, T9600, b0
if b0 = "U" Then
gosub allSTOP
high up
endif
if b0 = "D" then
gosub allSTOP
high down
endif
if b0 = "E" then
gosub allSTOP
high east
endif
if b0 = "W" then
gosub allSTOP
high west
endif
if b0 = "S" then gosub allSTOP
if b0 = "X" then goto MainMenu
goto JOGMenu


ACQUIRE:
GOSUB CLR
SEROUT TX, T9600, [" AUTO-ACQUIRE ", 13, 10]
SEROUT TX, T9600, ["NOT YET ASSHOLE!", 13, 10]
goto MainMenu


STOW:
GOSUB CLR
SEROUT TX, T9600, [" AUTO-STOW DISH", 13, 10]
SEROUT TX, T9600, ["NOT YET ASSHOLE!", 13, 10]
goto MainMenu


allSTOP:
low up
low down
low east
low west
return


abort:
gosub allSTOP
gosub clr
serout TX, T9600, ["USER STOP! -- MOVE ABORTED!", 13, 10]
PAUSE(5000)
goto MainMenu


moveerror:
gosub allSTOP
gosub clr
serout TX, T9600, ["SYSTEM ERROR! -- MOVE ABORTED!", 13, 10]
PAUSE(5000)
goto MainMenu


POS:
pause 100
serout TX, 0, ["EL -- ", #Eencoder0Pos, " ", "AZ -- ", #Aencoder0Pos, 13, 10]
PAUSE 100
return

Hi,
Please, please use the code tags when posting code

[ code ]
Paste code here but remove the spaces within brackets and you'll get:
[ / code ]

Code:

---

Paste code here but remove the spaces within brackets and you'll get:

---

1) I don't quite get it... Do you have multiple encoders all connected to a single input and if so how does that work? I thought east/west etc were individual inputs but they are clearly outputs so I'm not sure I understand.
What's the purpose of the DISABLE right before the interrupt handler? DISABLE is used with PBPs ON INTERRUPT, I don't Think you want it there when using DT-INTS. It's probably not related to the problem you're having but still....

2) That's probably because you're using SEROUT while you have interrupts stealing time away from in in the background. SEROUT is software timed, if you have interrupts firing while SEROUT is executing its timing will be off causing baudrate errors. The 16F1829 does have EUSART, you'll be MUCH better off using it (with HSEROUT for example) instead of SEROUT!

3) I'll leave this one for now.

4) I think you're doing quite good! It's a bit too much code to for me to "pick apart" right now but one thing I personally don't use much is HIGH/LOW. They are nice in that they automatically set the pin to an output (clearing TRIS) but it does so on every occurence of the command so it's quite wasteful if the pin is supposed to be an output all the time anyway. Nothing inherently wrong with HIGH/LOW though so as long as you're not suffering from speed or lack of flash then it's just fine.

/Henrik.

/Henrik,

Thanks for the reply. Yes the encoders were all separate at one time. There are two right now, but there are actually 3. Elevation, Azimuth, and Skew. I'm not using the skew right now as it's not super critical to change it within reasonable driving distance ie about 12 hrs. The remaining two, as well as eventually the third, all join together to come in to the MC on one wire. I did this when my plan was to have a wired handheld device only and was trying to keep the number of wires down to 8 so I could use CAT5 between the two. I have since gone BT with the multi-MC idea, but I saw no reason to change it. If you look at my interrupt coding, I simply made it so that the program decides which encoder to add the pulse to by deciding which axis it was trying to move. Since only one axis ever needs to move at one time, it works fine. I just re-read your post... UP, DOWN, EAST, WEST are the output pin aliases. Eencoder0Pos is the variable for the elevation encoder position. Aencoder0Pos is the variable for the Azimuth. If a pulse comes in and the MC was moving the dish up, UP will be = 1 to it'll add 1 to the Eencoder0Pos. If it was moving the dish down, then DOWN will = 1 and it'll subtract 1 from Eencoder0Pos and so forth. Each encoder originally had two pulse wires with one pulse half a cycle behind so the MC could distinguish which way it was rotating. Ditching the second pulse wire from each encoder (since the MC already knows which way it was trying to move it) and combining the remaining three (since the MC also knows which encoder should be moving) was the only way I could think of to get it all on one wire.

Speaking of which, I am having a problem there too. The elevation isn't an issue. From "stowed" (down) to full travel UP, is like 3665 pulses. But the azimuth is WAY more. From "stowed" around to physical limits one way is approx 220 deg, and 109300 pulses. And that's only partial rotation. Full rotation is about 400 - 450 deg, so I have a counter that needs headroom of about 250,000. What can i use that's bigger than WORD? The 65k overflow point isnt really workin for me. When I started this project in Arduino, it wasn't an issue. If I can't get bigger than WORD, then the only other thing I can think of is to add code to the interrupt so on azimuth, it'll only -1/+1 to my var on say, every fifth pulse. I have resolution coming out my ears, but still, I'd rather not if there's another way.

The high/low issue... So if I use high/low, it sets the TRIS bytes for me? If I use high/low, it significantly adds to the program size? And if I set the TRIS bytes, how do I do it? I guess, WEST = 1?? Very interesting... I don't recall this info being in the PBP manual?

Yes, I'll kill the disable. I think it's an accidental leftover from when I started. I started using a PBP int for that and the DT-INT for a timer. Then after I understood the DT-INT a little better, it switched over to it for both. I was using velocity monitoring and a sudden slowing to calc when I hit the physical limit on azimuth. Then I found the switch yesterday, and eliminated that catastrophe of coding. I need to eliminate the timer as well since I have no use of any time-keeping anymore.

Quote:

---

Originally Posted by HenrikOlsson

Hi,
2) That's probably because you're using SEROUT while you have interrupts stealing time away from in in the background. SEROUT is software timed, if you have interrupts firing while SEROUT is executing its timing will be off causing baudrate errors. The 16F1829 does have EUSART, you'll be MUCH better off using it (with HSEROUT for example) instead of SEROUT!
/Henrik.

---

I figured it was something like this. I assumed it had to do with the ASM interrupts because through playing with the numbers, I found:
Faster Clock = Less errors (expected)
Faster Baud = Less errors (not expected)

I then had the hypothesis that there were "time holes" my serial info was falling thru. Faster clock = smaller holes = less char lost. And faster baud = more info makes it thru beween the holes = less char lost. It did baffle me at first, that lowering the baud made it way worse. I had to drive around at work thinking about it for several hours before it hit me what was happening... lol

Just wondering, why bother counting pulses?

Wouldn't you only need 360° rotation, 90° elevation and not sure for skew?

Since you haven't tackled the tracking yet, would it be simpler to just "move" as long as a button is pressed on the handheld?

Or, maybe enter a degree and go to that position (a rotary encoder on the devices can track where it's pointed).

Just tossing thoughts.

Robert

Quote:

---

Originally Posted by Demon

Just wondering, why bother counting pulses?

Wouldn't you only need 360° rotation, 90° elevation and not sure for skew?

Since you haven't tackled the tracking yet, would it be simpler to just "move" as long as a button is pressed on the handheld?

Or, maybe enter a degree and go to that position (a rotary encoder on the devices can track where it's pointed).

Just tossing thoughts.

Robert

---

Well ya... that's the idea. But without an encoder, how would it have any idea where it is? The pulse counting is the only way to indicate how far the dish has travelled. When you look at the handheld, (or the phone or terminal) when I'm done, you will only see degrees or a satellite choice. You won't see the pulses anymore, but they have to be there. Maybe you misunderstood my project... This is a self-acquire satellite system, BUT I'm rebuilding the electronics from scratch. I S***canned all the stock electronics. The dish itself is VERY hearty, and well (over) built, but the electronics were way overbuilt as well, and as such, never worked reliably. Also, I am upgrading (completely changing) the satellite system that run on it as well. Totally different band even. So I have to establish a new way for it to identify and peak in on the new satellite as well.

I just re-read... OH! No, you would have to see the dish.. lol. Not small. 1 meter, on it's own trailer with an on-board box for generator, UPS, batteries, modem, router, etc. The dish only needs 360deg, (well a lil for overlap in case the user has the trailer oriented with the satellite right at the stop point) and elevation 90deg. BUT the motors are very small and geared down to hell and back. (I'm pretty sure the reason was so the motors could be de-energized and the dish stay put due to the extreme gearing) As a matter of fact, the elevation hardware is a C-band Superjack. The azimuth motor is nearly the same, but of course oriented differently. So an encoder that would only read a partial amount of a single revolution won't work. The motors turn many thousands of times to fully rotate the dish.

When I'm done, there will be a JOG mode that moves as long as the button's pressed. But I still want it tracking where it is, both for auto-stow purposes, and because the box that mounted on the trailer is in a possible path of the dish. It'll never be in the way to find the bird, but you can (and I did this morning, and ripped the mounting plate right off the trailer, something else I'll need to repair now) crash the dish into the box. Bad S*** happens. So even when jogging, I want to program in "no fly zones" that wont allow you to crash it.

As for giving it target coordinates, it'll be even easier than that. It only points to one satellite. With the addition of GPS and compass, you will be able to turn it on, and press Auto-Acquire and it'll do the rest. That's the end goal.


Make a lil more sense now?

Hi,

Quote:

---

Each encoder originally had two pulse wires with one pulse half a cycle behind so the MC could distinguish which way it was rotating. Ditching the second pulse wire from each encoder (since the MC already knows which way it was trying to move it) and combining the remaining three (since the MC also knows which encoder should be moving) was the only way I could think of to get it all on one wire.

---

So ordinary qudrature encoders then. Are they open collector output? I mean, if they are push-pull type output and you have several connected together there's quite a possibillity one will try to drive the line low while another tries to drive the line high.

Another option is to keep a global count for each encoder. Then you have each encoder signal connected to a timer/counter input on the PIC. When you're about to move an axis you clear the timer/counter register and run the motor. The timer/counter register will now track the relative movement which you can add or subtract from your global count for the axis moving. You'll still not have the direction information given by the quadrature nature of the encoder but it sounds as if the dish can't be backdriven anyway.

Quote:

---

I figured it was something like this. I assumed it had to do with the ASM interrupts because through playing with the numbers, I found:
Faster Clock = Less errors (expected)
Faster Baud = Less errors (not expected)

---

When you increase the baudrate each "message" takes less time to send so it's less likely that an interrupt occurs while it's sending.

Quote:

---

What can i use that's bigger than WORD?

---

That would be a LONG but they're only available on 18F parts. If you don't NEED the resolution then increase your count every X interrupt, that would be the easiest. Another option is to use two WORDS where the "top" one indicates degrees and the "bottom" one indicated minutes, seconds or 1/10 of degrees or whatever.

Quote:

---

The high/low issue... So if I use high/low, it sets the TRIS bytes for me?

---

Yes it does. But it does every time you use HIGH/LOW.

Quote:

---

If I use high/low, it significantly adds to the program size?

---

I guess it depends on how you define significantly but yes. Lets say you have WEST aliased to PortB.0, then doing HIGH WEST will basically be replaced with TRISB.0 = 0 : PortB.0 = 1. The "wasteful" part is that it does the TRISB.0 = 0 every time you do a HIGH/LOW west, even if the pin is and has been an output all the time.

Quote:

---

And if I set the TRIS bytes, how do I do it? I guess, WEST = 1?? Very interesting... I don't recall this info being in the PBP manual?

---

Exactly, just clear the TRIS bit (like you're already doing). Then simple set the port register. PortB.0 = 1 or WEST = 1, if WEST is aliased to PortB.0.

/Henrik.

Quote:

---

Speaking of which, I am having a problem there too. The elevation isn't an issue. From "stowed" (down) to full travel UP, is like 3665 pulses. But the azimuth is WAY more. From "stowed" around to physical limits one way is approx 220 deg, and 109300 pulses. And that's only partial rotation. Full rotation is about 400 - 450 deg, so I have a counter that needs headroom of about 250,000. What can i use that's bigger than WORD?

---

This jogged my memory regarding a problem I had regarding time of day comparisons. I had the idea of converting time of day to seconds into day which obviously could go up to 86400 and will not fit into a byte or word variable. I resolved the issue by comparing hours, minutes and seconds into the day which was just a few more lines of code.

In your case is it possible to change pulses into second, minute and degree variables. Then again obviously your variables will have 60, 60 and 450. This will then be a clock routine of which there are many examples I am sure.

Quote:

---

Originally Posted by HenrikOlsson

Hi,
So ordinary qudrature encoders then. Are they open collector output? I mean, if they are push-pull type output and you have several connected together there's quite a possibillity one will try to drive the line low while another tries to drive the line high.

---

I thought of this when I first got rolling but one of the first things I worked on was to come up with some sort of scope. I made one from some CAT5, a stereo headphone jack from Radio Shack, and some alligator clips to use the mic jack on my laptop. Anyways, I can see the encoder signals, and from day one they have always been super clean. When I combined them I noticed no degradation or conflicts. Right now is probably the dirtiest I've seen because I have 50ft of CAT5 running in my living room window from the dish to my breadboard. (It's HOT in Texas!) But even when I say dirty, they are still really clean square waves, very little edging on the corners, if any, and no misses, dropoffs, or extra trash spikes. Just not PERFECT like you see people playing with PLL's on youtube on $1k scopes.

Quote:

---

Originally Posted by HenrikOlsson

Another option is to keep a global count for each encoder. Then you have each encoder signal connected to a timer/counter input on the PIC. When you're about to move an axis you clear the timer/counter register and run the motor. The timer/counter register will now track the relative movement which you can add or subtract from your global count for the axis moving.

---

timer/counter input?? hmm, I'll have to look into this dark magic you speak of...

Quote:

---

Originally Posted by HenrikOlsson

You'll still not have the direction information given by the quadrature nature of the encoder but it sounds as if the dish can't be backdriven anyway.

---

If by "backdriven", you mean you can't push it by hand and move it, then yes you are right. I think this is why the designers used regular DC motors with gearboxes and encoders instead of say, large steppers. The steppers could have been used with no gears and no encoding, but when powered down, the dish would be flapping in the wind.

Quote:

---

Originally Posted by HenrikOlsson

When you increase the baudrate each "message" takes less time to send so it's less likely that an interrupt occurs while it's sending.

---

Ya but here's the rub... there was no interrupt happening. This has been happening since I put in the interrupt coding, but there was nothing hooked up. The encoder wire was just hanging off the CAT5 while I was jogging the dish manually while physically watching it (to avoid crashing) and tweaking the code for the menus and dish control. And remember, right now, there is no interrupt happening. That was the #2 subject of this post. (Which I still haven't figured out) And the way my code is written,

Eencoder0Pos = 0
HIGH UP
PAUSE 250
IF Eencoder0Pos = 0 Then goto moveerror

If I was having a float problem, it would only have to trigger ONE interrupt to avoid my error. My code doesn't require steady movement, or consistent movement, it only requires it not to still be on ZERO, which it is. So with confirmed zero triggered interrupts, it's still dropping characters from the ----- OMFG! Wow it's dark in here! Smells bad too... I just may pull my head out someday! The timer! Duh! I completely forgot the timer interrupt.... I'll get back to ya on this one..... UGH!

Quote:

---

Originally Posted by HenrikOlsson

If you don't NEED the resolution then increase your count every X interrupt, that would be the easiest.

---

That's what I was figuring my factor of 5 on. If I have 250,000 pulses from limit to limit, and I count every 5th pulse, that's now 50,000 which gives me 15000 to spare.

Hi,

Quote:

---

I thought of this when I first got rolling but one of the first things I worked on was to come up with some sort of scope. I made one from some CAT5, a stereo headphone jack from Radio Shack, and some alligator clips to use the mic jack on my laptop. Anyways, I can see the encoder signals, and from day one they have always been super clean. When I combined them I noticed no degradation or conflicts. Right now is probably the dirtiest I've seen because I have 50ft of CAT5 running in my living room window from the dish to my breadboard. (It's HOT in Texas!) But even when I say dirty, they are still really clean square waves, very little edging on the corners, if any, and no misses, dropoffs, or extra trash spikes. Just not PERFECT like you see people playing with PLL's on youtube on $1k scopes

---

OK, soundcards generally have a capacitor in series with the input to remove any DC bias, I'm surprised that you get a clean crisp square wave but I guess it depends on at what frequency you measured. What if you remove the encoders and use a switch or whatever to simulate pulses and toggle a LED or something in ISR? That way you should be able to verify if interrupts aren't actually being generated.

Quote:

---

timer/counter input?? hmm, I'll have to look into this dark magic you speak of...

---

Your PIC have two timers TMR0 and TMR1. They can be configured as timers or as counters. When configured as counters they will be "clocked" by a signal connected to T0CKI and T1CKI inputs respectively.

Quote:

---

If by "backdriven", you mean you can't push it by hand and move it, then yes you are right. I think this is why the designers used regular DC motors with gearboxes and encoders instead of say, large steppers. The steppers could have been used with no gears and no encoding, but when powered down, the dish would be flapping in the wind.

---

That's exactly what I meant. If you don't get the direction information from the quadrature encoders then you must be SURE that each and every pulse from the encoder is caused by the dish moving in the desired direction. If there's any vibration etc it's going to cause "extra" pulses which eventually will cause the position to drift. Sounds like you've got it covered, just something to think about.

Quote:

---

Ya but here's the rub... there was no interrupt happening. (snip) And remember, right now, there is no interrupt happening. That was the #2 subject of this post. (Which I still haven't figured out) And the way my code is written....(snip)....I just may pull my head out someday! The timer! Duh! I completely forgot the timer interrupt.... I'll get back to ya on this one..... UGH!... (snip)

---

Ya, exactly...THE TIMER.... :-)

Lets focus on one issue at the time, pick one and let us know how it goes. We'll go from there!

/Henrik.

YAY! No more timer, no more dropped letters, menus are beautiful again!

Yes the gearboxes hold the dish VERY securely. Plus, even if some wind or vibration caused some pulses, the MC will ignore them. Remember, the interrupt will fire no matter what, but unless the MC has an output high, to move the dish, it won't count them anywhere. It'll skip by all the if-then's and continue like nothing happened.

I put a button and led on INT pin and a LED on a spare pin then turned it on.
then I added:

LED = 0
pause 500
LED = 1

to the beginning of the interrupt handler. push push, blink blink, but no blackout from the response pin. So interrupt is not working.

Hi,

Quote:

---

YAY! No more timer, no more dropped letters, menus are beautiful again!

---

Ah, progress!

Quote:

---

Yes the gearboxes hold the dish VERY securely. Plus, even if some wind or vibration caused some pulses, the MC will ignore them. Remember, the interrupt will fire no matter what, but unless the MC has an output high, to move the dish, it won't count them anywhere. It'll skip by all the if-then's and continue like nothing happened.

---

Yes, I understand that. I was more thinking of the vibration caused WHILE the dish IS being moved but again, it's probably not an issue.

Quote:

---

I put a button and led on INT pin and a LED on a spare pin then turned it on.
then I added:

LED = 0
pause 500
LED = 1

---

First make sure you have control over that LED pin that you use in the ISR, blink the LED a couple of times at the start of the program just to make sure. Also, try removing the line where you manually set INTCON. A) You have several interrupt sources enabled that you don't actually use and B) DT-Ints handles setting INTCON for you.

/Henrik.

check this out...
http://s1179.photobucket.com/user/th.../Galaxy%20Dish

Ok, I put a double blink on the Main Menu under the Acquire label since I'm not using it yet. So anytime, I can hit 3 on the main menu and led blinks off twice. No interrupt still. removed intcon

About the WORD limitation, how about DOUBLE WORD?

Use 2 WORD variables, use them in embedded loops.

Code:

---

... (to increment in a loop, has to be rewritten if PULSE COUNT determined in a calculation)

IF WORD2 < 65535 THEN
  WORD2 = WORD2 + 1
ELSE
  WORD1 = WORD1 + 1
  WORD2 = 0
ENDIF

... (to perform pulses)

FOR COUNT1 = 0 TO WORD1
  FOR COUNT2 = 0 TO 65535
    PULSE
  NEXT COUNT2
NEXT COUNT1

FOR COUNT2 = 0 TO WORD2
  PULSE
NEXT COUNT2

---

I know it's more tedious, but it should work in my reality. :D

Robert


Edit: or you can use a 18F with PBPL. D'OH!

Max. 2,147,483,647.

Quote:

---

Originally Posted by thasatelliteguy

check this out...
http://s1179.photobucket.com/user/th.../Galaxy%20Dish

---

That is cool!

So you're making a satellite guided lawnmower? :D

BTW, did you catch the ENTIRELY PVC CNC mill/3D printer in the background? There's also extensive pics of that in an album on my photobucket. That was really my very first project diving into electronics... it took me about 3-4 months to get it built and running....

Hi,

Quote:

---

Ok, I put a double blink on the Main Menu under the Acquire label since I'm not using it yet. So anytime, I can hit 3 on the main menu and led blinks off twice. No interrupt still. removed intcon

---

OK, next up: The INT-pin is RA2 and it's got both comparator and ADC functionallity multiplexed on it. The comparator seems to be disabled by default (good in this case) but the analog functionallity is NOT disabled. Try adding ANSELA.2 = 0 to turn it off for that pin.

/Henrik.

Quote:

---

Originally Posted by thasatelliteguy

BTW, did you catch the ENTIRELY PVC CNC mill/3D printer in the background? There's also extensive pics of that in an album on my photobucket. That was really my very first project diving into electronics... it took me about 3-4 months to get it built and running....

---

You should start a thread in Off Topic and describe it. I'm looking forward to start working in my own mini-mill, one day.

Robert

Quote:

---

Originally Posted by Demon

You should start a thread in Off Topic and describe it. I'm looking forward to start working in my own mini-mill, one day.

Robert

---

I can definitely help you with any design work. I learned A LOT. Doing it in PVC was a real engineering challenge to say the least. My next trick will be a 30'X6' wooden above ground pool. And just to add some challenge to life... no fasteners. Nearly a 1/4 million lbs of water held up with construction adhesive and bailing wire... gonna be fun!

New twist on my lost letters/interrupt problem. It's gotten WAY better since I s***canned the timer, but the ext int is still killing me. Especially if any encoder stops on a high pulse. It tweaks my program to the point it wont even run. I have to disco the pulse wire, jog the dish a lil, then reconnect it to even get going again. Ideas on how to solve this and squash this bug permanently?

Hi,
OK, so now the interrupt IS firing as expected? What fixed it?
I still think you may have a problem with the multiple encoders individual outputs fighting each other when connected togeter. Do you have a datasheet for the encoder you're using and possibly a schematic of how you've got it wired?

What if you disconnect all but a single encoder?

/Henrik.

The ANSEL fixed it....thanks

I only have two encoders running at the moment as there is no skew motor right now. (I had a runaway situation in the beginning and ripped the planetaries out)

This happens with either encoder, so I believe it's probably not the fact their tied together, plus I would think I would see it on the scope. But when I get home tonight I'll try to disconnect one and see if it does it. I think there's something screwey with my power though. OK... I have two 12V batteries on the unit wired in series to 24v. I have 4 large auto-type 5 pole relays in my on-board control box as well as a 7805 to power the encoders. I am grabbing 12v from one batt only. All the motors are 24, but that's how I blew out the planetary. I think they half-powered it so if and when it does crash, it won't do damage. Anyways, I have one hot lead from each relay coming inside to my bench + one encoder lead + two leads (in and back) from a reed switch for azimuth location + one ground lead. so:

UP + (give this 12V+, and since the second relay is 5 pole and NC -, this moves the dish up)
DOWN + (give this 12V+, and since the second relay is 5 pole and NC -, this moves the dish down)
EAST + (give this 12V+, and since the second relay is 5 pole and NC -, this moves the dish east)
WEST + (give this 12V+, and since the second relay is 5 pole and NC -, this moves the dish west)
(This is a standard setup for wiring door locks to a car alarm. It gives you one-wire reverse poles to an actuator or in this case motor)
Those 4 wires are ran to a low-power motor controller. I did have them at 5v relays, but I found the kickback when they shut off was wigging out the chip. The motor controller gives me much better circuit isolation.
Encoder+ 5v pulse from both encoders
Switch feed
switch return (these, I just found and havent wired into my bulkhead plug yet.)
ground (To tie into the breadboard to make common ground to complete the circuit)

I have a 12v supply in the house (14v) into a 7805 to power the motor controller and chips.

If the encoders are in a position to wigg it out, when I disconnect BOTH power leads, the low power side stays powered. WTF? I have to disco the encoder lead or ground from outside to make it stop. What's really strange tho is that I can connect ONLY the 14v + and the board lights up. Without a common ground how can this be? SMFH!! Holy S***! That has to be the longest ground loop in history! I have a UPS charging the batteries which is on an extension cord to my bedroom window. I'm betting if I check, I'll find it's - to ground cont. The power pack I'm using is for the Hughnet modems and I know it's - to ground cont. So it's backfeeding ground from the pack I'm using to power my board, thru my breaker box, out my bedroom window, thru the UPS, to the relay board on the unit, and back in thru the living room. I'm calling Guiness!

I need to fix this tonight before going any further. I think this is the root of some spike-resets I'm still occasionally getting when the dish stops, and god knows what else, including my serial issues. But I guess on the bright side, I know for sure all my ground leads are securely soldered! lol

When my internet went down last night, I was forced into the manual with no outside help... it forced me to finally figure out and understand the commands to set bit in registers...YAY! But still I can't get the damn thing to work. Could ya take a look and see what's hanging me up in moving from serin/serout to hserin/hserout?


*** Also notice, for some reason when I made the change away from HIGH/LOW, my interrupt stopped being able to "see" the status of the output pin. I had to add a variable to be set along side each time before it'd trigger the if/then's again. Seems like I wasted more memory than I saved... Is there a better fix?

Code:

---


INCLUDE "DT_INTS-14.bas"
INCLUDE "ReEnterPBP.bas"

#CONFIG
    __config _CONFIG1, _FOSC_HS & _WDTE_OFF & _PWRTE_OFF & _MCLRE_ON & _CP_OFF & _CPD_OFF & _BOREN_OFF &  _CLKOUTEN_OFF & _IESO_OFF
    __config _CONFIG2, _PLLEN_OFF & _LVP_OFF
#ENDCONFIG

DEFINE OSC 20
ANSELA = 0        'DISABLE ANALOG
TRISA.1 = 1      'RX PIN AS INPUT
ADCON1 = 7
TXSTA.4 = 0      'SYNC BIT OFF
RCSTA.7 = 1      'SPEN BIT ON
RCSTA.4 = 1      'CREN BIT ON
PIE1.5 = 1        'RCIE BIT ON
INTCON.6 = 1      'PEIE BIT ON
INTCON.7 = 1      'GIE BIT ON


ASM
INT_LIST  macro    ; IntSource,        Label,  Type, ResetFlag?
        INT_Handler    INT_INT,  _doEncoder,    PBP,  yes
    endm
    INT_CREATE            ; Creates the interrupt processor
ENDASM
@  INT_ENABLE  INT_INT


avg var word
UP var PORTC.0
TRISC.0 = 0
UP = 0
DOWN var PORTC.1
TRISC.1 = 0
DOWN = 0
WEST var PORTC.2
TRISC.2 = 0
WEST = 0
EAST var PORTC.7
TRISC.7 = 0
EAST = 0
RX var PORTC.5
TRISB.6 = 1
TX var PORTC.4
TRISB.5 = 0
azLIMIT var PORTC.6
TRISC.6 = 1
LED var PORTB.7
TRISB.7 = 0
LED = 1
newpos var word
oldpos var word
distance var word
Eencoder0Pos var word
Aencoder0Pos var word
Enewposition var word
Eoldposition var word
elHOMEpos var word
elSTOWpos var word
Anewposition var word
Aoldposition var word
azPOS var word
azSTOWpos var word
azHOMEpos var word
cereal var word
apple var word
apple = 0
stowed var word
stowed = 0
wsave var byte $70 SYSTEM
wsave1 var byte $A0 SYSTEM
wsave2 VAR BYTE $120 SYSTEM
wsave3 VAR BYTE $1A0 SYSTEM
HEL var byte
HAZ var byte
b0 var byte
i var byte
el_UP var byte
el_UP = 0
el_DN var byte
el_DN = 0
az_EAST var byte
az_EAST = 0
az_WEST var byte
az_WEST = 0

goto MainMenu

disable
doEncoder:
    if el_UP = 1 then Eencoder0Pos = Eencoder0Pos + 1
    iF el_DN = 1 THEN Eencoder0Pos = Eencoder0Pos - 1
    IF az_WEST = 1 THEN Aencoder0Pos = Aencoder0Pos + 1
    IF az_EAST = 1 THEN Aencoder0Pos = Aencoder0Pos - 1
@ INT_RETURN

allSTOP:
GOSUB POS
WEST = 0
EAST = 0
UP = 0
DOWN = 0
el_UP = 0
el_DN = 0
az_EAST = 0
az_WEST = 0
pause 2000
return


CLR:
    For i = 0 to 30
        hserout [10]
    next i
return


TEST1:
Eencoder0Pos = 0
avg = 0
testloop:
gosub POS
el_UP = 1
UP = 1
for i = 1 to 30
pause 250
oldpos = newpos
newpos = Eencoder0POS
if oldpos > newpos then distance = oldpos - newpos
if newpos > oldpos then distance = newpos - oldpos
avg = avg + distance
hserout  ["Distance Travelled: ", #distance, 13, 10]
next i
gosub allSTOP
avg = avg/30
pause 1500
hserout  ["Test Complete. 1/4 Second Average was: ", #avg, 13, 10]
pause 5000
goto MainMenu
 
         



Startup:
    pause 2000
    gosub CLR
    hserout  ["Running Startup Procedures!", 13, 10]
    hserout ["PLEASE WAIT....", 13, 10]
    pause 3000
    Eencoder0Pos = 0
    hserout  [10, 10, "Eencoder0Pos Before is: ", #Eencoder0Pos, 13, 10]
        pause 2000
    Eoldposition = Eencoder0Pos
        DOWN = 1
        el_DN = 1
    pause 1000
        gosub allSTOP
    hserout  [10, "Eencoder0Pos After is: ", #Eencoder0Pos, 13, 10]
        pause 2000
    Enewposition = Eencoder0Pos
    hserout  [10, "Eoldposition is: ", #Eoldposition, 13, 10]
    hserout  [10, "Enewposition is: ", #Enewposition, 13, 10]
    pause 2000
    IF Eoldposition = Enewposition THEN
                stowed = 1
                apple = 1
                pause 5000
        gosub CLR
                hserout  ["Startup Sequence Good!", 13, 10]
                hserout  ["Continuing to Main Menu...", 13, 10]
        pause 3500
        goto MainMenu
        ENDIF
        IF Enewposition <> Eoldposition THEN
                stowed = 0
                apple = 0
                UP = 1
                el_UP = 1
        pause 1000
                gosub allSTOP
                gosub CLR
                hserout  ["Startup Error!", 13, 10]
                hserout  ["Dish will need homing before move will be allowed!", 13, 10]
        hserout  ["Continuing to Main Menu...", 13, 10]
        pause 5000
        goto Mainmenu
    ENDIF

MainMenu:
    gosub CLR
    hserout  ["******** MAIN MENU ********", 13, 10, 10]
    hserout  [" 1. Start Homing Sequence", 13, 10]
    hserout  [" 2. Manual JOG Mode", 13, 10]
    hserout  [" 3. Auto-Acquire Satellite", 13, 10]
    hserout  [" 4. Stow Dish for Travel", 13, 10, 10]
    hserout  ["Enter Your Selection:"]
    hserin [b0]
    If b0 = "1" then goto HomeDish
    If b0 = "2" then goto JogMenu
    If b0 = "3" then goto TEST1
    If b0 = "4" then goto Startup
goto MainMenu

HomeDish:
    gosub CLR
    hserout ["******** HOME DISH ********", 13, 10, 10]
    hserout [" 1. Start Homing Sequence", 13, 10, 10]
    hserout [" 2 Abort Homing", 13, 10, 10]
    hserout ["Enter Your Selection:"]
    hserin [b0]
    if b0 = "2" then goto MainMenu
    homeloop:
    IF b0 = "1" THEN
        gosub HomeEL
        'gosub HomeAZ
        HAZ = 1
        IF (HEL = 1) AND (HAZ = 1) THEN
            gosub clr
            hserout ["HOME PROCESS WAS SUCCESSFUL!", 13, 10]
            goto MainMenu
        ENDIF
        IF (HEL = 0) OR (HAZ = 0 ) THEN
            gosub clr
            hserout  ["DIS HOME PROCESS CAN SUCK MY DICK!", 13, 10]
            goto MainMenu
        ENDIF
    ENDIF
    pause(200)
    goto homeloop
goto HomeDish

HomeAZ:
    gosub clr
    hserout  ["HOMING AZIMUTH - PLEASE WAIT..", 13, 10]
    PAUSE(500)
    Aencoder0Pos = 0
    oldpos = 0
    WEST = 1
    az_WEST = 1
    PAUSE(250)
    IF Aencoder0Pos = 0 THEN
        gosub allSTOP
        EAST = 1
        az_EAST = 1
        PAUSE(250)
        gosub allSTOP
        PAUSE(500)
        Aencoder0Pos = 0
        WEST = 1
        az_WEST = 1
        PAUSE(500)
        IF Aencoder0Pos = 0 THEN goto moveerror
    ENDIF
    pause 1000
    loop4:
    pause 250
    oldpos = newpos
    newpos = Aencoder0POS
    if oldpos > newpos then distance = oldpos - newpos
    if newpos > oldpos then distance = newpos - oldpos
    if distance < 100 then
        gosub allSTOP
        Aencoder0Pos = 65000
        hserout  ["HOMING AZIMUTH WAS SUCCESSFUL!", 13, 10]
        HAZ = 1
    endif
    goto loop4
    az_EAST = 1
    EAST = 1
    loop8:
    pause 100
    if Aencoder0Pos > 0 then goto loop8
    return
 

HomeEL:
gosub clr
hserout  ["HOMING ELEVATION - PLEASE WAIT..", 13, 10]
PAUSE(500)
Eencoder0Pos = 0
el_UP = 1
UP = 1
PAUSE(250)
IF Eencoder0Pos = 0 THEN
    gosub allSTOP
    DOWN = 1
    el_DN = 1
    PAUSE(250)
    gosub allSTOP
    PAUSE(500)
    Eencoder0Pos = 0
    UP = 1
    el_UP = 1
    PAUSE(500)
    IF Eencoder0Pos = 0 THEN goto moveerror
ENDIF
    pause 1000
    oldpos = Eencoder0Pos
    loop3:
    pause 250
    newpos = Eencoder0POS
    hserout  ["oldpos = ", #oldpos, 13, 10]
    hserout  ["newpos = ", #newpos, 13, 10]
    if oldpos > newpos then distance = oldpos - newpos
    if newpos > oldpos then distance = newpos - oldpos
    if oldpos = newpos then distance = 0
    hserout  ["distance = ", #distance, 13, 10]
    oldpos = newpos
    if distance < 1 then
        gosub allSTOP
        Eencoder0Pos = 3000
        HAZ = 1
    hserout  ["HOMING ELEVATION WAS SUCCESSFUL!", 13, 10]
    goto safe_el
    endif
    goto loop3
    safe_el:
    el_DN = 1
    DOWN = 1
    loop9:
    pause 100
    gosub pos
    if Eencoder0Pos > 1500 then goto loop9
    return
 
JogMenu:
gosub CLR
pause 250
hserout  ["***** JOG MENU *****", 13, 10, 10]
hserout  ["U - UP", 13, 10]
hserout  ["D - DOWN", 13, 10]
hserout  ["E - EAST", 13, 10]
hserout  ["W - WEST", 13, 10]
hserout  ["S - ALL STOP", 13, 10]
hSEROUT  ["X - MAIN MENU", 13, 10, 10]
hserin [b0]
if b0 = "U" Then
    gosub allSTOP
    HIGH UP
    el_UP = 1
endif
if b0 = "D" then
    gosub allSTOP
    HIGH DOWN
    el_DN = 1
endif
if b0 = "E" then
    gosub allSTOP
    high EAST
    az_EAST = 1
endif
if b0 = "W" then
    gosub allSTOP
    HIGH WEST
    az_WEST = 1
endif
if b0 = "S" then gosub allSTOP
if b0 = "X" then
    gosub allSTOP
    goto MainMenu
endif
goto JOGMenu

ACQUIRE:
goto MainMenu

STOW:
goto MainMenu



abort:
gosub allSTOP
gosub clr
hserout  ["USER STOP! -- MOVE ABORTED!", 13, 10]
PAUSE(5000)
goto MainMenu

moveerror:
gosub allSTOP
gosub clr
hserout  ["SYSTEM ERROR! -- MOVE ABORTED!", 13, 10]
PAUSE(5000)
goto MainMenu

POS:
pause 100
hserout  ["  EL -- ", #Eencoder0Pos, "  AZ -- ", #Aencoder0Pos, 13, 10]
return

---

To set up Hserin/Hserout use defines here is what the manual says.


The serial parameters and baud rate are specified using DEFINEs:
' Set receive register to receiver enabled
DEFINE HSER_RCSTA 90h
' Set transmit register to transmitter enabled
DEFINE HSER_TXSTA 20h
' Set baud rate
DEFINE HSER_BAUD 2400
' Set SPBRG, SPBRGH directly
' (better to set HSER_BAUD instead)
DEFINE HSER_SPBRG 25
DEFINE HSER_SPBRGH 0

This is the way I use it but I know there are always alternatives.

http://www.picbasic.co.uk/forum/showthread.php?t=4994

Mistet E's Multicalc utility, just what you need for USART.

Robert

Hi,
The 16F1829 has analog inputs on PortA, PortB and PortC but you're only disabling it on PortA. You absolutely MUST read the datasheet for these things. A pin in analog mode may seem to work when used as an output (but it will eventually bite you (RMW issue etc)), however when you're trying to read the state of that output pin (which is what you're doing (or originally did) in the ISR it will not give you the correct result. This is also clearly stated in the datasheet:

Quote:

---

Setting the appropriate ANSELA bit high will cause all
digital reads on the pin to be read as ‘0’ and allow
analog functions on the pin to operate correctly

---

And the same thing applies for ANSELB and C of course. As you can see, if the ANSELx register isn't set correct any READ of that port-pin will return 0.

Also, I don't see you're using the ADC for anything yet you're setting ADCON1=7, why is that?

/Henrik.

http://www.picbasic.co.uk/forum/showthread.php?t=18529

If you want to see what you need to make pins digital.

Robert

Quote:

---

Originally Posted by HenrikOlsson

Hi,
The 16F1829 has analog inputs on PortA, PortB and PortC but you're only disabling it on PortA. You absolutely MUST read the datasheet for these things. A pin in analog mode may seem to work when used as an output (but it will eventually bite you (RMW issue etc)), however when you're trying to read the state of that output pin (which is what you're doing (or originally did) in the ISR it will not give you the correct result. This is also clearly stated in the datasheet:
And the same thing applies for ANSELB and C of course. As you can see, if the ANSELx register isn't set correct any READ of that port-pin will return 0.
/Henrik.

---

Ok sensei, but if that's the case, why did it work fine before? Does high/low set the pin to digital as well as setting the tris bit? Or just a fluke. When it comes to computers, I don't really put much stock in 'accidents' except in the context of "I accidentally screwed that up" lol

Quote:

---

Originally Posted by HenrikOlsson

Also, I don't see you're using the ADC for anything yet you're setting ADCON1=7, why is that?
/Henrik.

---

I am not sure why it's there. This code started out on a 877a then went to something else when I smoked all 5 of those. Then back to 877a when more came in, then to this 1829 when I smoked all the new 877a's. This 1829 is actually the PICAXE20M2 that got me started on PIC vs Arduino. I came up on two of them scrapping something and saved them. Later, while going thru stuff, I realized they were MC's, and then what PICAXE was, and here I am..... But the code has been cut and pasted, and gone from MPLABX to MCS so idk....

Quote:

---

Originally Posted by thasatelliteguy

This code started out on a 877a then went to something else when I smoked all 5 of those. Then back to 877a when more came in, then to this 1829 when I smoked all the new 877a's. This 1829 is actually the PICAXE20M2 that got me started on PIC vs Arduino. I came up on two of them scrapping something and saved them. Later, while going thru stuff, I realized they were MC's, and then what PICAXE was, and here I am..... But the code has been cut and pasted, and gone from MPLABX to MCS so idk....

---

I wasted many an unhappy day copying and pasting code that did not work.

I would start again and build up the program one step at a time. By adding small portions of code if the code stops working the small modification is the cause.

A good place to start is with the main menu, simply to test HSEROUT and HSERIN. Then take another very small step.

Hi,

Quote:

---

Ok sensei, but if that's the case, why did it work fine before? Does high/low set the pin to digital as well as setting the tris bit?

---

No, HIGH/LOW only handles the TRIS bit. I'm surprised, and a bit sceptical to be honest, that it really did work before. Then, of course, there might be something I'm missing - wouldn't be the first time, for sure.

When moving from one PIC to another you really do need to verify that what you set the registers to applies to the new chip as well. Usually it does but certainly not always - especially if you move from one series to another. CMCON is one example, someone searches the forum, finds a post where it says that CMCON=7 disables the comparators. This is true for the some PICs but not all.... It's tedious (some might even say boring) but reading the datasheet really is a must and you certainly do learn a lot from doing it.

/Henrik.

Or you do like me and let Alldigital tell you what to do. :D

I go to the datasheet when I need a specific feature.

Robert

Quote:

---

Originally Posted by Demon

Or you do like me and let Alldigital tell you what to do. :D

I go to the datasheet when I need a specific feature.

Robert

---

Well in this case I did that... It's just that it seems when trying to enable the hardware serial, there is A LOT of stuff to activate/set, and I just wasn't getting the combination correct. Still haven't... but haven't tried today either. I got sidetracked on another project... Gotta start a thread on that one now.

Quote:

---

Originally Posted by thasatelliteguy

Well in this case I did that... It's just that it seems when trying to enable the hardware serial, there is A LOT of stuff to activate/set, and I just wasn't getting the combination correct. Still haven't... but haven't tried today either. I got sidetracked on another project... Gotta start a thread on that one now.

---

Like I said, check this out. Tell it what you want and it gives you the settings.

Quote:

---

Originally Posted by Demon

http://www.picbasic.co.uk/forum/showthread.php?t=4994

Mistet E's Multicalc utility, just what you need for USART.

Robert

---

Robert

Quote:

---

Originally Posted by thasatelliteguy

... when trying to enable the hardware serial, there is A LOT of stuff to activate/set, and I just wasn't getting the combination correct. Still haven't...

---

Datasheet p. 118, APFCON0, bits 2 and 7.

The rest comes from Multicalc.

Robert

OK, I cannot get multicalc to run on any machine I have. It tells me there is a dll missing. I go get the dll, put it in the same folder, system32, windows, system, root, doesn't matter, it wont work.

As advised, I started over from scratch, inserting one section of code at a time. Since I could not ever solve the serial issues, I scrapped DT's interrupts. I guess they have many applications where it wouldn't matter, but it seems his interrupts, while probably faster and more reliable, seem to act on a lower layer and keep screwing with the layer above. Maybe I don't quite comprehend it yet, maybe I will someday, but for now, I'm tired of looking at this GD thing and I want it to work and be gone from me...

Now my problem has reversed itself. The serial is screwing with the interrupt. Go figure. The interrupt quits firing while serin waits for input. Can I fix this? I don't see anything obvious in the datasheet in the registers... The only this I could see was uart interrupt instead of serin command. But am I then back to having to get the hardware serial running again? Or will it work from any pin?

Code:

---

'****************************************************************
'*  Name    : GALAXYFINALBUILD.BAS                              *
'*  Author  : After 9 wks, Who the hell cares?                  *
'*  Notice  : Copyright (c) 2014                                *
'*          : You have the right to STFU!                      *
'*  Date    : 6/7/2014                                          *
'*  Version : 43046721.11                                      *
'*  Notes  : "Remember to fill the gas can in case it fails    *
'*          :  while showing boss how to operate..."            *
'****************************************************************

#CONFIG
    __config _CONFIG1, _FOSC_HS & _WDTE_OFF & _PWRTE_OFF & _MCLRE_ON & _CP_OFF & _CPD_OFF & _BOREN_OFF &  _CLKOUTEN_OFF & _IESO_OFF
    __config _CONFIG2, _PLLEN_OFF & _LVP_OFF
#ENDCONFIG

DEFINE OSC 20

ANSELA = 0
ANSELB = 0
INTCON.7 = 1
INTCON.4 = 1
OPTION_REG.6 = 1

LED var PORTC.7
TRISC.7 = 0
LED = 0
DOWN var PORTB.4
TRISB.4 = 0
DOWN = 0
EAST var PORTB.5
TRISB.5 = 0
EAST = 0
WEST var PORTB.6
TRISB.6 = 0
WEST = 0
RX var PORTC.4
TRISC.4 = 1         
TX var PORTC.1
TRISC.1 = 0
UP var PORTB.7
TRISB.7 = 0
UP = 0

a0 var byte
a1 var byte
i var byte
VerboseMode var byte
cereal var byte
Aencoder0Pos var word
Eencoder0Pos var word

ON INTERRUPT GOTO DoEncoder

VerboseMode = 1

goto MainMenu

DISABLE
doEncoder:
    if UP = 1 then
        Eencoder0Pos = Eencoder0Pos + 1
        if VerboseMode = 1 then serout TX, 2, ["Eencoder0Pos = ", #Eencoder0Pos, 13, 10]
    endif
    if DOWN = 1 then
        Eencoder0Pos = Eencoder0Pos - 1
        if VerboseMode = 1 then serout TX, 2, ["Eencoder0Pos = ", #Eencoder0Pos, 13, 10]
    endif
    if EAST = 1 then
        if a0 = 5 then
            Aencoder0Pos = Aencoder0Pos + 1
            A0 = 0
            if VerboseMode = 1 then serout TX, 2, ["Aencoder0Pos = ", #Aencoder0Pos, 13, 10]
        endif
        a0 = a0 + 1
    endif
    if WEST = 1 then
        if a1 = 5 then
            Aencoder0Pos = Aencoder0Pos - 1
            a1 = 0
            if VerboseMode = 1 then serout TX, 2, ["Aencoder0Pos = ", #Aencoder0Pos, 13, 10]
        endif
        a1 = a1 + 1
    endif
RESUME
ENABLE

MainMenu:
    gosub CLR
    serout TX, 2, ["******** MAIN MENU ********", 13, 10, 10]
    serout TX, 2, [" 1. Start Homing Sequence", 13, 10]
    serout TX, 2, [" 2. Manual JOG Mode", 13, 10]
    serout TX, 2, [" 3. Auto-Acquire Satellite", 13, 10]
    serout TX, 2, [" 4. Stow Dish for Travel", 13, 10, 10]
    serout TX, 2, ["Enter Your Selection:"]
    serin RX, 2, cereal
    if VerboseMode = 1 then serout tx, 2, [#cereal,13,10]
'    If cereal = "1" then goto HomeDish
    If cereal = "2" then goto JogMenu
'    If cereal = "3" then goto TEST1
'    If cereal = "4" then goto Startup
goto MainMenu

JogMenu:
    gosub CLR
    pause 250
    serout TX, 2, ["***** JOG MENU *****", 13, 10, 10]
    serout TX, 2, ["U - UP", 13, 10]
    serout TX, 2, ["D - DOWN", 13, 10]
    serout TX, 2, ["E - EAST", 13, 10]
    serout TX, 2, ["W - WEST", 13, 10]
    serout TX, 2, ["S - ALL STOP", 13, 10]
    serout TX, 2, ["X - MAIN MENU", 13, 10, 10]
    serin RX, 2, cereal
    if cereal = "U" Then
        gosub allSTOP
        HIGH UP
    endif
    if cereal = "D" then
        gosub allSTOP
        HIGH DOWN
    endif
    if cereal = "E" then
        gosub allSTOP
        high EAST
    endif
    if cereal = "W" then
        gosub allSTOP
        HIGH WEST
    endif
    if cereal = "S" then gosub allSTOP
    if cereal = "X" then
        gosub allSTOP
        goto MainMenu
    endif
goto JOGMenu

allSTOP:
    EAST = 0
    UP = 0
    DOWN = 0
    WEST = 0
    if VerboseMode = 1 then GOSUB POS
return

CLR:
    if VerboseMode = 0 then
        For i = 0 to 30
            serout TX, 2, [10]
        next i
    endif
return

abort:
    gosub allSTOP
    gosub clr
    serout TX, 2, ["USER STOP! -- MOVE ABORTED!", 13, 10]
    PAUSE(5000)
goto MainMenu

moveerror:
    gosub allSTOP
    gosub clr
    serout TX, 2, ["SYSTEM ERROR! -- MOVE ABORTED!", 13, 10]
    PAUSE(5000)
goto MainMenu

POS:
    pause 100
    serout TX, 2, ["  EL -- ", #Eencoder0Pos, "  AZ -- ", #Aencoder0Pos, 13, 10]
    pause 2000
return

---

Hi,
DT-Ints works at the hardware level. When an interrupt occurs it causes the PIC to (without intervention from the actual program) to jump to interrupt vector. From there it's up to the user to decide what needs to be done. In the case of DT-ints it first saves all the internal PBP variables then it executes the ISR "coupled" to the interruot sources you define. When it gets to the @INT_RETURN it restores the system variables and then continues the "original" program wherever it left it.

As you hopefully can see here, anything that is executing when the interrupt fires will be put "on hold" while the ISR is executing. If you're in the middle of a PAUSE 100 when the interruopt fires, those 100ms will be "extended" by for the duration of the ISR plus the time it takes to save/restore the system variables.

This is how interrupt works and there's nothing you can do about except write the code so that it doesn't rely on software timing etc. The only drawback with DT-Ints compared to using "real" interrupts at the ASM level is the time it takes to save and restore the system variables but it's something that needs to be done in order to be able execute PBP code in the ISR.

Now, ON INTERRUPT works differently. Instead of allowing the hardware to trip the interrupt at the hardware level it inserts code between each of of the PBP commands. The inserted code simply checks the interrupt flag and if its set it jumps to the ISR. Now, if an interrupt occurs during that same PAUSE 100 the interrupt flag won't be checked untill the PAUSE 100 is complete because the interrupt flag is polled between each PBP command. So yes, with ON INTERRUPT interruopt quits firing during SERIN or anything else really.

ON INTERRUPT allows you to use PBP commands in the ISR and self timed commands like PAUSE, SERIN, PULSIN, SOUND etc etc to work with the (very big) drawback of latency.

You really should concentrate on getting HSEROUT/HSERIN going. How's the hardware designed, do you have a MAX232 etc between the PIC and PC or are you running straight from the PIC? If the later then you need to invert the polarity of the EUSART output, something which can be done in the PIC - on some chips, I haven't checked the 16F1829.

/Henrik.

serin will stop the program until a key is pressed unless you add an optional time out

SERIN Pin, Mode,{Timeout, Label,}{[Qual...],}{Item...}

Why are you not using Hserin? I thought this issue had been solved, in another thread.

then maybe i did get it working... I got consistent gibberish at one point. I'm beginning to regret ever getting away from arduino. At least it could walk and chew gum at the same time which apparently pic cannot.

I'm using BT. come to think of it, I probably can't use EUSART. This is getting to be such BS.

Quote:

---

At least it could walk and chew gum at the same time which apparently pic cannot.

---

That's just so far from the truth that I'll simply honor it with a response of the same quality.
If you don't know what you're doing then it doesn't matter if it's an Arduino (ATMEL) or a PIC. People here, including myself, are actually spending a lot of time trying to help you but if the Arduino did the job so well then by all means, use it.

/Henrik.