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

[camerart]

Hi,
Here is CODE for 18F4431 8xCH SERVO-MOTOR CODE using a shift register: https://www.electro-tech-online.com/threads/oshonsoft-interrupt-parse.159316/

Add GPS and PARSE CODE to the above CODE, in the same way.

Camerart

 

[camerart]

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

 

[tumbleweed]

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

 

[tumbleweed]

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

 

[camerart]

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

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

 

[Pommie]

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

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.

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.

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.

What's wrong with the hardware UART?

Seems it's used for something else!!!

Mike.

 

[camerart]

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.

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.


Seems it's used for something else!!!

Mike.

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

 

[tumbleweed]

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?

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.

 

[Pommie]

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.

 

[camerart]

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.

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

 

[camerart]

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.

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.

 

[tumbleweed]

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.

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.

 

[Pommie]

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.

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.

 

[tumbleweed]

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.

 

[Pommie]

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.

 

[camerart]

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.

 

[tumbleweed]

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.

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!

 

[camerart]

Hi,
Earlier I came up with an idea!
I don't know if it is better or worse than the path at the moment, but if you have another look and choose which is best.
Here: https://www.electro-tech-online.com...control-on-pic-oshonsoft-basic.163337/page-28
#446-#448
C.

 

[Pommie]

Earlier I came up with an idea!

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.

 

[camerart]

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.

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.

 

[Pommie]

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.