Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

Drive 33 Servos With One PIC + USART

Status
Not open for further replies.
I'm treading a completely different path. My buffer is only 20 bytes long, arranged as length, mask. Outputting the buffer is pretty trivial. Building the buffer is the headache.

Mike.
 
I wonder if you could use 128 bytes of RAM as a 1024 bit interval buffer with up to eight '1' bits somewhere in that buffer indicating when to exclusive-or the output port with a value from another 8 byte array? Not quite sure if it's doable but I'll check it out this coming week.
 
Last edited:
All intriguing ideas. I will get to this later also. Business doubled this week. Got a couple hundred new RGB dotmatrix's in... still waiting for the TS GLCD's and the new prototype TS RGB GLCD. Maybe they'll be here Monday.
 
wschroeder said:
All intriguing ideas. I will get to this later also. Business doubled this week. Got a couple hundred new RGB dotmatrix's in... still waiting for the TS GLCD's and the new prototype TS RGB GLCD. Maybe they'll be here Monday.
Great news. Forgive me for asking on the Forum but I seem to have lost my Thunderbird email profile so my email isn't working... Can I expect that order sometime soon after you get caught up Sir?

Mike
 
I will ship to you as soon as the new GLCD's come in from China. They put me off by 2 weeks. Even the US Navy and Canadian Dept of Defense are waiting... really.. ;) I have the tracking number, so it should be soon, probably Monday or Tuesday.
 
Back to the topic of workable multi-channel hi-rez Servo code for 16F' devices...

I think I may have a method that provides a variable number of steps at 1 usec resolution using very few ram locations. I'll try coding an example for 1024 steps which would require 24 ram locations for the ISR driver and then 2 locations for each Servo array element. Like the method Mike (Pommie) is brain-storming, this method also requires a lot of work setting up those 24 variables.
 
A 1uS version on the 16F would be impressive. Would that also handle the serial as well. I have 2uS code for a 20MHz and 4uS code that uses the 8MHz internal oscillator and both manage to do serial with a fifo at 115.2K & 19200.

I'll post them when I get a working example of the buffer build code (got most of it working just no time to tidy it.). It probably won't be until after Christmas as I'm away most of next week.

Mike.
 
I haven't been able to squeeze serial input into the 1 usec update code which was 16 MHz (4 cycles per microsecond) so it looks like I will also be going with a longer update interval. I'm also having a hard time building serial input code without the 18F' movff instruction (grin).

Looking forward to seeing your method and I'll keep working on mine too.

Happy Holidays. Mike
 
I used a trick to get the serial working. I only check the serial if the count has bit 2 set. This gives a worst case scenario between serial checks of 3*4*8 = 96 cycles where each servo is 3 periods apart.

Here's the ISR code for the 8 cycle routine. It's not well commented but you should be able to follow it. Note, this hasn't even been assembled and definitely not tested!

Code:
		movlw	ServoBuffer
		movwf	FSR
		movlw	0xff
		movwf	PORTA		;0   set all on.
Wait		btfsc	INDF,2		;1/2 it set then we have 32 cycles to read serial and test for exit
		goto	DoSerial	;3   exit on 3
		incf	FSR,F		;3
		movfw	INDF		;4   prefetch port value
		decf	FSR,F		;5
Enter		decfsz	INDF,F		;6/7
		goto	Wait		;8
		movwf	PORTA		;8
		movlw	3		;0
		addwf	FSR,F		;1   point to next port value
		movfw	INDF		;2   prefetch incase time = 1
		decf	FSR,F		;3   back to time count
		goto	Enter		;5

DoSerial	movfw	FSR		;4   save the pointer
		movwf	FSRtemp		;5
		decf	FSR,F		;6   point to last port value
		movfw	INDF		;7   get it
		btfsc	STATUS,Z	;8/9 if it was zero, were done
		goto	Done		;    exit on 10
		btfss	PIR1,RCIF	;10/11
		goto	NoSerial	;    exit on 12
		incf	FifoStart,W	;14  get fifostart + 1
		andlw	FifoLength-1	;15  make it circular
		movwf	FifoStart	;16  
		addlw	FifoBuffer	;17  add start of buffer
		movwf	FSR		;18  put in indirect pointer
		movfw	RCREG		;19  get the received byte
		movwf	INDF		;20  put it in fifo
		movfw	FSRtemp		;21  restore the pointer
		movwf	FSR		;22
		decf	INDF,F		;23 - 8 = 15  reclaim 8 cycles
		decf	INDF,F		;15 - 8 = 7   and again
		decf	INDF,F		;7 - 8 = 2    and again
		nop			;3
		goto	Enter		;5

