Hardware ESC 8xSERVO CONTROL on PIC (Oshonsoft BASIC)

camerart · Feb 4, 2023

Pommie said:
Yes, everything will do it's thing and when it's complete it sets it's interrupt flag and generates an interrupt. If while a byte (from RS232) is being loaded into memory a timer 2 interrupt occurs then it'll interrupt once the current interrupt has finished. As all these things are happening at 8,000,000 instructions per second then nothing gets missed. An interrupt routine would have to be over 500uS (4000 instructions) long for an interrupt to be missed.

Mike.

Hi M,
My mate has the view, that as it was previously, with 18F4431 PORTB outputting BYTE, BYTE BYTE, in parallel to the SERVOS would be fine.
I explained the external 'shift register' method, which took a bit of explaining, and reluctantly, he accepted it.
I explained that I was going to try this method first, then perhaps compare it with the PORT method later.

I have your explanations about the CLK timings and have read them a few times, and think I get the instruction speed, and INT timings.
We then went on to precise timings, and what happens if 2xINTs arrive at once, the priorities and how they time into each other.

I posted on AAC, but hasn't been looked at, so we may be on our own?
C

Pommie · Feb 4, 2023

camerart said:
We then went on to precise timings, and what happens if 2xINTs arrive at once, the priorities and how they time into each other.

If two interrupts "arrive" at the same time then they will simply be dealt with in the order in the code. In this case, Timer 2 interrupt will be dealt with first and then CCP1 will be dealt with. However, the output pin will have already changed and so there is at least 0.5mS (the length of the on pulse) to deal with this. Which at 32MHz is an eternity.

The writing to port B method will always be glitchy and is why the shift register was added. The alternative was using a chip with PPS so the output of CCP1 could be moved.

Mike.

camerart · Feb 4, 2023

Pommie said:
If two interrupts "arrive" at the same time then they will simply be dealt with in the order in the code. In this case, Timer 2 interrupt will be dealt with first and then CCP1 will be dealt with. However, the output pin will have already changed and so there is at least 0.5mS (the length of the on pulse) to deal with this. Which at 32MHz is an eternity.

The writing to port B method will always be glitchy and is why the shift register was added. The alternative was using a chip with PPS so the output of CCP1 could be moved.

Mike.

Hi M,
I meant the SERVO and the GPS INT together, but I think priorities take care of that.

Portb v 'shift register' Well, we're trying yours first.

I'm trying to find a way of analysing, so many oscillations and interrupts, a log file for example.
C

Pommie · Feb 4, 2023

