November 29, 2013

Raspberry PI Slave board for industry

Board Features :

  • 7-35V DC input
  • 24 Inputs/Outputs (MCP23S17)
  • 16 Analogue 0..5V CMOS inputs
  • 8 bits stacking bus system : up to 8 modules on the Bus, with write/read/latch controls
  • 6 bits FAST i/O port
  • SPI expansion port
  • RTClock (SPI)  providing 96bytes NVRAM for data backup ( backup battery : 3V button cell )
  • native LCD support for debugging if needed
  • MCU : 18F4520 @ 40MHz + firmware update/create PORT
Software features (currently under development)
  • The Firmware provides execution of micro-code chunks asynchronously to the raspberry PI cpu clock
  • Code loops, conditonnal jumps, comparisons are executed at precise time intervals, no matter the interrupts that can happen on the raspberry PI linux system.
  • micro code commands are industry oriented processes (automation,control, low level drivers…)
Code parser, loader, saver, and test

Code parser, loader, saver, and test

PI-Slave board plugged on top of the PI

PI-Slave board plugged on top of the PI

Debug LCD and some Led MAtrix connected for testings

Debug LCD and some Led Matrix connected for testings

Closer view showing (front) the 2 MCP23S17 (18F4520 MCU + Analogue MUX IC are located on the bottom side of the board )

Closer view showing (front) the 2 MCP23S17 (18F4520 MCU + Analogue MUX I.C are located on the bottom side of the board )


May 23, 2010

A remote 4 SERVOs Driving module diagram

Filed under: PIC progs and schematics — Tags: , , , , , — admin @ 6:48 pm

I’ve moved and been away for a little time…

Now i’m back with a project about the remote control of servomotors with a PIC as controller , and discrete ICs to generate the correct timings pulses necessary to drive the servos.

In the way i look at the things, i’m having trouble with the fact that the PIC microcontroller could be used only as a PWM generator, that’s the reason why i decided to develop a remote board , that could take in charge the generation of correct sized pulses in the 20ms period , providing that the PIC has pre-loaded the duration time into each timers.

I came out with a concrete solution designed to be stack-able and easily customizable for all of you , robots addicts ! It uses 4516 CMOS counters and 4011 classic CMOS gates

Take a look at this ( click to enlarge )

So what the hell is that ?

The clock for each counters is the same one , a 8KHz tunable clock, wich input is ‘clock in’ on my diagram.

A ‘load pulse’ is generated on the counter’s ‘Sx_LOAD’ input : it enables the loading of the data PD0,PD1,PD3,PD4 (binary) into the selected counter ( each of them have a separate ‘load data’ line ).
Each counter is counting down so it will be set at the binary value PD when the ‘load pulse’ is applied, then imediatly after the pulse has come to the low level, they will start counting down.In this mean time, the ‘carry out’ pin of the counter gets High, hence the ‘SERVO_x’ pin also.
When then counter reachs the ‘zero’ value, it’s ‘Carry Out’ gets low. so the generated ‘SERVO_x’ pulse will also get down, and the NAND gate then disables the clock to reach the counter’s clock input : the counter stops counting.

Then a new cycle can start again, by loading a new value into PD by a ‘load_pulse’ on the related pin, after , in the case of servomotors driving, around 20ms (minus the servo pulse time) of waiting time.

I could have added a 2->4 decoder onto the 4 servo board, but i have first decided to keep the ‘Sx_LOAD’ as-is to keep that diagram simple and easily customizable.

One of the important thing is that the counters are 4 bit counters, wich means that the servo will have a 4 bit resolution for positioning, hence a 11.25° resolution. ( 16 * 11.25° = 180° ) .

The timing are also important to understand :

A standard servo is operating from around 0.5ms to 2.5ms pulse length ( thats what i’ve experienced for my side ).
If you get deeper into my diagram logic, you’ll catch that the generated ’servo pulse’s’ duration is the sum of the ‘load_pulse’ time with the counter’s preset datas down count.
If we use a 0.5ms ‘load pulse’ duration, the preset datas combined with the 8KHz clock pulses will provide a covering of the needed time range , from 0.5ms to 2.375ms.

With that kind of remote timers, the robot’s microcontroller just has to manage the ‘load pulses’ and PD datas each 20ms.

Some of you could ask : so and..whats the gain there ?

If the microcontroller takes 0.5ms for each ‘load pulse’, and each load pulse must come every 20ms, then we can achieve a 40 servos driving with one microcontroller (theorical calculation)
Practically lets take a look at a 32 servos system :

  1. 4 Bits port for PD ( duration data )
  2. 6 Bits port for Servo Selection ( a 6 to 32 decoder , wich routes the ‘load_pulse’ to the needed servo) + 1 extra bit to enable decoding.

We have around 11 output Port-bits to achieve a 32 servo driving system - lets say it’s 12bits.
The only routine we have to code is a timer routing into the microcontroller.This routine has to happend every 20ms.
Each time the routine is executed, it programs PD0,PD1,PD2,PD3 of servo number ‘N’ then it programs the ’servo select’ port (6bits) , with the number ‘N’ , then sends a pulse of 0.5ms duration enabling the servo selection decoding (a ’decode_and_load_enable’ bit).
then the routine skips to the next servo in the list and repeat the cycle from the start : programming PD0,PD1,PD2,PD3, for the next servo ,  and so on for the 32 servos.

As we’ve already seen before,  if we use 32 servos, the complete routine will take about 0.5ms x 32 = 16ms.
So we are free with an extra processor time of about 4ms before the 20ms deadline.
If for example, we use a PIC18F @ 32MHz , those 4ms mean a lot of instructions and time to do other stuff than just driving the servos : our microcontroller has now time to do interesting stuff like converting probe datas , doing neural computations and so on , as a 4ms time @32 MHz means 32000 instructions.

Stay tuned !



cat{ } { post_69 } { } 2009-2015 EIhIS Powered by WordPress