Proton BASIC Community

Hi All,
I'm looking for some very general thoughts on how to go about reducing a 2 micro project down to a single micro.  It's not about cost - just removing the need for 1 micro to tell another what it's doing.
The current project uses a stepper motor running in 1/4 step mode with variable pulse rates from 800uS up to about 5000uS.  It has to stop, start and reverse without losing count of where it is.  I also need to update an OLED display using a second micro which is fed data from the stepper micro over a one way 115.2kb serial link.   It all works fine as the display data is sent between stepper pulses even though the display only updates every 500mS.  It is painful having to send various fields of data to the display board and wondered how you would go about doing it in a single micro.   I should mention that the data payload sent to the display takes about 600uS and to refresh the display takes about 60mS so it's not like you can interrupt the stepper drive to blurt it out.
My first thoughts were to use the PWM and generate the stepper pulses as a background task and this works well but how do you count PWM pulses up and down without it becoming a foreground task again?  If I could find a way to stop and start on a given pulse count yet still update the display I'd be very happy but it seems to me I need two real-time processes.  Any thoughts would be welcome.

Cheers,
David

Is using a dual core PIC an option?

Quote from: david on Oct 16, 2024, 09:20 PMIf I could find a way to stop and start on a given pulse count yet still update the display I'd be very happy but it seems to me I need two real-time processes.  Any thoughts would be welcome.

You can tie the PWM output to Timer0 or Timer1 clock input pin and generate a hardware Timer interrupt to trigger PWM event.

David,

As Ken points out, an alternative would be to go to a DsPic33.

I have used a DsPic33FJ128GP706A @80MHz and they are fast. I use it to generate 200Hz signals that are internally sampled at 4KHz. I do all this with various timers and interrupts, as well as servicing a 115kps serial port also using interrupts. I have problems with times under 5us, since the latency of the interrupts starts to be a problem.

The DSPIC CK series is even faster and cheaper.

Regards,
Gamboa

Many thanks for the replies folks.
I'm not familiar with dual core PICs as my background is more at a hobby level.  You have perhaps confirmed my thoughts that this is a need for two, real time processes.   Would such a device still need to communicate between the two cores?  If so then it doesn't really change my situation as it wouldn't matter if my link is 100mm or 2mm.

trastikata,
I'm currently using Tmr0 and loading a variable in to it, doing a heap of other logic stuff, sending the serial data to the display and then waiting (briefly) for the overflow flag to be set.  Timing is tight with little spare time but both the pulse duration and the serial are at least off the same clock source so can't catch up with each other.  The main delay is the serial data but I don't really want to consider increasing the baud rate up to 230400 even though it appears to be reliable.  The device I'm using is a 16F1824 running at 16MHz. I could run it faster but I'll never have the time be able to talk directly to the OLED display, hence the serial data to the other PIC.
Perhaps what I'm currently doing isn't a bad approach and the thought of learning a new, dual core PIC is a bit much for this old dog.
Thanks again for your support.

David

Hi David

What you could perhaps look at is using a 18F Device that has Hardware already built in with the Motion Feedback Module,
for example the PIC18F2431 to run the Interrupts from the encoder of the stepper motor.

Regards
Craig

Hi Craig,
That's quite a stroppy device for sure and I would need to study it in more detail.  I could use the PWM in the device I have now but the problem I have is that the shortest stepper period is around 800uS and a full write to the OLED display takes about 60mS so I would have to "free run" the stepper PWM for that period before I can stop it or change its speed.  That may still be acceptable but currently I can change speed or stop on a pulse by pulse basis.   
I think a 60mS control latency should be ok as long as I can keep track of the pulse numbers. 
Thanks for your interest.  The fog is starting to lift a bit.....

Cheers,
David

Quote from: david on Oct 17, 2024, 07:34 AMtrastikata,
I'm currently using Tmr0 and loading a variable in to it, doing a heap of other logic stuff, sending the serial data to the display and then waiting (briefly) for the overflow flag to be set.  Timing is tight with little spare time but both the pulse duration and the serial are at least off the same clock source so can't catch up with each other.

Hello david,

I had in mind different kind of setup...

Timer0 and Timer1 have designated pins at which you can clock the timer from an external source instead of the main clock. That external source can be your PWM.

So if you use for that purpose Timer1, thus by bridging the PWM pin with the T1CKI pin, Timer1 will increment on every pulse from the PWM pin. Now if you preload Timer1 with the remainder of (65535-command pulse command count) every time new PWM command is issued, Timer1 will generate a hardware interrupt once the PWM command finishes.

If you arrange the PWM commands being generated from within the interrupt, rest of the time you can send code to the OLED and if an interrupt happens to pause the OLED transfer, it won't be even noticeable.

Demo Proteus stepper with oled

Quote from: trastikata on Oct 17, 2024, 04:14 PMHello david,

I had in mind different kind of setup...

Timer0 and Timer1 have designated pins at which you can clock the timer from an external source instead of the main clock. That external source can be your PWM.

So if you use for that purpose Timer1, thus by bridging the PWM pin with the T1CKI pin, Timer1 will increment on every pulse from the PWM pin. Now if you preload Timer1 with the remainder of (65535-command pulse command count) every time new PWM command is issued, Timer1 will generate a hardware interrupt once the PWM command finishes.

If you arrange the PWM commands being generated from within the interrupt, rest of the time you can send code to the OLED and if an interrupt happens to pause the OLED transfer, it won't be even noticeable.

Hello trastikata,
That's an interesting idea for me to try.  As mentioned, I'm currently using the Tmr0 overflow flag but could also use its interrupt, but your approach also has the counting I need.   I may need to reconsider the chip I'm using as presently I have Tmr1 as a real time clock and my PWM is currently generating a 0 - 4V analog signal for driving another motor speed control.  There's no problem finding chips with more than one PWM and more timers.
My key takeaway from your post is the thought of interrupting the OLED drive.   I always think the sky will fall down but the reality is that I have 10uS wide stepper pulses occurring at a maximum rate of every 800uS.  I need to try some of these ideas and perhaps prove I don't need to interleave the operation of two micros.
Many thanks for your input.

Cheers,
David

Quote from: Pepe on Oct 17, 2024, 06:06 PMDemo Proteus stepper with oled

Hello Pepe,
Thanks for your example but I've never used Proteus before - what do I need to view it?

Cheers,
David

Install proteus version 8.16

Hmmmm.   Tough choice - expensive or illegal......
Thanks for the example but I'll work on the approach trastikata outlined for a bit.

David