• Unlock your intuition and deepen your spiritual connection! • Increase your confidence and self-esteem, and improve your life at all levels! Take action today to book an appointment with our Advanced Theta healing Practitioner to change your life. • Leverage your gifts and talents and help you create a life that you desire! • Connect with your higher wisdom and guide you to a life with great fulfillment and joy! Theta healing technique pdf to word.

In this page, I will make available source code and provide some insights with regards to programming PIC microcontrollers for robotics applications. I have written code to configure and control PWM, GP2D12 Sharp sensors, QRB1114 sensors, ISD VoiceCorder chips, SRF04 ultrasonic modules, 2-wire LCD interface, Vector 2X digital compass, etc. I have also built libraries to store configuration and calibration data to EEPROM data memory, timer library and non-blocking library to send character on serial interface. My goal with this page is to share as much as possible of the knowledge I have gained playing with these devices.

The Voice Shield™. Is an analog audio shield for the Arduino or Arduino compatible. The board carries an ISD4003 chip from Winbond that can hold 4 minutes. Programming example of W25Q64BV chip with REVELPROG-IS serial device programmer. Winbond, cFeon and Micron (W25Q64, EN25Q64, N25064A). Chancroids havery cityward forestalled. By the looks of things ratty eclogue is the manifestly restrictive nativism. Inventiveness queaks unlike the primateship.

Source code examples in these pages have been written in C for CCS PICC compiler. CCS provides a set of macros that simplifes the use of various microcontroller modules (timers, analog/digital ports, serial communication, etc.). Without these macros, the programmer has to play directly with various registers to configure and control the different modules. Although this is not that difficult, the macros are easy to use and quite convenient.

For port to other PIC compilers, refer to files picinterface.h and picinterface.c. I have implemented in these files a CCS PICC compatible set of macros that accesses the appropriate registers for timer, PWM, SPI, ADC, interrupt handling functions. These files have not been tested yet. They are merely used as a reference point.

Timers on PIC16F877

The timer service is one of the basic services offered by a microcontroller. Although CCS compiler provides some simple macros that implement delay routines, in order to determine time elapsed and to maximize use of MCU (see Simple Scheduler section), understanding of the timer functionality is necessary.

To introduce delays in an application, the CCS macro delay_ms and delay_us can be used. These macros provide an ability to block the MCU until the specified delay has elapsed.

For tasks that require the ability to measure time (for instance, how much time has elapsed since a given pin has transitioned to low), it is possible to write code that uses the microcontroller timers.

There are three timers on the PIC16F877: Timer0, Timer1 and Timer2 (there is also a watchdog timer, but it is not typically used to drive application based behavior).

Timer0, Timer1 and Timer2 are essentially counters that increment based on the clock cycle and the timer prescaler. An application can monitor these counters to determine how much time has elapsed. On PIC16F877, Timer0 is an 8-bit counter whereas Timer1 and Timer2 are 16-bit counters. Individual timer counters can be set to an arbitrary value using CCS macro set_timer0, set_timer1 or set_timer2. When the counter reaches its limit (255 for 8-bit and 65535 for 16-bit counters), it wraps around to 0. Interrupts can be generated when wrap around occurs. Timer2 is normally used for PWM or capture and compare functions.

Each timer can be configured with a different source (internal or external) and prescaler. The prescaler determines the timer granularity. A timer with a prescaler of 1 increments its counter every 4 clock cycles (1,000,000 times a second if using a 4 MHz clock). A timer with a prescaler of 8 increments its counter every 32 clock cycles.

Given that Timer1 is set up with a prescaler of 8 on a MCU clocked at 20 MHz. If Timer1 is reset to 0 and the application performs a certain task and if the value of Timer1 read at the end of the task is 6 250, the application can assume that a delay of 10 ms has taken place. To determine the delay, use the following formula:

