Home Projects Swarmbots Swarmbots documentation
Swarmbots documentation PDF Print E-mail
Monday, 26 October 2009 13:14

Swarm Robotics

Project Documentation

- Internal use only -

Dereck Wonnacott, Jake Weinmann

IEEE Student Chapter
Lake Superior State University

Project Definition

Swarm robotics is the study of systems of robots that interact as a single unit to achieve a common goal. The goal of this project is to form a strong foundation of practical knowledge in the field of swarm robotics by building a swarm robotic system. Using the knowledge gained from this project the members of this project should be able to complete a given task using swarm robotics technology.

The first challenge is to define what we wish to accomplish with our swarm. With such an open-ended project we need some clear goals to constrain our efforts to something attainable. The project is therefore broken into a Prototype Phase and a Task Phase.

Prototype Phase


This phase of the project is to learn about the low level aspects of swarm robotics. Familiarize ourselves with the PIC microprocessor and various sensors that will potentially be used is the primary focus for this phase of discussion. Control of each node's hardware as a single unit is the first goal, including obstacle avoidance and proximity detection. Basic communication between each node is the next major task to overcome. Finally, we remove the focus from the node and look at the swarm as a single unit and attempt to control the swarm as a single entity. The goal here is to have three nodes that can move in an indoors environment together in a swarm. This lays the framework for the task phase where the swarm will be retooled and given a task to accomplish.

Plan of Attack

  1. Sensor research
  2. Peripheral selection
  3. Select Micro-controller
  4. Control LEDs
  5. Read sensors
  6. Control actuators
  7. Chassis prototype
  8. RF Communication Protocol
  9. Position awareness*
  10. Swarm Motion
  11. Environment awareness
  12. Task selection for swarm

Sensor Network Design

To accomplish a given task with a robotic swarm, the team will first look at the sensors that are available to us in a budget situation. Here we select the components that we wish to purchase for prototyping and gather data on usage and availability.

The end result will in hope be nodes made from a single custom PCB with surface mount devices (opposed to through hole components). The LSSU Prototype and Development Center (PDC) has a pick-and-place robot for assembly of PCBs as well as an oven and solder screen for the soldering process. It is my hope that we can use these facilities for our task phase. During component selection try to choose components with a SMD package as well as a PDIP or breakout package for prototyping.

Important information to gather in each of the sensor's sections is operating voltage: min, typ, max; Current draw, Surface Mount Device (SMD) device availability as well as cost.


A triple-axis accelerometer was chosen so that when a node tilts or is picked up, this motion can be detected. it will also allow for collision detection in three dimensions. There are relatively inexpensive modules available that require no interfacing that are suitable for prototyping. If the third axis is, in fact, not necessary it should be removed for future designs.

The MMA7260Q Triple Axis Accelerometer is one such low-cost device. There is a reasonably-priced development board available for prototyping that is readily available from mouser.com. There is very little interfacing circuitry and it has built in temperature compensation and low-pass filter.

Vdd (v)
Idd (mA) 0.5
Proto Cost
SMD Cost
Sensitivity (mV/g)

http://www.sparkfun.com/commerce/product_info.php?products_id=252 http://www.mouser.com/Search/ProductDetail.aspx?R=MMA7260QTvirtualkey55700000virtualkey841-MMA7260QT

Yaw Rate Sensor [Gyroscope]

In effort to allow a node to drive in a straight path, rotational drag from the drive system must be detected and compensated. Accelerometers can detect tilt parallel to the surface of earth due to the acceleration caused by gravity, therefore a single axis yaw rate sensor will provide ample data while minimizing the number of A/D channels required.

The LISY300AL is an exceptionally low-cost device that performs at 300deg/second rotation. It is also available in a breakout package that allows for quick and easy prototyping.

Vdd (V)
2.7 - 3.3 - 3.6
Idd (mA)
Proto Cost
SMD Cost

http://www.sparkfun.com/commerce/product_info.php?products_id=8955 http://www.mouser.com/Search/ProductDetail.aspx?qs=sGAEpiMZZMvhQj7WZhFIADzkRRoaTp86rMZCacdV9wI%3d

IR Proximity Sensor

WIP: Jake,Joe,Dereck

Obstacle avoithe major cdance is one of hallenges that the node must perform autonomously. Feedback about the surroundings of the robot will need to be rapid and accurately detect dangerous areas. IR proximity detection should allow the node to detect walls and other obstacles before colliding with them. Likewise IR proximity detection should allow us to see where stairs or table edges are, and avoid them. 

