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

[thasatelliteguy]

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

[HenrikOlsson]

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 ]



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.

[thasatelliteguy]

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

[thasatelliteguy]

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

[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

[thasatelliteguy]

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?

[HenrikOlsson]

Hi,


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.





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.




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.




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.




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.




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.

[EarlyBird2]

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.

[thasatelliteguy]

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.



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




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.




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!





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.

[HenrikOlsson]

Hi,

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.


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.



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.



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.

[thasatelliteguy]

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.

[HenrikOlsson]

Hi,


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



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.





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.

[thasatelliteguy]

check this out...
http://s1179.photobucket.com/user/thasatelliteguy/embed/slideshow/Galaxy%20Dish

[thasatelliteguy]

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

[Demon]

About the WORD limitation, how about DOUBLE WORD?

Use 2 WORD variables, use them in embedded loops.



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

[Demon]

check this out...
http://s1179.photobucket.com/user/thasatelliteguy/embed/slideshow/Galaxy%20Dish

That is cool!

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

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

[HenrikOlsson]

Hi,


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.

[Demon]

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

[thasatelliteguy]

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?

[HenrikOlsson]

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.

[thasatelliteguy]

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

[thasatelliteguy]

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?




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

[EarlyBird2]

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.

[Demon]

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

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

Robert

[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:

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.

[Demon]

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

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

Robert

[thasatelliteguy]

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



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

[EarlyBird2]

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.

[HenrikOlsson]

Hi,

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.

[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

[thasatelliteguy]

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.

[Demon]

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.


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

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

Robert

Robert

[Demon]

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

[thasatelliteguy]

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?



'************************************************* ***************
'* 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

[HenrikOlsson]

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.

[EarlyBird2]

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.

[thasatelliteguy]

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.

[thasatelliteguy]

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

[HenrikOlsson]

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.

[EarlyBird2]

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.

You said you got it working by using Hserin. Now you do not seem to be sure.

[thasatelliteguy]

I'm sorry guys. I was very very tired. I have a crazy learning curve, and sometimes when I push wide-open-throttle for too long cuz I've really bitten off too much, I burn out and crash. I've been asleep since Saturday... five weeks was just too long. I really do appreciate all the help! You all are great!

Can I use EUSART over BT HC-05? I would assume not since one is UART and one is EUSART...

If that's the case my problem is then:

1. I cant use DT's interrupts without corrupting my serin/serout. And I have to assume it'll corrupt hserin/hserout as well.
2. I can't use ON INTERRUPT cuz it'll miss pulses during even the shortest waits. This is even worse than #1 since the machine will be lost.

If I use serial interrupts and program loops, which from how arduino is structured, I assume that's what happens on that platform, wouldn't that solve my problem once and for all?

[thasatelliteguy]

You said you got it working by using Hserin. Now you do not seem to be sure.

No I never got it working using hserin. I can't even get multicalc to run. I DID get some rather consistent gibberish through hserin, but nothing more.

[EarlyBird2]

No I never got it working using hserin. I can't even get multicalc to run. I DID get some rather consistent gibberish through hserin, but nothing more.So are you saying you have got nothing to work? If this is the case then chose something and make it work. Henrik has suggested Hardware USART.

If what you do does not work then you are doing something wrong. Do not apportion blame elsewhere.

[Demon]

I may be wrong, but the only difference between SERIN and HSERIN is one is handled by software, the other by hardware. But the actual signal is identical, bluetooth shouldn't be able to know or care how it was generated.

Multicalc, you need a DLL possibly. It's in that thread. It works on my XP and WIN7 machines. You REALLY want to get this tool working, it does other things as well as the USART settings.

If an Arduino can do something, I don't see a reason why a PIC couldn't do it.

Robert

[EarlyBird2]

One difference is that Hardware USART requires an RS-232 driver but software does not. Also with software the pins are not fixed. Just need to take this into account when deciding which to use. Obviously if there is no RS-232 driver available then Hardware USART can not be used. I wonder if this is why he could not get HSERIN to work, could explain the gibberish he got.

[Demon]

Might be on to something. I forgot I use a MAX232 in my setup.

PC side uses more than 5V (12V I think), good thing a PIC can take a beating.

Robert

[Demon]

One difference is that Hardware USART requires an RS-232 driver...

Look what I found.

http://www.picbasic.co.uk/forum/showthread.php?t=10361&p=82591#post82591

Robert
:)

[thasatelliteguy]

Might be on to something. I forgot I use a MAX232 in my setup.

PC side uses more than 5V (12V I think), good thing a PIC can take a beating.

Robert

Jury's still out on the beating... I toast them at regular intervals doing far less nefarious acts to them.... However, they are, on whole, much cheaper to replace than arduino boards.

As far as the 12v tho, this 16f1829 chip I'm using now has been a hoss so far. And it started life as a PICAXE20M2. So when I first flashed it, it was with a home-made serial cable with no MAX232 or anything. Just straight out the serial port to the chip, so I think some chips will handle it better than most think...

[EarlyBird2]

Jury's still out on the beating... I toast them at regular intervals doing far less nefarious acts to them.... However, they are, on whole, much cheaper to replace than arduino boards.

As far as the 12v tho, this 16f1829 chip I'm using now has been a hoss so far. And it started life as a PICAXE20M2. So when I first flashed it, it was with a home-made serial cable with no MAX232 or anything. Just straight out the serial port to the chip, so I think some chips will handle it better than most think...
Have you a MAX232 connected to the Hardware USART pins?

[HenrikOlsson]

Hi,

Can I use EUSART over BT HC-05? I would assume not since one is UART and one is EUSART...
If SEROUT works with the HC-05 then HSEROUT will - as long as you get the polarity and baudrate correct. USART vs EUSART is just a matter of the features available they both do asyncronous serial and they both work with HSERIN/HSEROUT.


1. I cant use DT's interrupts without corrupting my serin/serout. And I have to assume it'll corrupt hserin/hserout as well.
That's correct and it's just the nature of the beast basically. It's not a problem, issue or bug, it's just the way the microcontroller works. If it's sitting in a tight software timed loop (which SERIN is) and an interrupt forces it to go and do something else the timing of that tight software loop is thrown off - nothing you can do about that.


2. I can't use ON INTERRUPT cuz it'll miss pulses during even the shortest waits. This is even worse than #1 since the machine will be lost.
That's also correct due to the reasons described earlier.


One difference is that Hardware USART requires an RS-232 driver...
Well, that depends..... For cabled connection to a PC it's a good idea to use a RS232 tranceiver for several reasons. Normally, the polarity of the USART output on the PIC is inverted in respect to what the PC expects. A typical RS232 tranceivers does two things. It "boosts" the signal voltage leverl so it falls within the specs for a proper RS232 connection and it inverts the signal so the PC can read it correctly.

Now, since we're talking about a Bluetooth connection here and it does work with SEROUT I probably wouldn't want to put a MAX232 between the PIC and the bluetooth module since it's most likely designed to operate at TTL levels. However, and as has been pointed out before, you need to watch the polarity and make it match whatever you're using with SEROUT. Either invert in in the PIC (if it's got that option) or use an external inverter between the PIC and the Bluetooth module.

Take a step back, write a small test program just for the HSEROUT/HSERIN part and get that working.

/Henrik.

[thasatelliteguy]

OK. I got multicalc working.
I got hserout working.
hserin - notsomuch.

My menu looks fine in the terminal. (although I can't test it with interrupts firing since I can't respond and mover the dish) But it just sits there and looks at me stupid when I give a command.



'************************************************* ***************
'* Name : UNTITLED.BAS *
'* Author : [select VIEW...EDITOR OPTIONS] *
'* Notice : Copyright (c) 2014 [select VIEW...EDITOR OPTIONS] *
'* : All Rights Reserved *
'* Date : 6/7/2014 *
'* Version : 1.0 *
'* Notes : *
'* : *
'************************************************* ***************
INCLUDE "DT_INTS-14.bas"
INCLUDE "ReEnterPBP.bas"


DEFINE HSER_RCSTA 90h ' Enable serial port & continuous receive
DEFINE HSER_TXSTA 24h ' Enable transmit, BRGH = 1
DEFINE HSER_SPBRG 129 ' 9600 Baud @ 20MHz, 0.16%
DEFINE HSER_CLROERR 1 ' Clear overflow automatically
APFCON0.2 = 1
APFCON0.7 = 1


#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


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


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
TRISC.5 = 1
UP var PORTB.7
TRISB.7 = 0
UP = 0






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






VerboseMode = 1


goto MainMenu




doEncoder:
if UP = 1 then
'if e0 = 5 then
Eencoder0Pos = Eencoder0Pos + 1
' e0 = 0
if VerboseMode = 1 then Hserout ["Eencoder0Pos = ", #Eencoder0Pos, 13, 10]
'endif
'e0 = e0 + 1
endif
if DOWN = 1 then
'if e1 = 5 then
Eencoder0Pos = Eencoder0Pos - 1
' e1 = 0
if VerboseMode = 1 then Hserout ["Eencoder0Pos = ", #Eencoder0Pos, 13, 10]
'endif
'e1 = e1 + 1
endif
if EAST = 1 then
if a0 = 5 then
Aencoder0Pos = Aencoder0Pos + 1
A0 = 0
if VerboseMode = 1 then Hserout ["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 Hserout ["Aencoder0Pos = ", #Aencoder0Pos, 13, 10]
endif
a1 = a1 + 1
endif
@ INT_RETURN




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 [cereal]
if VerboseMode = 1 then HSEROUT [#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
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 [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
HSEROUT [10]
next i
endif
return


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]
pause 2000
return

[EarlyBird2]

Are you saying these lines do not execute?

hSERIN [cereal]
if VerboseMode = 1 then HSEROUT [#cereal,13,10]

[thasatelliteguy]

Are you saying these lines do not execute?

hSERIN [cereal]
if VerboseMode = 1 then HSEROUT [#cereal,13,10]

correct

[EarlyBird2]

Are you saying these lines do not execute?

hSERIN [cereal]
if VerboseMode = 1 then HSEROUT [#cereal,13,10]

correct


HSERIN is not receiving anything then?

[thasatelliteguy]

HSERIN is not receiving anything then?
that's correct

[EarlyBird2]

The issue has nothing to do with HSERIN or the program. As you have a MAX232 could you connect direct to your PC and use HyperTerminal to test the functioning?

[richard]

have a look at this thread for some ideas on serial transmission with interrupts
http://support.melabs.com/threads/281-DT-Interrupt-Serial

[EarlyBird2]

The BT modules could be the issue have they got Flow Control on the RS232. A data sheet would help.

[HenrikOlsson]

Hi,
If SERIN/SEROUT without flow control works across the BT-link (which it apparently is) then HSEROUT/HSERIN will work too. It's just a matter of getting it setup correctly.
Having an oscilliscope or logic analyzer and probing the signals as it enters/exits the PIC would help. Doing so with the "working" version using SEROUT/SERIN and the with the HSEROUT/HSERIN comparing what you get would most likely reveal the issue.

/Henrik.

[EarlyBird2]

If SERIN/SEROUT without flow control works across the BT-link (which it apparently is) then HSEROUT/HSERIN will work too.


My understanding is that serin never worked but serout did, post #44, which is why I suspect flow control, we were given the wrong impression when we were told using hardware usart had solved the problem. Do we need more information? or will this lead to more misinformation depending on how I read it.

[thasatelliteguy]

Hi,
If SERIN/SEROUT without flow control works across the BT-link (which it apparently is) then HSEROUT/HSERIN will work too. It's just a matter of getting it setup correctly.
Having an oscilliscope or logic analyzer and probing the signals as it enters/exits the PIC would help. Doing so with the "working" version using SEROUT/SERIN and the with the HSEROUT/HSERIN comparing what you get would most likely reveal the issue.

/Henrik.
Flow control.... hmmmm. Makes me think I may have somethiny else amiss... could it be terminal settings? Serin/serout works fine. I have hooked up an LED to the rx on the pic and I see it flicker on data send. I havent tried to cross the tx/rx to look for echo but I suspect ill get it. Was there something I needed to change in the terminal program to make the data "legit" ? I seem to remember a flow control dropdown box......

[thasatelliteguy]

I suppose I can also scope the data coming out of the bt and into the pic, but I dont think itll yield much more than seeing the led flicker... unless you want me to somehow capture and post the raw scope results to actually interpret them

I'll be back home in about an hour if you would like me to do that...

[EarlyBird2]

The flow control I was thinking of was between the 16f1829 and the BT connected to it.

[thasatelliteguy]

OK! I think I have my permanent solution. Since I had no problems with the first setup I did with this project where I was using physically attached buttons instead of serial commands to control the unit, I am adding a second PIC, whose only job in life is to sit at a serin command pause and await commands. Upon receiving a command, it will simply set a pin high for about 100ms, simulating a button press. Proof of concept already works... Just have two small snags... (and a large one too, but one step at a time lol)
1. I am trying to send via serial just one character. Capital A-F, depending on what combo of buttons is pressed by the user. It's not going thru. The BT is linked. The link seems good. When I hold a button down, it causes the serin pause to release, causing my debugging LED to flash. However, no command is processed. I'm sure it's a format problem or something, but I have tried 9 ways to sunday and I just can't seem to spot what I'm doing wrong. Also, if I shut down the master BT and log my laptop terminal into the dish PIC, sending A-F from the terminal works perfectly and it responds as expected.

2. Only buttons 3 and 4 work. Buttons 1 and 2 do not cause the LED to flash on the receiving end. I assume I'm missing something again about analog/digital, but this pic is very basic and has no ADC, and for the life of me I cannot figure out what I am missing. I have read thru every register in the datasheet, and I'm just not snapping to what it is...

Here is the code for the handheld device:


'************************************************* ***************
'* Name : Wireless Handheld Device
'* Author : John Moore
'* CHIP : PIC16F628A
'* Date : May 28, 2014
'* Version : 1.0
'* Notes : This pic will eventually have 4 physical buttons and an LCD
'* : as well as a BT device. Right now I just need it to send the
'* ; serial commands, as I am monitoring the feedback with a terminal.
'************************************************* ***************
#CONFIG
__config 10000111110000
#ENDCONFIG

button1 var PORTA.2
button2 var PORTA.3
button3 var PORTA.4
button4 var PORTB.3
TRISA.2 = 1
TRISA.3 = 1
TRISA.4 = 1
TRISB.3 = 1
cereal var byte
TX var PORTB.2
TRISB.2 = 0
START:
if button1 = 1 then cereal = "A"
if button2 = 1 then cereal = "B"
if button3 = 1 then cereal = "C"
if button4 = 1 then cereal = "D"
if (button2 = 1) and (button3 = 1) then cereal = "E"
if (button1 = 1) and (button4 = 1) then cereal = "F"
if cereal <> "X" then serout TX, 2, [cereal]
pause 100
cereal = "X"
GOTO START


Here is the code for the PIC16F628A that is receiving the commands and "pressing buttons":


'************************************************* ***************
'* Name : On-Board Communication PIC
'* Author : John Moore
'* CHIP : PIC16F628A
'* Date : May 28, 2014
'* Version : 1.0
'* Notes : This pic will never be more complicated than this. It's only
'* : purpose in life is to get characters and push buttons.
'************************************************* ***************
#CONFIG
__config 10000111110000
#ENDCONFIG

button1 var PORTB.7
button2 var PORTB.6
button3 var PORTB.5
button4 var PORTB.4
TRISB.7 = 0
TRISB.6 = 0
TRISB.5 = 0
TRISB.4 = 0
button1 = 0
button2 = 0
button3 = 0
button4 = 0

RX var PORTB.3
TRISB.3 = 1
LED var PORTA.1
TRISA.1 = 0

cereal var byte

START:
serin RX, 2, cereal
if cereal = "A" then
high button1
pause 140
low button1
endif

if cereal = "B" then
high button2
pause 140
low button2
endif

if cereal = "C" then
high button3
pause 140
low button3
endif

if cereal = "D" then
high button4
pause 140
low button4
endif

if cereal = "E" then
button2 = 1
button3 = 1
pause 140
button2 = 0
button3 = 0
endif

if cereal = "F" then
button1 = 1
button4 = 1
pause 140
button1 = 0
button4 = 0
endif
LED = 1
pause 250
LED = 0
pause 250
GOTO START

[richard]

bit 7 of your config word should be 0 , having lvp enabled can lead to tears .
the comparator needs to be disabled to use your porta pins as digital

[Tobias]

So you have your BT sorted out?

I use a BT chip on my boards with no converter. I have the BT chip running at 3.3v just like the PIC.

I am not sure what you are meaning by handheld device but if you are using a BT chip, look into making the app work on your Android phone.

Look into Basic4Android. Its a piece of cake to use. The wireless side is a bit cumbersome but once you get it going, its pretty slick. I use it to make an app to control up to 48 electrical motors sending data back and forth from the motor control boards to a tablet all wirelessly.

http://www.basic4ppc.com/index.html

If you get try it and need some help, email me at [email protected]

[thasatelliteguy]

bit 7 of your config word should be 0 , having lvp enabled can lead to tears .
the comparator needs to be disabled to use your porta pins as digital

A thousand thank-yous my friend! It worked beautifully!