When a byte is received by the UART, it is placed in RCREG and an interrupt is generated. As long as that byte is removed before the next one arrives all will be well (or we'll get an overflow error). As the transmission is at 9600 baud a byte arrives approximately once every mS - an immense amount of time at 32MHz (8000 instruction cycles). That is enough time to execute all the interrupts many times over. If the timer 2 code is being executed and a byte arrives then it will finish the timer 2 code, execute the CCP1 code (if needed) and then deal with the UART code (which is omitted above).

As an exercise, I timed the CCP1 ISR and it takes 38 cycles to execute. The timer 2 ISR takes less than 30 cycles. As I said, ooodles of time. So worst case scenario if a byte arrives just as both interrupts trigger it'll be (much) less than 100 cycles before the byte is removed from RCREG and we've got 8,000 cycles to do it in. I doubt this code uses more than 1% of the available cycles.

Mike.

camerart · Feb 5, 2023

Pommie said:
When a byte is received by the UART, it is placed in RCREG and an interrupt is generated. As long as that byte is removed before the next one arrives all will be well (or we'll get an overflow error). As the transmission is at 9600 baud a byte arrives approximately once every mS - an immense amount of time at 32MHz (8000 instruction cycles). That is enough time to execute all the interrupts many times over. If the timer 2 code is being executed and a byte arrives then it will finish the timer 2 code, execute the CCP1 code (if needed) and then deal with the UART code (which is omitted above).

As an exercise, I timed the CCP1 ISR and it takes 38 cycles to execute. The timer 2 ISR takes less than 30 cycles. As I said, ooodles of time. So worst case scenario if a byte arrives just as both interrupts trigger it'll be (much) less than 100 cycles before the byte is removed from RCREG and we've got 8,000 cycles to do it in. I doubt this code uses more than 1% of the available cycles.

Mike.

Hi M,
I read you words, but it's better for me to visualise things.

I just tried a logic analyser, to see if it would work as a log, and I got the XTL to show=CLK.
I've now got to wire up any outputs, so I can connect the analyser properly, and it should print out everything, let's see.
C

Pommie · Feb 5, 2023

camerart said:
I've now got to wire up any outputs, so I can connect the analyser properly, and it should print out everything, let's see.

That'll be interesting. My C code analysis shows that it's doing what it's supposed to be doing. Let's see what your analysis says.
You really should learn C.

Mike.

camerart · Feb 5, 2023

Pommie said:
That'll be interesting. My C code analysis shows that it's doing what it's supposed to be doing. Let's see what your analysis says.
You really should learn C.

Mike.

Hi M,
Wiring the analyser, can be combined with wiring the 'shift register'. It's time consuming, as it's SMD.

I learnt BASIC in the 80s, by osmosis, and was offer 'C' but my brain doesn't work like a programmers, so it's impossible.
Having said that the brain bashing I've had translating your CODE, has taight me some things, and I can sort of see what your CODE does, but as for writing it, is a no go.
C

camerart · Feb 5, 2023

Hi M,
I've wired most of it. I attached the 'shift register' to the 18F4431.
+5, GND, CLK, DATA. The Pin signals are 3.3v, we'll see if they match?

Then I attached the logic analyser to the 'shift register' and the PIC 8mHz XTL.

The logic analyser is a Saleae with Logic 2.4.6 firmware. If you install it, you should be able to open one of the files attached, and zoom in and out, not sure.

CH0 is 8mHz XTL
CH1 is S/R CLK
CH2 is S/R DATA
CH3 is SERVO1
CH4 is SERVO2
CH5 is SERVO3
Nothing showing on the SERVO PINS so far.

Here are the files:
C

Pommie · Feb 5, 2023

That looks like it's only doing the first pulse every 20mS - first 0.1S has 5 pulses in it. If the data line is 1 and a clock pulse happens then the first output should go to one. I can't tell from your pictures if the data line is high when the first pulse arrives.

Mike.

camerart · Feb 5, 2023

Pommie said:
That looks like it's only doing the first pulse every 20mS - first 0.1S has 5 pulses in it. If the data line is 1 and a clock pulse happens then the first output should go to one. I can't tell from your pictures if the data line is high when the first pulse arrives.

Mike.

Hi M,
Could you open the link? I think I may have to send it in a PM. You will have to install the Saleae program, then you can zoom in and out and scan (I think)

EDIT: 0=Oscillator 1=CLK 2=DATA
C

Pommie · Feb 5, 2023

No PMs received and if I click the Google Drive link it just wants me to sign into mine.

Try right clicking on the file and select "copy link to clipboard" and PM the link.

Mike.

camerart · Feb 5, 2023

Pommie said:
No PMs received and if I click the Google Drive link it just wants me to sign into mine.

Try right clicking on the file and select "copy link to clipboard" and PM the link.

Mike.

Hi M,
I was asking your permission to send.
I sent it, but I think it needs an email, see mssages.
C

sagor1 · Feb 5, 2023

Pommie said:
When a byte is received by the UART, it is placed in RCREG and an interrupt is generated. As long as that byte is removed before the next one arrives all will be well (or we'll get an overflow error). As the transmission is at 9600 baud a byte arrives approximately once every mS - an immense amount of time at 32MHz (8000 instruction cycles). That is enough time to execute all the interrupts many times over. If the timer 2 code is being executed and a byte arrives then it will finish the timer 2 code, execute the CCP1 code (if needed) and then deal with the UART code (which is omitted above).

As an exercise, I timed the CCP1 ISR and it takes 38 cycles to execute. The timer 2 ISR takes less than 30 cycles. As I said, ooodles of time. So worst case scenario if a byte arrives just as both interrupts trigger it'll be (much) less than 100 cycles before the byte is removed from RCREG and we've got 8,000 cycles to do it in. I doubt this code uses more than 1% of the available cycles.

Mike.

RCREG is a 2 byte FIFO register. That is, it can store up to 2 bytes before it has to be read. If the PIR1.RCIF flag is still set after reading RCREG the first time, that means there is another byte still in the FIFO buffer waiting to be read. Keep reading RCREG until the RCIF flag is clear...
So, in theory, you have up to 2ms (and a bit more) to empty the RCREG at 9600 baud. If a third byte is received without emptying at least the first byte from RCREG, you get the overflow error bit. Even more time to handle interrupts than 8000 cycles....
See figure 19-6 in the 18F4431 datasheet

Pommie · Feb 5, 2023

sagor1 said:
RCREG is a 2 byte FIFO register. That is, it can store up to 2 bytes before it has to be read. If the PIR1.RCIF flag is still set after reading RCREG the first time, that means there is another byte still in the FIFO buffer waiting to be read. Keep reading RCREG until the RCIF flag is clear...
So, in theory, you have up to 2ms (and a bit more) to empty the RCREG at 9600 baud. If a third byte is received without emptying at least the first byte from RCREG, you get the overflow error bit. Even more time to handle interrupts than 8000 cycles....
See figure 19-6 in the 18F4431 datasheet

I tried to keep it as simple as possible. And as you said, there's even more time to do everything. As most transmissions are 1-8-2-N then each byte takes slightly longer than 1mS.
BTW, figure 19-6 is for I²C.

Mike.

sagor1 · Feb 5, 2023

Hm, maybe different dated datasheets? Mine may be older. My 19-6 is on page 234 and looks like:

Ok, found latest datasheet, Figure 20-6 is now the same as above... Sheeess...

Pommie · Feb 5, 2023

I'm using DS 39616d and this is on page 214.

Looks like mine has had an additional chapter inserted. UART is chapter 20. And figure 20-6 is the same as yours.

Mike.

camerart · Feb 5, 2023

Hi,
I recall seeing this before.
----------------------------
char = RCREG
char = RCREG
------------------------------------
I understand that it's from a different program, but I think it's the same principle?
C

Pommie · Feb 5, 2023

camerart said:
char = RCREG
char = RCREG

That is a very bad idea. RCREG is only valid if RCIF is set so the second read could be a random value.

Mike.

camerart · Feb 6, 2023

Pommie said:
That is a very bad idea. RCREG is only valid if RCIF is set so the second read could be a random value.

Mike.

Hi M,
Reading #413, it says read RCIF until the FIFO is clear. I assume that there's a flag that tells you it's empty.
I don't see where RCIF is read in your CODE.

EDIT: The data is not coming from the EUSART, but from the CODE, so if I'm correct, RCREG isn't involved
C

camerart · Feb 6, 2023

Hi,
I noticed this in an old program:
----------------------------------
RCON.IPEN = 1 'Must be included when using INTERRUPTS
-----------------------------------
C

Hardware ESC 8xSERVO CONTROL on PIC (Oshonsoft BASIC)

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Attachments

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Active Member

Well-Known Member

Active Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Attachments

Well-Known Member

Similar threads

Privacy & Transparency

Privacy & Transparency