NoSerial	movfw	FSRtemp		;11  restore pointer
		movwf	FSR		;12
		decf	INDF,F		;13 - 8 = 5  reclaim 8 cycles
		goto	$+1		;7
		goto	$+1		;9
		decf	INDF,F		;9 - 8 = 1   and again
		goto	$+1		;3
		goto	Enter		;5

Mike.
Merry Christmas.

Edit, it also doesn't have the initial delay etc.
 
Last edited:
So then, that must be the 8 MHz code with 4 usec 'step' size. Oh boy, I'm looking forward to studying it. At first glance it seems we're trying similar methods using counters...

That 16 MHz 1 usec 'step' code I was contemplating was an "unrolled" loop but I forgot about caching serial data. Oh well...

Code:
T1      movf    Val_01,W        ;
        decfsz  Tmr_01,F        ;
        goto    T1              ;
        xorwf   PORTB,F         ;
T2      movf    Val_02,W        ;
        decfsz  Tmr_02,F        ;
        goto    T2              ;
        xorwf   PORTB,F         ;
T3      movf    Val_03,W        ;
        decfsz  Tmr_03,F        ;
        goto    T3              ;
        xorwf   PORTB,F         ;
T4      movf    Val_04,W        ;
        decfsz  Tmr_04,F        ;
        goto    T4              ;
        xorwf   PORTB,F         ;
 
Last edited:
Since Mike K8LH has helped me think a little differently in my approach to code problems by judiciously using the abundance of PIC18 RAM to great advantage in developing his hirez servo positions, I think it's time to push the envelope with ROM when it comes to PIC16. Also note that controlling 33 servos from a PIC16 might only be possible from something like the new 16F887 running with its internal oscillator, which maxes at 8 MHz.

Here's my conceptual approach without having done any work yet on the problem, and it may provide some fodder for good minds. I once considered puttting a RETURN instruction at the last address of ROM and then calling various ROM addresses a given number of addresses before the RETURN instruction to create virtual delays, that is, delays that did not require any code or code loops. This is because when a PIC's ROM is cleared it becomes a nice series of NOP's, or single cycle instructions. This should work as long as you know how much ROM is left at the end of your MCU.

Imagine putting a RETURN instruction at the last address of the '887, or least at a known address. Since the servo period of 0 to 2500us is essentially a delay, it should be possible to make a Call to an address the number of addresses before the RETURN to create the necessary time delay.

A PIC16 will only allow 8 Calls since this is the maximum of the Stack. But over 20ms all 33 servos might get handled.

What do you think?
 
Last edited:
That's certainly a good concept for a delay routine but I'm not sure how you'd use it for a 16F' servo controller where we're really trying to do a lot in just a few cycles (over and over again).

Regards, Happy Holidays, Mike
 
How about a Servo-64 solution using a 28 pin 18F2620 and eight 74HC238 decoder IC's? It's an off-shoot from the 2.5 Kb buffer K8LH Soft-32 controller 'method'. It just won't support digital "on/off" outputs but I'm brain-storming a way to fix that using a latch or flip-flop IC instead of the decoder IC.

Happy Holidays everyone...
 
Hi Mike,

Yes, you're probably right... it was an idea that popped into my head.... not necessarily a good one.
 
Last edited:
I have not been treated more badly by any other forum administrator/moderator than this one...whoever it is doing this. In fact, I have never been banned from any forum, save this one. Passing notes publicly in the signature of my postings is possibly the worst form of decorum for someone in charge. I have email.
 
OK, quite simple answer - I responded in the same way you did - you made your point, I made mine in exactly the same way. If you had contacted me privately then I'd have responded privately.

I'll repeat again for you - if you want to advertise your commercial site please contact the administrator about advertising rates!.
 
Nigel,

I must say I'm shocked to think that someone could possibly try and rationalize attaching those messages to someone elses posts. That must be the tackiest thing I've witnessed here.

May I ask if there's an authority, other than you, with whom I could lodge a complaint?

Sincerely,

Michael McLaren, K8LH
 
I also think that Warren's treatment is a little harsh. Considering he has only 55 posts, his contributions are very informative.

Mike.
 
Status
Not open for further replies.

Latest threads

Back
Top