Add GPS/PARSE to 8xSERVO-MOTOR CODE in Oshonsoft

Status
Not open for further replies.
Sort by date Sort by votes
Hi,
I compared the HW working CODE with the last CODE posted, and commented out with [ '/ ], it now works, so the problem seems to be in the commented out sections. This is the equivelent of SEROUT in OSH

I'll work through these lines, to see if I can figure it out.

EDIT: I commented in the [ '/ ] lines from the earlier file posted here, 'now gone', till the SERVO stopped moving, and now there only a few lines, that 'break' it.
C
 

Attachments

  • 18F4431 32MHz XTL REMOTE SLAVE GPS SERVO 010323 1436 test.txt
    7.7 KB · Views: 284
Last edited:
Upvote 0 Downvote
I haven't been following along, but it looks like you're trying to use TMR5 along with CCP2 to generate a bit-banged UART (for what ever reason).

On that device, CCP2 can't use TMR5 as a clock source. In capture/compare modes the CCP peripherals can only use TMR1.

TMR5 is a special beast... it has it's own period register (PR5H : PR5L) and the TMR5IF interrupt bit is in PIE3/PIR3 bit 0
 
Upvote 0 Downvote
At 9600 baud each bit time is approx 104us.

The max error for a UART is about 5%, so that only allows for about a 5us variation in the bit timing, which at 32MHz translates to 20 ASM instructions. That's probably eaten up by the 'Save System' alone.

With all those other interrupts going on I can't see a software uart working, even one driven by a timer.
What's wrong with the hardware UART?

EDIT - strick some of that timing above. The output is generated by a periodic intr, so as long as the isr time doesn’t exceed half the bit time you'll probably be OK. Still, that could be a problem...
 
Last edited:
Upvote 0 Downvote
Hi T,
Thanks for dropping in and letting me know about the TMR5 issue with the CODE.

I'm not skilled enough to understand the details, but without you having to go too deep, can you imagine a solution?
C
 
Upvote 0 Downvote
Yes, I incorrectly thought the CCP2 module could use any 16 bit timer as it can on many other pics - one of the problems of not being able to test it. I'll look at the code later to see if it can be salvaged. Busy with other code ATM.
tumbleweed said:
The max error for a UART is about 5%, so that only allows for about a 5us variation in the bit timing, which at 32MHz translates to 20 ASM instructions. That's probably eaten up by the 'Save System' alone.
Click to expand...
This doesn't matter, the bits are relative to the start bit so if ALL bits are delayed by 1 hour (instead of 5uS) then it'll still work. Edit, I see your edit now, I'm assuming that the time for 9 bits (start+8data) cannot exceed 1/2 a bit error I.E. 50uS total so ~10uS per bit. I don't count stop bits as they are a low value and intrinsic to the code.

tumbleweed said:
What's wrong with the hardware UART?
Click to expand...
Seems it's used for something else!!!

Mike.
 
Upvote 0 Downvote
Hi M,
The UART RX is used for the GPS input, and the UART TX is an SS/CS input for the SPI. I hope that's not a conflict?
C
 
Upvote 0 Downvote
camerart said:
The UART RX is used for the GPS input, and the UART TX is an SS/CS input for the SPI. I hope that's not a conflict?
Click to expand...
I see. I went back and read through some of the thread. Sorry I didn't see that.

So this PIC has to be an SPI slave also? I would think that's another interrupt to deal with, although sync'ing an SPI slave and master can be very tricky (I see it's just polled in some of the original code). The slave needs to know when a new packet begins/ends, and on the master side it never knows if the slave is ready to receive a byte.
 
Upvote 0 Downvote
I just realised, software UART could be done with uS accuracy using CCP2. Timer 1 is already running at 2MHz.

I'll have a go later.

Mike.
Edit, yes, 500nS accuracy.
 
Upvote 0 Downvote
Hi T,
To clarify:
There are 2x pairs of pics. BASE and REMOTE (connected via radio) ach of the pairs is connected VIA SPI, controlled by each master.
This thread is for pic4 which is controlled by pic3 SPI.
My mate is working on the SPI's, and maybe a while.
C
 
Upvote 0 Downvote
Pommie said:
I just realised, software UART could be done with uS accuracy using CCP2. Timer 1 is already running at 2MHz.

I'll have a go later.

Mike.
Edit, yes, 500nS accuracy.
Click to expand...
Hi M,
The SW UART is for me to monitor what's going on as the CODE develops, and won't be used when in full swing, and I can monitor using SPI and an analyer, which is not as convenient.
Whatever you choose.
C.
 
Upvote 0 Downvote
Pommie said:
I just realised, software UART could be done with uS accuracy using CCP2. Timer 1 is already running at 2MHz.

I'll have a go later.

Mike.
Edit, yes, 500nS accuracy.
Click to expand...
If you're already using TMR1 then I don’t think that'll work. To get a periodic timer you have to use Compare mode special event trigger, which will reset the timer.
 
Upvote 0 Downvote
tumbleweed said:
If you're already using TMR1 then I don’t think that'll work. To get a periodic timer you have to use Compare mode special event trigger, which will reset the timer.
Click to expand...
Or compare and set/reset output pin. This is what the servo output uses which leaves timer 1 free running. Adding n to CCPR will generate an interrupt n/2 instructions later.

Mike.
 
Upvote 0 Downvote
If I follow, if you leave TMR1 free-running then you have to keep adjusting CCP2 to generate the uart timing.

I've never used it, but I think you were on the right track with TMR5. It looks to be a combination of a TMR + compare mode CCP peripheral. You'd just have to adjust your use of CCP2 to match TMR5 registers/TMR5IF.
 
Upvote 0 Downvote
You pointing out that CCP2 can't be used by timer 5 was the hint that made me realise that I can use timer 1. Yes, I do need to keep adjusting CCPR2 but it's simply, CCPR2+=208; I.E. an interrupt every 104uS. The output pin will also automatically be set high/low by hardware so timing is not an issue - as long as it's within ~800 instruction cycles.

The compare mode used is one of the two that set/reset the output pin,


Or, if no change desired then the 1010 mode to just generate the interrupt. It should be interesting if I can get this software (or is it semi-hardware) UART to work.

Mike.
 
Upvote 0 Downvote
It should be interesting if I can get this software (or is it semi-hardware) UART to work.

Hi M,
Yes, it would be useful.

I can try any HW tests, at your convenience.
C.
 
Upvote 0 Downvote
Pommie said:
The compare mode used is one of the two that set/reset the output pin,
Or, if no change desired then the 1010 mode to just generate the interrupt. It should be interesting if I can get this software (or is it semi-hardware) UART to work.
Click to expand...

I've done a "hdw assisted software uart" using various TMR+CCP combinations, but never used that method before to generate the output. It will be interesting to see if it works out... at first glance it seems like it would.

The only issue I see is you need to set the mode based on the current output state + desired next output state (since changing the mode to 1000 or 1001 will set the IO pin level), but that shouldn't be too bad. Cool if it works out!
 
Upvote 0 Downvote
Pommie said:
Can you just cut/paste it here? I went looking for #446 etc but just got lost.
What is the idea?

This is a link to #446. Are you suggesting having a frame variable again? This is already implemented.

Mike.
Click to expand...
Hi M,
From what I understand, the CODE you are working on, has a difficulty because of running out of TIMERS, as both CCP's are used for the SERVO 'shift register' 1x for the CH times X8, and 1x for the FRAME, leaving a lack of TMR for the GPS.

I suggested that if only 1x CCP was used for the CH's, so 8XCH and the 9th time is the rest of the FRAME time, this would leave the second CCP for the GPS.

If this is what you did, and I haven't understood how it all works, then disregards this.
C.
 
Last edited:
Upvote 0 Downvote
The servos only use CCP1 to do the pulses and the gap.

Mike.
Edit, timer 1 is also used but is never altered so it is free running and can be used for other timing.
 
Upvote 0 Downvote
Status
Not open for further replies.

Similar threads

Using the IDE simulator (Oshonsoft).
Replies
14
Views
2K
DogFlu66
B
Moving from mikroBasic to OshonSoft Basic
2 3
Replies
44
Views
6K
Ian Rogers
  • Question
Library for TM1651 (Oshonsoft Basic).
Replies
12
Views
2K
DogFlu66
B
CONFIG3H (OshonSoft P18 Simulator IDE)
Replies
6
Views
1K
bcz
B
  • Question
Library for LCD19264 with UC1609C display (Oshonsoft)
2
Replies
25
Views
4K
Nigel Goodwin
Menu
Log in
Register
Cookies are required to use this site. You must accept them to continue using the site. Learn more…