Ambient IR radiation from the sun as well as florescent lighting is going to be a challenge to overcome. One way do deal with this problem is to modulate the node's IR source at some high frequency which does not occur in nature. A high-pass filter can be made to filter out the "DC bias" allowing the node to differentiate between proximity IR and ambient IR.

When multiple nodes are inm. There have been numerous ideas on how to solve this problem; time would be better spent on other problem some area, the may interfere with one another's IR proximity detection systes until our first node has been built.

Bonus features include the ability for nodes to do some communication via IR if that deems necessary.  

TIP: Digital cameras can usually 'see' IR light. If in doubt that a device is emiting or not, look at it with a digital camera.

Component Selection
IR emitters have a few key options: wavelength, angle, and current usage. The transmitter and emitter must be matched in wavelength; the largest number of components on mouser.com where rated for 940nm.

Emitting IR light is done with an IR LED. Receiving IR can be done with two different devices, a phototransistor or an IR receiver module. Read on below for specifics on those devices.

Cost (USD)
IR Receiver Module

Dereck initially selected a cheap unit that had both the emitter and transmitter in one unit. The ASDL-3007-021 is designed for data communications and has filtering build into the device. It can be interfaced to a microcontroller with only power decoupling capacitors as stated in the data-sheet. These IRDA modules where too small for prototyping as they are SMD packages.

The next parts order contained IR LEDs with a wavelength of 940 nm. For detection of IR, Dereck purchased a few different devices. The first three items are photo transistors of 10, 20, and 30 degree detection angles. Also ordered was an IR receiver module that will output a digital 'high' when it detects a 38Khz IR signal. This potentially takes some of the work off of the CPU by reducing the amount of white noise entering the system and digital filtering that we must do. These reduce the flexibility of the system, as well as increases cost slightly.

Phototransistor Notes 

Experiment Results [Dereck]
emitter: 4mA
receiver: 30 uA
V1: 5v
range: 0-2ft
signal: analog 0-5v

The circuit is very simple and produces an analog voltage that can provide ranging information. If the IR LED is pointing directly at the phototransistor, the phototransistor becomes a short and output is zero volts. If there is no IR light, the phototransistor becomes an open circuit and voltage becomes V1. In the configuration shown in the diagram above, when there is no object within the viewable range, output is 1v; output increases as an object enters the range and becomes closer.

This is a great starting point for a proximity detection system. This is only step one, as it is not "multi-node" safe. It also gives no indication of where the object is that is within range without some scanning operation.

Further experiments show that the IR LED wasn't even needed, apparently the lab lighting was providing the IR light. Interesting, I'm not sure how we can filter this out.

I put a 'switch' between V1 and R1, with R2 still connected to V1 and was able to combat the room lighting to some degree. Tapping the switch turns on the LED for a 'burst' of IR light that is then visible on the output as a sort of pulse. Assuming the light in the room is constant, this could be filtered and used to differentiate between IR that is not from the node itself.

Varying the pulse width with time might even allow us to detect our own IR signal from other robots.

Detecting a peak-to-peak voltage [Vpp] of some critical value may indicate that we are too close to something and need to take note.

Turning off the lab lights increased Vpp by 150mV with an object in fixed location. This stands to reason that we cannot rely on Vpp for absolute ranging, but only a relative ranging.

Increasing the number of IR LEDs increased Vpp significantly when the object remained the same distance from the detector.

The smaller the distance is between the LED and phototransmitter, the better Vpp responds to an object in range and being able to see the object.

  1. http://www.seattlerobotics.org/guide/infrared.html
  2. http://www.gorobotics.net/articles/sensors/building-an-infrared-proximity-detector
  3. Opto Components INFRARED LED 940nm
  4. 940nm led emitter data sheetInfrared Receiver Modules 4.5-5.5V 38kHz
  5. Infrared Phototransistors Phototrans Clear
  6. http://optodatabook.liteon.com/DataBookFiles/11693/R309.pdf

Theremin Vision Sensor (WIP: Jake/Joe)

