Remote control by location (PIC in Oshonsoft)

Thread Starter

camerart

Joined Feb 25, 2013
3,838
hi C,
Please, Data Type and Format, of #rot. ?
Also, what is the measurement parameter?
E
Hi E,
I'm not good at word meanings, but do you mean WORD for DATA TYPE. I don't know what format means, sorry. I use LAT for analog inputs, and #ROT is 0 to 3.3V. I hope that answers you?
C
 

ericgibbs

Joined Jan 29, 2010
21,458
hi,
OK, I am trying to help you, but it's difficult if I don't know what you are asking.:)

As examples: consider #rot, you say its value is from 0V thru 3.3V.
This could be, depending upon the unit that's sending the Data
in
as ASCII characters "0.0" thru "3.3" [including the DP]
or in HEX as 00 thru 21 [represented as 0x00 thru 0x21
or BINARY Bits 00000 thru 10001
or DECIMAL 00 thru 33

If you wanted to Display the Value say, on an Alpha Numeric LCD, ASCII Format is OK.
If you wanted to use the Value in a numeric calculation, Decimal format is OK

Say the Value was in HEX or Binary and you need to display and say also use the value in a calculation, you would have to Convert the HEX value to ASCII for the LCD and Decimal for the calculations,

Oshonsoft does have Commands to do these conversions.

E
Post an ACTUAL message string and I will try to interpret the formatting.
 

Thread Starter

camerart

Joined Feb 25, 2013
3,838
hi,
OK, I am trying to help you, but it's difficult if I don't know what you are asking.:)

As examples: consider #rot, you say its value is from 0V thru 3.3V.
This could be, depending upon the unit that's sending the Data
in
as ASCII characters "0.0" thru "3.3" [including the DP]
or in HEX as 00 thru 21 [represented as 0x00 thru 0x21
or BINARY Bits 00000 thru 10001
or DECIMAL 00 thru 33

If you wanted to Display the Value say, on an Alpha Numeric LCD, ASCII Format is OK.
If you wanted to use the Value in a numeric calculation, Decimal format is OK

Say the Value was in HEX or Binary and you need to display and say also use the value in a calculation, you would have to Convert the HEX value to ASCII for the LCD and Decimal for the calculations,

Oshonsoft does have Commands to do these conversions.

E
Post an ACTUAL message string and I will try to interpret the formatting.
Hi E,
Post an ACTUAL message string and I will try to interpret the formatting.
I posted the actual message that goes between the MASTER and REMOTE in #1234, and here: Hserout "$BORI", ",", #ud, ",", #rot, ",", #fr, ",", #lr, ",", strcmd, ",", strprs, ",", strspr, ",", strqeideg, ",", "W", CrLf

I think it's perhaps best that I convert all of the #VARIABLES in the STRING to STRINGS. As you can see by e,g STRCMD, I've done it before and I'm sure I can do it this time.
It may not be the most efficient, but I'm sure it can be improved later when tidying up. I'll make a note.
The reason is, I'm just in a complicated (for me) section of programming, and I don't want to break anything.
I'll ask the question again later, if I haven't figured it out.
Thanks for your patience,
C.
 

Thread Starter

camerart

Joined Feb 25, 2013
3,838
Hi All,
Update:
All peripherals on both BASE and REMOTE are working and the two are 'talking' to each other :)
Here's an image of the readout. You may be able to spot a mistake?
There's quite a bit of tidying up to do, but for me this is a milestone.
C
 

Attachments

Thread Starter

camerart

Joined Feb 25, 2013
3,838
Hi,
The 18f4431 is READing an incremental encoder [QEIDEG], and passing it to 18F46K20 PIC, via SPI.
Here is the section of CODE where it READs it, but it gives an error!
any clues as to where they are coming from please?
C
 

Attachments

Thread Starter

camerart

Joined Feb 25, 2013
3,838
Hi,
The artifact in #1246 has dissapeared, and with no replies, I'll leave that for now.

Progressing nicely!
With the LCD screen, I can see what's happening without using the radio link, which is for control. When using the radio link, there were lots of clashes, once BASE and REMOTE are both running. No 'mainly' only the control signals from MASTER, plus a return from REMOTE e,g, Batt voltage etc

Each module PARSES it's message ok, but they are tooo slow.
How can I sync the 2x messages so that they TOGGLE alternatively, please?
C
 

Thread Starter

camerart