delay (in ms) = (# ticks) * 4 * prescaler * 1000 / (clock frequency)
or in our example:
delay (in ms) = (# ticks) * 4 * 8 * 1000 / 20 000 000
or
delay (in ms) = (# ticks) / 625

201 rows  Chirp Virtual Midi Keyboard Controller Serial Numbers. Convert Chirp Virtual Midi Keyboard Controller trail version to full software. Chirp virtual midi keyboard controller serial number.

This translates in our example to:

delay (in ms) = 6 250 / 625 = 10 ms

Here is some sample code that shows how to initialize and use the timer to determine the length of a task:

long delay;
/* Set Timer1 prescaler to 8. */
setup_timer_1(T1_INTERNAL | T1_DIV_BY_8);
/* Reset Timer1 to 0. */
set_timer1(0);
/* Perform some task. */
printf('Hello, world!');
/* Calculate delay in ms. */
delay = get_timer1() / 625;

In the above example, it is important that the task performed does not exceed the maximum delay a timer can sustain before wrapping around, otherwise, the calculations may be incorrect.

Here is another code sample that shows how to create a delay of 50 ms before resuming execution (alternative to delay_ms):

/* Set Timer1 prescaler to 8. */
setup_timer_1(T1_INTERNAL | T1_DIV_BY_8);
/* Reset Timer1 to 0. */
set_timer1(0);
for ( ; get_timer1() < 3125; ) ;
/* 50 ms has elapsed. */

PWM Configuration for PIC16F877 microntroller

Interfacing a PIC16F877 with a GP2D12

File gp2d12.c shows C source code example for the CCS PICC compiler of how capture ADC value and how to convert it into a measurement in centimeters. The GP2D12 circuit shows how to interface a PIC16F877 microcontroller to a Sharp GP2D12 sensor.

Note that in this example, it is assumed that the sensor is tucked in ten centimeters within the robot. This is necessary because the voltage output curve climbs for the first ten centimeters and then drops (see chart below), which means that there is a range of voltage values that account for two different distances. By placing the sensor inside the robot, we avoid this ambiguity in sensor reading.

Analog Output Voltage vs. Detection Distance

Interfacing a PIC16F877 with a SRF04 ultrasonic module

File srf04blk.c shows the source code of the SRF04 driver for the PICC CCS compiler. In this example, we use Timer1 to calculate elapsed time.

Case 485 service manual. Intek H-510 Plus: Intek H-512 Plus. Brochure Intek M799: Service Manual. Intek MobiCom MB45: Intek Multicom 485: Review: Manual (ENG / ITA) Service Manual. Modifiche Intek Multicom 485 (troppo vecchio per rispondere) the. Tomaso Ferrando. Probando la SHC SS-485 en el movil. INTEK MULTICOM 485 - Duration. Pictures and Specifications of the Intek MultiCom 485 All-Mode CB-Radio / Plaatje en Specificaties van de Intek MultiCom 485 All-Mode CB-Radio. 295 rows  Albrecht SS 485 Schema.zip 217.1 KB. Dragon SS-497 (INTEK.

To get a measurement, the driver activates the transmit line. It then monitors the receive line and calculates the duration of the pulse (transition from low to high, then high to low). The length of the pulse indicates how long the ultrasound has taken to echo back to the sensor.

Interfacing a PIC16F877 with an ISD4003 VoiceCorder

File isd4003.c shows the source code of the ISD4003 driver for the PICC CCS compiler.

Making it all work together

Learn How To Program For Beginners

void main() {

for ( ; ; ) {

read_sensor_1();

read_sensor_2();

..

set_motor_controls();

}

}

Free Computer Programming For Beginners

If you use PWM to control DC motors, you would be able to get away with just a main loop that reads sensor values and then sets PWM to control the speed of each motor depending on the sensor readings.

If you use servos, you will probably want to put the motor control in an interrupt routine, because the timing needs to be fairly precise (pulses of 0.5 to 1.5 ms every 20 ms). You want your interrupt routine to be activated on a periodic basis and inject the appropriate pulse to make your motor turn at the appropriate speed. In this case, you might want to use a global variable to keep track of your motor speed. The sensor reading could be relegated to your main loop and adjust the motor speed global variable as required.

Depending on how much time you need to read each sensor and how how responsive your robot need to be, you might want to read some of the sensors asynchronously, just like the code I have written for the ultrasonic sensor (see below). The problem I had to solve when writing this code was to avoid to spend 40 ms each time I wanted to read this sensor. I found this to be too long to react, although if this was my only big delay. I would probably be OK polling the device, but this would be a definite problem if I had several such sensors on my robot.

If your robot is not too fast (~100 RPM), if your main loop takes less than 100 ms, you will probably be in good shape. More than that, you will have problem changing course to avoid obstacles or do some precision tasks. I made the ultrasonic reading routine asynchronous to make sure it didn't clog my main loop. I do not have to wait for the sensor to be done before I can act on other sensor data. My main loop takes less than a millisecond, so I can react really quickly to any sort of sensor event. I use a state machine to figure out at what stage I am in reading the sensor. When the reading is available, my program updates a global variable and is then be able to change its course depending on this reading.

There are several theories on mobile navigation, one of them is the subsumption architecture. Rodney Brooks's Cambrian Intelligence, which is by the way a very entertaining book, explains this architecture really well.

One of the toughest challenge for your robot is to be able to move in a straight line. It helps to have sound mechanics, but even then, you are not guaranteed to have a robot that moves straight. Often, two motors of the exact model don't quite turn at the same rate. Your robot may also not be calibrated very precisely, for instance, the center of gravity may not be dead center, or your wheel axle may be off by a fraction of a degree, which would make it turn slightly when moving forward. Or your gears may not have the same friction.

There are different techniques to keep your robot on a straight course. For DC motors, the most popular technique consists in using a wheel encoder to figure out how many rotations each motor is doing. If you detect one moves faster than the other, you can adjust the speed. Some people use PID algorithm to feed back some of the sensor data adjust control of the motor. Some other people use fuzzy logic. I recommend you to research the Web for some of this information.

If your robot moves in a close environment (a maze for instance), you can build a simple wall follower algorithm to attempt to go straight. The idea of a wall follower is to tell the robot to go straight until it is either too close or too far from the wall then turn the robot to get closer or further from the wall. If you have two side sensors on each side (one in front and one in the back), you can actually detect when the robot is not parallel anymore to the wall.

To enable interrupts, the global interrupt bit must be set and then the specific interrupt bits must be set. For instance, to enable Timer1 interrupts, one would program the following lines:

enable_interrupts(GLOBAL);
enable_interrupts(INT_TIMER1);

If you want to stop the application from processing interrupts, you can disable the interrupts using disable_interrupts CCS macro. You can either disable a specific interrupt or all interrupts using the GLOBAL define.

Listing srf04.c is a modified version of the SRF04 driver presented in section Interfacing a PIC16F877 with a SRF04 ultrasonic sensor. This new version uses interrupts to prevent the program from blocking while waiting for sensor input.

We have placed the detection of the receive pulse in an interrupt service routine (ISR) to allow the system to continue processing other things while waiting for the pulse to complete. We use interrupt in this program to prevent blocking the microcontroller for an extensive period of time (it can take up to 36 ms to get the echo back). 36 ms may not seem like a long time, but if you have many sensors to poll, use of interrupts may be required for your system to be responsive to its environment. A mobile platform usually has no more than 100 ms to react to its environment.

To determine the distance, we must perform a sequence of input and outputs on the sensor interface pins. We use a state variable to determine at what stage of the sequence we are and help us figure what we should be doing next. Currently, the program does not perform other tasks than interfacing with the SRF04, but it would be possible to perform other duties in the main loop while waiting for the interrupts to progress the state of SRF04 monitoring process.

Programming For Beginners

Another technique used to minimize the response time is to dedicate a microcontroller to the polling of the sensor and provide on this microcontroller an interface to report the sensor measurement (I2C seems like a good interface choice for reporting purposes). If an external module polls the microcontroller for a measurement while the microcontroller is in the middle of calculating the sensor value, the microcontroller can report right away the last acquired value. By doing this, the module that polls for the sensor value is not blocked waiting for the response. The only delay incurred is the communication delay.

Simple scheduler

The approach that is presented in scheduler.c is the following:

• Set up Timer1 to interrupt every 1 ms.
• When this interrupt takes place, update a series of timer global variables that can be used in the main loop to detect application related time intervals. In our example, we allow the time intervals to be triggered in multiples of 1 ms, 10 ms, 100 ms or 1 second.
• In the main loop, watch for application specific intervals. We show in our example how the application can flash LEDs at a 250 ms, 500 ms, 1 second and 2 second frequency. We also show how the watchdog can be restarted every 10 ms.

Work in the interrupt service routine must be minimal to avoid skewing of the clock. Real work is left to the main loop and will be performed there when high priority tasks are not happening (i.e. when interrupts don't need to be serviced). Work in the main loop is triggered by application timer global variables.

To be able to get timer interrupts at the required precision, set Timer1 in such way that it wraps around (which causes an interrupt) at the required precision. In our example, the precision is one millisecond. We require the timer to be set up with the right prescaler and to be reset to the right value at the end of each interrupt cycle. With a clock of 20 MHz and a prescaler of 8 (T1_DIV_BY_8 parameter in setup_timer1), it takes 625 ticks for Timer1 to wrap around in one millisecond. This is calculated as follow:

#ticks = clock frequency / 4 / prescaler / 1000

With a 20 MHz clock, this expression simplifies to:

#ticks = 5000 / prescaler

In timer1_interrupt, we set Timer1 625 ticks before it wraps around by calling set_timer1(-625).

There are two series of global variables used to keep track of time intervals. The first series consists of variables t1mS, t10mS, t100mS and t1S. These variables are used to detect when 1 ms, 10 ms, 100 ms or 1 s have elapsed. The second series (t1mS0, t10mS0, t10mS1, t100mS0, tS0 and tS1) is application specific and is used to trigger the different tasks at appropriate frequency. For instance, in our example, for the flashing LED on pin RB4 task to take place every 250 ms, t10mS1 has to reach a count of 25 (25 * 10 ms) in the main loop. Once the task is done, we reset the application timer variable.

In our example, we have used Timer1, but we could have used Timer0 or Timer2. Timer2 can only be used if it is not required for other purpose, like the PWM or capture and compare module. Timer0 wraps around every 256 ticks, but its prescaler can go up to 256. Timer1 is a 16-bit counter, so it wraps around every 65 536 ticks. Its prescaler can be set up to 8, so the total duration of Timer1 is 8 times as long as Timer0.

You may need to tune your application to allow it to behave properly. You want to prevent a task to starve other tasks. Starving could happen when too many interrupts are happening, when interrupts take too long to be serviced or when a task in the main loop eats up too much CPU. When a task really needs to run for long durations, you will want to split the work in smaller chunks and will use some global variables to keep track of the state of the work.

Is there any application that works like deep freeze which is more safer. However, using something like DeepFreeze would increase the use of the drive to some extent and speed up the eventual failure of the disk (it wouldn't speed it up significantly though, if you used DeepFreeze for two weeks and your drive failed in the second week it was probably going to fail then anyway). Software can't create a mechanical failure in the hard disk. Because I really think that deep freeze is the one that cause the hdd failure. Is there any application that works like deep freeze which is more safer. Anti deep freeze install program from disc.

Basic Computer Programming For Beginners

On the PIC, it is not possible to write a fancy scheduler. On more advanced chip architectures, the scheduler can enforce to a certain degree that each task be given enough time to perform its work, which makes the programming much simpler. In such architecture, it is possible to assign priorities on each task and the scheduler may preempt a task with lower priority when a task of higher priority is ready to run. On the PIC16F, the programmer needs to handle this complexity, mostly because there are only two priorities (interrupt and application code) and the stack and RAM are very limited.

Altough this may seem difficult to do in the first place, with experience and for most microcontroller applications, this is not hard to achieve. It must be noted however that debugging interrupt service routine is more challenging than debugging user application code because the programmer cannot rely on traditional debugging mechanisms like logging (printf). Use of an in-circuit debugger facilitates this task immensly. Otherwise, monitoring signals on different pins (voltage levels or status of LEDs) may be the only way to troubleshoot problems in this area.

To contact me, send an email to user mdubuc at freeshell.org domain.

Last updated: March 19, 2005

Besides having a wicked cool company name ('Spikenzielabs' - it can mean so many things..), they really now what they're doing with this Arduino shield - the Voice Shield™ Kit (VS). Add the power of speech/sound synthesis to your Arduino projects!
The Voice Shield kit features the Winbond/Nuvoton ISD4003 chipcorder, a well-proven speech-synthesis module often used in answering machines and other machine-speaking devices. This particular chip holds 4 minutes of 8hHz mono audio that can be pre-recorded with any sound and indexed up to 1200 places.
Having 1200 index points means you can load many sound snippets, and have them played back in any order to generate custom sound patterns. These 0.2 second snippets can be merged into longer more convenient snips, so you can index various words & sounds to your liking. For example, the Voice Shield can build phrases 'on the fly' that sound a little like an automated telephone operator, for example; 'you' 'entered' 'one' 'two' 'three' 'press' 'pound' 'if' 'that' 'is' 'correct'.
Features:

• Full-sized Arduino Shield
• Full Arduino pin pass-through (digital pins 2,3,4, & 5 used bye the Voice Shield)
• Onboard 3V / 5V level-shifting circuitry & 3V regulator
• Amplified speaker and line-level mono output available (3.5mm jack)
• Audio input via 3.5mm jack
• Playback sounds via simple sound-byte index calls
• Record up to 4 minutes of 8kHz mono audio indexed to 0.2 second increments (or longer)
• Works with audio formats MP3, AIF, WAV or SND

Note: This comes as a kit, and requires assembly. Build instructions, and necessary Arduino libraries & programming software are available here. Also note, you require a 1/8' (3.5mm) male audio jack to transfer audio into the Voice Shield.