The Theremin Vision Sensor is a good possibility for proximity detection, in complement to IR sensors.  The theremin vision system seems like it will cost approximately $7. Each CMOS timer needed (part # LMC555CN) is priced at $1.73 on digikey, so it will be $6.92 for 4 of them.  Each corner of the robot needs a theremin vision sensor to detect proximity of objects and relative size.  The basic idea is that objects in "view" of the antennae will result in a capacitance change, which results in a frequency change in the CMOS timer, which the microprocessor can detect on the 100 HZ range (Check the reference pages for a much better explanation).  Capacitance changes are relative to the size and proximity of the object, meaning large objects will cause a greater change in capacitance, and close objects will cause a greater change as well.  This system requires a clock on the microcontroller and an offset clock on each sensor.



Similar kind of system that might be interesting to play with.


From the PIC interfacing point of view almost every implementation I have found utilities two pins. One pin to initiate a ping and one to listen for an echo. There is one unit that can do both on one pin, but that would limit us in the respect that we would not be able to ping any faster than 50ms which may or may not be an issue. From the RS385 lecture I recall Dr. Jones mentioning that we need to be able to update our environmental data every 20ms or so. 20ms translates to a sample frequency of 50 Hz and requires at least two sonar on each robot to meet that goal.

Another issue is crosstalk between sonar units in the same area. A potential solution would be to have an array of transceiver units on board each node which would rapidly send out a 'packet' of pings in some form of bit pattern. The receiver should listen for that sequence to insure that it has heard an echo form itself and not another node's ping. Should a node receive a ping from another node or an echo from another location, it would not match the pattern that was sent and be discarded.

One idea to keep costs down and to make use to the properties of a swarm is that we could put a single sonar on each node and coordinate the pings for each node. If the nodes could direct their pings in a given direction and then swam in such a way that the pings always faced away form each other, this would maximize the efficiency of the data collection

For the sake of progress and getting some hardware built. I think we should start with a single sonar module and see it's performance. Then If it does not work, add multiple devices to each node. The goal of a swarm is that the nodes are useless on their own but together they can accomplish a task and this will be one of many use cases for swarms. Sensors can be spread out over the entire swarm.



It might be interesting to give a node a compass. As long as one node knows it's orientation it may advertise this to the rest of the swarm. These modules are decently expensive, making a good case of building a heterogeneous swarm of node capabilities.


Same concept as adding a compass in that only one node need to know it's position wrt the planet. As long as the Local Positioning System (LPS) is active and in range, a given node can know it's position relative to the world frame.

Battery Voltage Sensor

It has been discussed many times that the nodes should be self charging. Some sort of battery voltage detection must occur to know when it needs to charge itself. There are a few ICs out there that are made for smart battery charging and include an output for reading battery voltage. After we decided on some batteries we can choose a device better. We need to build something on the bench before we have a use for a mobile robot powered by batteries though.

Motor Current Detection

To protect motors we should monitor the current that is passing through the motors. The Mars Rocks Rover failed to to burned out motors. If we had a method to monitor the current we could detect stalling and protect the motors. This should probably be part of the motor control design.

Quadrature Encoders

For motor speed, direction and location. These are basic sensors for your consumption.


Motor Speed Controllers

Motor control will be a key foundation technology. Any task that a swarm might do will of course need some sort of motor to accomplish the task.

Potentially a simple H-bridge that is controlled with a PWM signal would be sufficient. That would require two digital pins be motor, one for direction, the other for speed. If we are short on pins, a discrete latch could be used for position and then a multiplexed output for selecting the motor we wish to control.


In effort to give nodes the ability to 'do something' servos may be required. They are controlled with a single pin usually. They have various methods of signal control but this can be left of future research. If we wish to control a servo, just leave a pin or two open.


Powering our nodes is something that we overlooked initially. Research is needed to make decisions on what types of batteries the nodes will use, as well as how we should charge those batteries. Pros and cons of each type of battery as well as an estimate cost would be awesome!

Battery Selection

Please fill in this section with pros, cons and costs.

Using AAA cells would give us 3.6v 1000mAH




Charging Circuitry

We discussed the ability for the nodes to be able to charge themselves when needed. In order for a large number of nodes to be able to charge their batteries without needing a large number of 'charging stations' they should probably be able to link together with a shared power line that allows nodes to chain together while charging.

It is also desired that the node would not need to shut down while charging. Depending on how the charging process works, this could mean that system power needs to be switched from battery to line and back during the charging process.

Different batteries require different charging applications, some are smart or require monitoring of some sort. The electronic components and reference schematics should be attached here.


The initial swarm will be build for indoors where florescent lighting is prevalent. While that makes solar panels not the best option for this swarm, it has been brought up in discussion numerous times and we should gain at least a theoretical knowledge of how it might work when incorporated with swarm robotics.


       ^-- look Ma! it's a FLUX capacitor

Omnidirectional locomotion was decided in effort to reduce complexity of each node by removing the need for a turret on each node. Omniwheels similar to those used by the 08-09 senior project team orientated at 120 degrees will be our initial configuration.

  2" TransWheel 2" Traswheel
Outside Diameter (in)
Inside Diameter (in)

The customer rep for OmniWheel.com said that it would be possible to have a custom bore size to match our motor shaft directly. We would need to call and set something up. I don't know if that would incur an additional cost, probably so.

To choose a gearbox and motor, a maximum speed and maximum weight that will need to be carried should be determined. This will allow us to select the best gearbox/motor combination for our needs. The nodes should be able to keep pace with a person walking at a normal pace which is about 1.5 m/s.

To calculate the required RPM to achieve a 1.5 m/s velocity is not straight forward, because the wheels are not pointing in the direction of motion. I estimate that we will lose 30% of our speed to the angle of rotation. This is true in the case of motion similar to the figure at the top of this section. The front wheel provides no motion, while the back two wheels rotate together at some velocity, fighting each other. The force is canceled between them and the remaining force propels the node.

1.5m/s * 1.3 = 1.95 m/s
2in = 5.08 cm
5.08*pi = 16 cm per rev
195cm/s / 16 cm/revolution = 12.2 revolutions per second
12.2 r/s * 60 s/min = 731 RPM

As we lack experience, it is difficult to estimate the necessary torque requirements.

Calculating the required torque to move the robot is non-trivial. We need to know the co-efficient of friction for the node on the floor. As this can not be calculated to any degree of accuracy, we will simply have to guess and check.

MS-16118-030 MS-25030-180  
FF-050 FF-180  
Operating v 4.5v - 8v 3v - 4.5v  
No Load RPM 127
No Load A 0.2A
Stall Current 1.9A 6.7A  
Stall Torque 110 oz-in
776 mN-m
92 oz-in
653 mN-m

The motors ordered from the MARS ROCKS competition MS-25030-180, we believe that the 118:1 16mm Spur Gearmotor, FF-050 will produce enough torque to move the nodes at an acceptable pace.  On the Mars Rocks project we attempted to maximize speed before we even had a moving robot. Even if these motors move too slow to be useful, we should at lease have some locomotion.


(2" Diameter wheel * pi * 127 RPM)/60 Seconds = 13 in/s, 0.3 m/s

The triangular drive system loses some of that speed as well as once the motor is loaded by the weight of the node, it will slow down further.

Unfortunately the MS-16118-030 is out of stock as far as I can find. The manufacture supplied me with some reseller contacts, but they were also out of stock. One option is to buy the MS-25030-030 and then a FF-050 motor separately and take and throw away the stock FF-030 motors.


Communication Network


May be useful (bleek)

RF communication using the same boards used by the train coupler senior project team.
2 digital IO ports on the micro are required.

Not sure how RF interference works, but I hope that it is similar to CAN networks where there is a recessive bit and a dominant bit. In the case of RF recessive bit would be no RF transmit, and a dominate bit would be RF transmit.

RF receiver must have 5v to operate.
RF transmitter can operate at lower voltage though, minimum of 3 volts.

Testing has shown us that we can communicate a signal about 80 feet away at a 3 volt signal.





Microcontroller Selection

There are many microcontrollers that were evaluated including ARM, PIC, BasicStamp, and the HC12. With cost being the primary motivation the PIC was selected for our initial round of development. There is also a wealth of documentation and experience within the university and the chips come in a PDIP package that is convenient for quick prototyping. The ARM looks very promising in the event that more processing power is required in later revisions.

Within the PIC world there are hundreds of types of chips with various features and computing power making the decision on what chip to use very difficult. The chip should fulfil at least the following criteria:

  • Digital
    • 1 Digital Output for RF
    • 1 Digital Input for RF
    • 3 PWM channels for drive motors
    • 3 Motor direction
    • 2 PWM channels for auxillary servos
    • 1 Sonar
    • 4 Theremin Vision proximity Sensor
  •  4 Analog Channel
    • (1) Yaw Rate Sensor
    • (3) accelerometer

The 18f46k20 was chosen by Brian as the microcontroller to use, it has more space for storage, a little bit more ram, two 16 bit timers, and one 8 bit timer.  Jake is currently researching some sample code and looking up how exactly to program the selected pic.  The 18f46k20 pic requires a 3.3v input to program, as opposed to most other pic families requiring a 5v input.  I honestly don't know how that's going to effect anything, as I have no experience programming pics.

Useful links for programming our particular pic:
The following link is a partial datasheet for our PIC series.
datasheet for the 18f46k20:

Pickit 2 Datasheet


Activity Log

Aug 24, 2009 - Dereck Wonnacott
Tags: Locomotion

The summer has been busier than ever before leading to lack of tangible progress. What has happened before this date is all a blur, but it seems reasonable to keep a log of activities and purchases as a way to track progress, credit, or lack thereof for the project.  This log should also include thoughts and comments from team members that would not seem fit for inclusion in the documentation itself. The audience of this section is primarily for team members. With that out of the way, let me begin.

Tonight I made two critical purchases backed by Jake and Skylar; the omni wheels, and the gearbox-motors. A few problems have popped up though in the ordering process.

(1) The MS-16118-030 Jake and I selected for the prototype is unavailable from a number of suppliers and the manufacture said they would not have any until December or January. I found that the same gearbox was used in combination with a lower torque motor and that they had surplus FF-050 motors for sale. This means we have to purchase two motors in order to get one usable combination, $3.20 additional to each gearbox purchased until the high torque version is available again.

(2) The motor will only produce a theoretical maximum velocity that is 15% of our target of a human walking pace. We also have no way to know the required torque needed to propel the nodes. Being burned badly by the Mars Rocks competition, we choose the most torque possible knowing we would lose speed. I hope that we can use the 38:1 gearbox in the next version in order to recover some speed.

(3) The output shaft of the gearbox is 3mm, with a flat. The idea is that we should use a 3mm hole in the wheel hub with a set-screw to hold the wheel to the axle. The omni-wheel is plastic and will not hold a set-screw well. The omni wheel also does not have a 'good' place to bore a hole to put a set-screw because of the rollers. The omni-wheels also don't have a 3mm ID hub available for mounting on the axle.

One idea for powering the wheels is to use a sleeve with a 3mm ID that has a set-screw for attaching to the axle. The omni-wheel will then be fixed to the sleeve with a key. The wheel and key will be held between a flange that is part of the sleeve and some clip or nut (magic) on the end of the sleeve.

Problems with this design include the fact that threading the end will add a length beyond the wheel that can be caught on obstacles.  A C-clip may let the key fall out of place.

Unorganized notes

Parts Queued For Purchase
1x sonar rx/tx

Ordered July 8, 2009 (Dereck)
4x Therein sensor:
what is required for one sensor is below:
  1x Cap 22pF 5% NPO Ceramic 0.1 inch     P4841-ND  (check)
  1x Cap 10uf 10V Tantalum 0.1 inch          P2026-ND  (check)
  2x Cap 10nF 10% XTR Ceramic 0.1 inch    P4922-ND  (check)
  2x Res 10K 5% 1/8 Watt                        10KEBK-ND  (check)
  1x Res 100K 10% 1/4 inch Trimmer         490-2372-ND (check)
  1x LMC555CN                                       LMC555CN-ND (check)

3x speed controller:
Brett - this is the h-bridge website http://www.mcmanis.com/chuck/robotics/tutorial/h-bridge/bjt-circuit.html (very useful info if anyone else is interested)

I tossed the code into mikroC on the laptop today and fixed all the compiler errors from the code
that I typed up into the gdoc without actually compiling, hopefully it all works now!
7/27/09 - JW

A brief note about the current code -- it seems like we can't have multiple independent PWM signals going on, this will make motor control a pain... we can manually set up a pwm signal using timer ports and whatnot though.
Current Code:

 * Project Name: Swarmbots                                                     *
 * Lead Programmer: Jake Weinmann                                              *
 * Configured for 18f46k20 PIC                                                 *
 * Datasheet available online @                                                *
 * http://ww1.microchip.com/downloads/en/DeviceDoc/41303E.pdf                  *

void intto10binary(int);
void duty_cycle(int);
int bintoint(int);
void strtohexbyte(char[]);
int bintohex (char[]);
void pwmconfig(void);
void pwmconfig2(void);

//for some reason this compiler won't let me declare variables in a for loop
//or anywhere besides globals, and main or something... screwy.

char bin_val [10];
int hexone = 0;
int hextwo = 0;
int i = 0;
int j = 0;
int newnum = 0;
int counter = 0;
int errorval = 0;
char secondpart[9];
char firstpart[9];

void main()
  ANSEL  = 0;                            // Configure AN pins as digital I/O
  ANSELH = 0;
  PORTA = 0;                             // initialize PORTA
  TRISA = 0;                             // configure PORTA as output

 * TRISA = 0xE7 // 11100111                                                    *
 * TRISB = 0xFF // 11111111                                                    *
 * TRISC = 0x09 // 00001001                                                    *
 * TRISD = 0xE0 // 11100000                                                    *
 *                                                                             *
 * The above allows for the following configuration of I/O ports, as necessary.*
 * Port A0, A1, A2 -- 3x inputs for theremin sensors                           *
 * Port A5, A6, A7 -- 3x inputs for accelerometer                              *
 * Port A3, B0, B1, B2, B3, B4, B5, B6, B7 -- 9x Inputs for IR sensors         *
 * Port C0 -- Input for Gyroscope                                              *
 * Port C1 -- Output for R/F communication                                     *
 * Port C2 -- RESERVED for 4th PWM usage, if needed (configured as output)     *
 * Port D5, D6, D7 -- 3x PWM outputs for motors                                *
 *                                                                             *
 * Ports not in use are as follows:                                            *
 * Port A -- 4,5                                                               *
 * Port B -- N/A                                                               *
 * Port C -- 4,5,6,7                                                           *
 * Port D -- 0,1,2,3,4                                                         *
 * This allows for up to 11 more I/O ports                                     *
 *that are unused with our current scope                                       *


//code for having LEDs count in binary, huzzah!
    if (PORTA > 0xFF)
     PORTA = 0x00;
  //Setup a way of making the pwm signal gradually increase.
  counter+= 10;
    if (errorval == 0)
      errorval = 0;
    if (counter > 0x3FF)
      counter = 0;


void intto10binary(int orig_num)
  if ((orig_num - 512) >= 0)
    orig_num -= 512;
    bin_val[0] = '1';
    bin_val[0] = '0';
  if ((orig_num - 256) >= 0)
    orig_num -= 256;
    bin_val[1] = '1';
    bin_val[1] = '0';
  if ((orig_num - 128) >= 0)
    (orig_num -= 128);
    bin_val[2] = '1';
    bin_val[2] = '0';
  if ((orig_num - 64) >= 0)
    (orig_num -= 64);
    bin_val[3] = '1';
    bin_val[3] = '0';
  if ((orig_num - 32) >= 0)
    (orig_num -= 32);
    bin_val[4] = '1';
    bin_val[4] = '0';
  if ((orig_num - 16) >= 0)
    (orig_num -= 16);
    bin_val[5] = '1';
    bin_val[5] = '0';
  if ((orig_num - 8) >= 0)
    (orig_num -= 8);
    bin_val[6] = '1';
    bin_val[6] = '0';
  if ((orig_num - 4) >= 0)
   (orig_num -= 4);
    bin_val[7] = '1';
    bin_val[7] = '0';
  if ((orig_num - 2) >= 0)
    (orig_num -= 2);
    bin_val[8] = '1';
    bin_val[8] = '0';
  if ((orig_num - 1) >= 0)
    (orig_num -= 1);
    bin_val[9] = '1';
    bin_val[9] = '0';
  if (orig_num > 0)
   errorval = 1;

void strtohexbyte(char cheese[])
  secondpart[0] = '0';
  secondpart[1] = '0';

  for (i = 0; i < 8; i++)
    firstpart[i] =cheese[i];
  secondpart[2] = cheese[8];
  secondpart[3] = cheese[9];
  secondpart[4] = '0';
  secondpart[5] = '0';
  secondpart[6] = '0';
  secondpart[7] = '0';
  secondpart[8] = '0';
  hexone = bintohex(firstpart);
  hextwo = bintohex(secondpart);

int bintohex (char binval[])
  newnum = 0;
  for (j = 0; j < 8; j++)
    if (binval[j] == '1')
      switch (j)
       case 0:
         newnum += 128;
       case 1:
         newnum += 64;
       case 2:
         newnum += 32;
       case 3:
         newnum += 16;
       case 4:
         newnum += 8;
       case 5:
         newnum += 4;
       case 6:
         newnum += 2;
       case 7:
         newnum += 1;
  return (newnum);

  //page 152 has a general pwm setup guide
void pwmconfig(void)
  //configuring a PWM output, huzzah!!!!

  RCON =     0x00;  //this has to do with interrupts

  PIE1 =     0x00;  //more interrupts /configured
  IPR1 =     0x00;  //sets interrupt priority /configured
  TRISD =    0xE0;  //sets port D for input/output configured for pwm outs binary val 11100000
  TRISC =    0x04;  //sets port C for input/output configured for pwm outs binary val 00000100
                        //Page 5 shows the pinout for the PWM ports and whatnot

  PSTRCON =  0x1F; //page 187 // 00011111
  TMR2 =     0x00;
  PR2 =      0xFF;  //configure for slowest binary val: 11111111
  CCPR1L =   0x80;  //page 171   //configured correctly binary val: 10000000
  CCPR1H =   0x00;
  CCP1CON =  0x0C;  //page 171   //configured correctly binary val: 00001100
  PIR1 =     0x00;  //check for interrupts
  //CCPR2L =   0x00;
  //CCPR2H =   0x00;
  //CCP2CON =  0x00;  //page
  ECCP1AS =   0x00;  //page
  PWM1CON =  0x00;  //page  186
  T2CON =    0x7D;  //page 165  //currently configured for slowest speed binary val: 01111101
  while (PIR1 == 0x00);  //wait for timer 2 to overflow, sets bit TMR2IF in PIR1 register
/*************************The above line could be an infloop*******************/
  TRISD = 0x00;
  TRISC = 0x00;

//  also turns on timer 2

//  RCON      IPEN     SBOREN    —      RI     TO    PD     POR    BOR
//  TRISB     PORTB Data Direction Control Register
//  TRISC     PORTC Data Direction Control Register
//  TMR2      Timer2 Register
//  PR2       Timer2 Period Register
//  CCPR1L Capture/Compare/PWM Register 1, Low Byte 59
//  CCPR1H Capture/Compare/PWM Register 1, High Byte 59
//  CCP1CON  P1M1 P1M0 DC1B1 DC1B0 CCP1M3 CCP1M2 CCP1M1 CCP1M0 59
//  CCPR2L Capture/Compare/PWM Register 2, Low Byte 59
//  CCPR2H Capture/Compare/PWM Register 2, High Byte 59
//  CCP2CON  —         —       DC2B1    DC2B0 CCP2M3 CCP2M2 CCP2M1 CCP2M0
//  PWM1CON  PRSEN     PDC6      PDC5    PDC4    PDC3   PDC2   PDC    PDC0

void pwmconfig2(void)
  RCON =     0x00;  //this has to do with interrupts
  PIE1 =     0x00;  //more interrupts /configured
  IPR1 =     0x00;  //sets interrupt priority /configured
  TRISD =    0xE0;  //sets port D for input/output configured for pwm outs binary val 11100000
  TRISC =    0x04;  //sets port C for input/output configured for pwm outs binary val 00000100
                        //Page 5 shows the pinout for the PWM ports and whatnot
  PSTRCON =  0x1F; //page 187 // 00011111
  TMR2 =     0x00;
  PR2 =      0xFF;  //configure for slowest binary val: 11111111
  CCPR1L = hexone;  // the above is now configured for fastest speed
  CCPR1H =   0x00;
  //CCP1CON = CCP1CON && 0xCF;
  //CCP1CON = CCP1CON || hextwo;
  PIR1 =     0x00;  //check for interrupts
  //CCPR2L =   0x00;
  //CCPR2H =   0x00;
  //CCP2CON =  0x00;  //page
  ECCP1AS =   0x00;  //page
  PWM1CON =  0x00;  //page  186
  T2CON =    0x7D;  //page 165  //currently configured for slowest speed binary val: 01111101
  while (PIR1 == 0x00);  //wait for timer 2 to overflow, sets bit TMR2IF in PIR1 register
/*************************The above line could be an infloop*******************/
  TRISD = 0x00;
  TRISC = 0x00;

Registers necessary for setting up timer1


timer1 oscillater enable bit (T10SCEN)

If control bit T1SYNC of the T1CON register is set, the
external clock input is not synchronized. The timer
continues to increment asynchronous to the internal
phase clocks. The timer will continue to run during
Sleep and can generate an interrupt on overflow,
which will wake-up the processor.

Copyright © 2014 LSSU IEEE. All Rights Reserved.
Joomla! is Free Software released under the GNU/GPL License.