Joined Feb 25, 2013
3,838
Hi,
Update:
I'm using a toggle switch 'TOFRO', so when either REMOTE or BASE RECEIVES a sentence and PARSES it, it then sends a TOFRO=1 in it's message which when RECEIVED by the other, does the same. I think this will replace that particular GUARD that 'JT' included when he edited the programs.
It's kind of working, and I've given it to my mate to iron our the creases, while I go on to MOTOR CONTROL.
C
 
Last edited:

Thread Starter

camerart

Joined Feb 25, 2013
3,838
Hi,
I've been trying to merge 2x programs into one:
It's just too difficult for me, I've been trying for weeks.
When they are both together one breaks.
Here are the programs, if anyone can help please?
NOTE: There is no need for the DATASWITCH now, or NEXT CHANNEL, as there is only 1x channel on this PIC.
C
 

Attachments

Thread Starter

camerart

Joined Feb 25, 2013
3,838
Hi,
Here's the best I've come up with:
I don't think it needs the INCLUDE?
(PIC2 Reads the QEIDEG (incremental encoder Degrees) and the GPS.) At the moment only QEIDEG is sent to PIC1 via SPI.

Left of the screen shot is the output of PIC1 and right PIC2, shown on computer terminal view.
PIC1 shows the QEIDEG and Joysticks plus temp/press (which is not correct!)
PIC2 shows the GPS RX input.
NOTE: the QEIDEG is not robust, and at overflow, where it should reset to '0' it always goes to 386.
C
 

Attachments

Last edited:

Thread Starter

camerart

Joined Feb 25, 2013
3,838
Hi,
Since #1250, I've been looking at the 2x programs separately, and the QEIDEG on PIC2 especially.

In #1250 the QEIDEG overflows and always shows 386. I have just got it to show 386 then correct, then 386 then correct, so I may be able to find why it does this?
C
 

sagor

Joined Mar 10, 2019
1,050
You should really clean up the code. You have functions like recv_rx and send_tx that are not called anywhere in the program. You initialize EUSART with baudcon, spbrg, etc which is pointless as HSEROPEN does that for you later.
You initialize MSG1="" before you declare that variable as a string. MSG1 is not used anywhere either, as Proc send_string is never called.
 

Thread Starter

camerart

Joined Feb 25, 2013
3,838
You should really clean up the code. You have functions like recv_rx and send_tx that are not called anywhere in the program. You initialize EUSART with baudcon, spbrg, etc which is pointless as HSEROPEN does that for you later.
You initialize MSG1="" before you declare that variable as a string. MSG1 is not used anywhere either, as Proc send_string is never called.
Hi S,
My method of programming is, mainly cutting and pasting, which is my skill level, but I will check those parts you mentioned, thanks.
EDIT: I've just found a 3x year old program for QEIDEG, which I'm looking at first.
C
 

Thread Starter

camerart

Joined Feb 25, 2013
3,838
You should really clean up the code. You have functions like recv_rx and send_tx that are not called anywhere in the program. You initialize EUSART with baudcon, spbrg, etc which is pointless as HSEROPEN does that for you later.
You initialize MSG1="" before you declare that variable as a string. MSG1 is not used anywhere either, as Proc send_string is never called.
Hi S,
I've cleaned up the CODE as best as I can and posted it here:
The SPBRG, has been commented out, but it neeeds investigation, later.

Since cleaning up, the GPS interrupt has stopped, but the QEI is fine, and sending it's DATA to PIC #1 MASTER via SPI, as expected.
C.
 

Attachments

sagor

Joined Mar 10, 2019
1,050
Hi S,
I've cleaned up the CODE as best as I can and posted it here:
The SPBRG, has been commented out, but it neeeds investigation, later.

Since cleaning up, the GPS interrupt has stopped, but the QEI is fine, and sending it's DATA to PIC #1 MASTER via SPI, as expected.
C.
Of course interrupts have stopped, as you clear INTCON at the beginning and never enable interrupts after that...
 

ericgibbs

Joined Jan 29, 2010
21,458
hi C,
How can the program read the contents of the ISR if it has not been given access Enable to the ISR .?
E

BTW: the ISR is Code 'bloated', you will have problems.
 

Thread Starter

camerart

Joined Feb 25, 2013
3,838
hi C,
How can the program read the contents of the ISR if it has not been given access Enable to the ISR .?
E

BTW: the ISR is Code 'bloated', you will have problems.
Hi E,
I don't understand what this actually means, but there are guards, that protect against blocking, or lost signals, so I think they should stay. I'll contact the member that wrote that section of CODE, in case he can remedy it. I have changed it since it was written, as some of the peripherals, that were inside, have been moved, as their not on this PIC.
Thanks,
C
 
Last edited:
Top