Programming

= = //Programming// //Welcome to PROGRAMMING Group.// = =

Guys, here is a start to our part for the final essay. please look at the stuff and change what needs to be changed. (4/27/11) (4/29/11) (4/29/11) updated!!!!!!!!!!!!!!!!! ya yo

=Assignment #5=

Design Work Done to Date
Thus far we have completed:
 * Coding for Arduino
 * Coding for Dallas Temperature
 * Coding for Force Resistive Sensors


 * 1) Collects individual temperatures for each sensor and displays them on the output. Our main temperature is then going to be sent to the mosfet control to determine the rate for the mosfet to work at.

OneWire myWire(10); change 10 to whatever you choose to use as the readout pin here! //connecting the Vdd pin on DS18B20 sensors means the sensor does not have to build up charge between readings in its internal capacitor. this might enable the use of a delay smaller than the accepted minimum (750ms)

int numSensor = 2; numbers of sensors used

int mosControl = 12; control pin for first mosfet int mosControl2 = 11; control pin for second mosfet

int highB, lowB, TReading, signBit, Tc_100; don't touch float whole, fract; as above

byte present; needed

int pulseVar = 0;

setting up void setup { pinMode(mosControl, OUTPUT); pinMode(mosControl2, OUTPUT); Serial.begin(9600); }

The main body


 * 1) The main body collects and displays the data for each sensor and displays temperature for everyone.

void loop {

myWire.r//eset_search;// delay(250);

for (int counter = 1; counter <= numSensor; counter++) {

byte data[12] = {0,0,0,0,0,0,0,0,0,0,0,0}; byte addr[8] = {0,0,0,0,0,0,0,0}; present = 0;

myWire.search(addr);

myWire.reset; myWire.select(addr); myWire.write(0x44,1); delay(750); present = myWire.reset;

myWire.select(addr); myWire.write(0xBE);

for (int i = 0; i < 9; i++) data[i] = myWire.read;

switch (counter) { case 1: temp1 = getDaTemp(data); Serial.print("Temp1: "); Serial.println(temp1); break; //Serial.println("i'm in 1's counter for getting temp");// //case 2:// //temp2 = getDaTemp(data);// //Serial.print("Temp2: ");// //Serial.println(temp2);// //break;// Serial.println("I'm in 2's counter for getting temp");

case 3: temp3 = getDaTemp(data); Serial.print("Temp3: "); Serial.println(temp3); break; //Serial.println("I'm in 3's counter for getting temp");// //case 4:// //temp4 = getDaTemp(data);// //Serial.print("Temp4: ");// //Serial.println(temp4);// //break;// Serial.println("I'm in 4's counter for getting temp"); case 5: temp5 = getDaTemp(data); Serial.print("Temp5: "); Serial.println(temp5); break; //Serial.println("I'm in 5's counter for getting temp");//

//}//

//}//

This part controls how fast the mosfet is going on and off while running at full blast (not running at full blast the whole time).
 * Coding for mosfet

pulseVar = ((temp1 - 3)*(36.57)); analogWrite(mosControl, pulseVar); analogWrite(mosControl2, pulseVar);

//}//


 * This is the function to get temperature.

float getDaTemp(byte sentData[12]) {

lowB = sentData[0]; highB = sentData[1]; TReading = (highB << 8) + lowB; signBit = TReading & 0x8000; test most sig bit if (signBit) negative { TReading = (TReading ^ 0xffff) + 1; 2's comp } Tc_100 = (6 * TReading) + TReading / 4; multiply by (100 * 0.0625) or 6.25

whole = Tc_100 / 100.0; separate off the whole and fractional portions

return (whole); }

The code controls the following functions and have been successfully completed:
 * Reads temperature of multiple temperature sensors
 * Uses this temperature to control Thermo-Electric Coolers
 * Controlling the fans - runs parallel to TEC
 * Comments in code show specific functions for future customization

All of our code has been posted (scroll all the way down) as well as every update of the code and what we changed. Comments have been added throughout the entire code so it is more user friendly and easy to follow.



Work Left to Complete
=**Members**=
 * Test code for variable Mosfet control based on temperature sensor input within the established parameters...

Writers: - James Hall - Brenden Demanche - Michael Vopelak - Ferdinand Aliaj - Joel Daniel

Researched by: - Brent Higgins

= = =**Assignment #2**= =**Project Description**=

In a nutshell we're pretty much the brains of the operation. Without us, the project would be a brick and serve no function or purpose. Everything is controlled by the code down to every detail and the controller itself. @http://arduino.cc/en/uploads/Main/LilyPad_3.jpg = =

=**Specific Problems**=

-Monitoring specific sensors (inputs and outputs) -Apart from acquiring code for all of the above sensors, our biggest task includes making them work together in harmony and function the way we want as well as cleaning up existing code to expel repetition and make it look nicer/work smoother. -Implementing a systematic way of measuring something unmeasurable (core body temperature). This will be done by communicating information with the research group. ( http://www.instructables.com/image/F4LWIIVG0KQKXPP/Program-with-arduino-IDE.jpg ) (This is not our code) = = =**Communication with Other Groups**=
 * Temperature
 * Pressure (Force)
 * TECs (controlled by the mosfets)

We need the hardware from each group and the specs on how they want that hardware to function (for example, the TEC group needs to give us specs on how they want the TEC to function specifically). We give them back functioning code that serves its purpose along with every other bit of code without any interference.

//Mike Vopelak -// Wireless communications/bluetooth feasibility study. //Is bluetooth or any other wireless communication between micro controllers a possibility for the 1st gen Autonomous Thermoregulation Device (ATD)? What kind of problems related to hardware add-ons and compatibility are we dealing with? What is the price of adding the functionality of bluetooth or some other form of wireless communication between devices?// //++++++++++++++++++++++++++++++++++//

//Here are a few websites that have some information on bluetooth. According to these sites, it seems that bluetooth connection on a micro controller is possible and fairly easy to do. I'm still confused about the costs though. The first site says that bluetooth chips cost about $4 to make, but on the second site, there are some starter kits that cost thousands of dollars. I'm not sure exactly what we need for this project, so I don't know what specifically to look for. Hope this helps.//

http://www.bluetomorrow.com/about-bluetooth-technology/general-bluetooth-information/bluetooth-costs.html

http://www.palowireless.com/database/docs/BT-devkits.pdf

We'll need more about bluetooth from you Mike, check Arduino.com and scroll down to the plug in bluetooth devices. Is the Lilly compatible with the bluetooth add on?

Arduino doesnt say anything specific about connecting a bluetooth to a lilypad, but it does seem that Arduino products can communicate with each other. I'm sorry for the lack of information. Research is not one of my strong points. The prices for bluetooth seem to range from $30 to $300. ---

//Brendan Demanche-// Wireless communications/bluetooth feasibility study. Wireless communications/bluetooth feasibility study. //Is bluetooth or any other wireless communication between micro controllers a possibility for the 1st gen Autonomous Thermoregulation Device (ATD)? What kind of problems related to programming complexity are we dealing with? >>> Download the Programming Process Tree and respond with comments on how you think this would be affected.// //+++++++++++++++++++++++++++++++//

Looks like if we are going to be using the arduino as our main board for the project, having bluetooth or wireless as an option is fairly simple. The Ardunio has the ability to support both wireless and bluetooth connection with the propper hardware. Hardwarewise we would be able to have this as part of the 1st gen Autonomous Thermoregulation Device. In terms of the programming side of using bluetooth and wireless, the complexiticy andwhich wireless stand we would like to use would depend on what we would want to utilize the bluetooth or wireless features for. For example we can use the bluetooth hardware and a PC to download and run the ardunio code without the need of wires. Although we can also use the bluetooth to send and recieve information with a mobile device IF we write a program for that particular device, ie and iPhone or Andriod phone. If we look at the wireless part of the hardware, this can be used on a greater scale to preform more tasks. Additionally if there were muliple ATDs in an area, the wireless would have the abilitiy to be connected to a main server and reley information to a certral system. Although this too would require some programing to accomplish. Additionally the wireless board would also give the microcontrollers the ability to "talk" with one another. Seeing that the arduino is one of the most used programmable microprocessing boards today, there are many people that have devolped code that could be used as a refference when we are programming ours. Additionally arduino has a software "templates" and some "how-tos" on there website for these different boards. It seems that for the 1st gen ATD we can look at using wireless as part for he project, just may be limited to using the PC as the rely device right now instead of an iOS (iPhone/iPad) or Andriod due to the programming.

//Links for information//

//Arduino Bluetooth - http://arduino.cc/en/Main/ArduinoBoardBluetooth// //- http://arduino.cc/en/Guide/ArduinoBT// //Arduino Wireless - http://arduino.cc/en/Main/ArduinoBoardFio//

//Arduino SoftwareSerial - http://www.arduino.cc/en/Reference/SoftwareSerial//

//Example of bluetooth connection and Ardunio - http://www.instructables.com/id/how-to-Control-arduino-by-bluetooth-from-PC-pock/step1/controlling-from-a-terminal-in-windows// /

//Sample Wireless Ardunio Project - http://www.sparkfun.com/tutorials/158//

//Ardunio hardware information - http://www.arduino.cc/playground/Main/InterfacingWithHardware//

// That's encouraging to hear. What we will do is look to budget for it accordingly, add bluetooth and wireless to one of the possible ATD component arrangements and if it turns out that we can get away with an arrangement with bluetooth or other wireless capability we will include it. So the component arrangements will be combinations of possible parts i.e. micro controllers sensors and tecs that could come together to form an ATD. From there we will be able to see how the power, battery, current and voltage will work out with the addition of a bluetooth or wireless communication module. Look out for my posting of these component arrangements I plan to put them up as soon as possible. // // --- //

//Ferdinand Aliaj- Develop a list of Ardunio micro controllers that are most suited for our application and tell us why you think they are best for this application. Include the specifications of each micro controller such as voltage, size dimensions of the controller, number of inputs, mass etc.// +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Ok, so here is probably the best option we have. ** The Arduino Lilypad: **

main: [] guide: [] tips: [|http://web.media.mit.edu/~leah/LilyPad/]

Main reason, this is attachable and designed to be attached to clothing.

Very easily programmable and we can sew this into our design. If anything, this will be our main used chip.

Some of the basic info of it:


 * Microcontroller || ATmega168V or ATmega328V  ||
 * Operating Voltage || 2.7-5.5 V ||
 * Input Voltage || 2.7-5.5 V ||
 * Digital I/O Pins || 14 (of which 6 provide PWM output) ||
 * Analog Input Pins || 6 ||
 * DC Current per I/O Pin || 40 mA ||
 * Flash Memory || 16 KB (of which 2 KB used by bootloader) ||
 * SRAM || 1 KB ||
 * EEPROM || 512 bytes ||
 * Clock Speed || 8 MHz ||

Should we wanna use an external power supply and i'm pretty sure we will....I see this as the info we need (from the main):

The LilyPad Arduino can be powered via the USB connection or with an external power supply. If an external power supply is used, it should provide between 2.7 and 5.5 volts. This can come either from an AC-to-DC adapter (wall-wart) or battery. Again, //don't power the LilyPad Arduino with more than 5.5 volts, or plug the power in backwards: you'll kill it.//

- The next chip is something for a wireless application. ** The Arduino Fio **

Main: []

When we need wireless information being sent out, this might be the tool we use.

**Summary **
Power The Arduino Fio can be powered with an FTDI cable or breakout board connected to its six pin headers (as marked on the bottom side), or with a regulated 3.3V supply on the 3V3 pin or a Lithium Polymer battery on the BAT pins. The power pins are as follows:
 * Microcontroller || ATmega328P  ||
 * Operating Voltage || 3.3V ||
 * Input Voltage || 3.35 -12 V ||
 * Input Voltage for Charge || 3.7 - 7 V ||
 * Digital I/O Pins || 14 (of which 6 provide PWM output) ||
 * Analog Input Pins || 8 ||
 * DC Current per I/O Pin || 40 mA ||
 * Flash Memory || 32 KB (of which 2 KB used by bootloader) ||
 * SRAM || 2 KB ||
 * EEPROM || 1 KB ||
 * Clock Speed || 8 MHz ||
 * **BAT.**For supplying a Lithium Polymer battery to the board.
 * **3V3.**The regulated 3.3 volt supply pins.
 * **GND.**Ground pins.

- Another wireless, offering bluetooth option is: ** The Arduino BT **

main: []

**Summary **

 * Microcontroller || ATmega168  ||
 * Operating Voltage || 5V ||
 * Input Voltage || 1.2-5.5 V ||
 * Digital I/O Pins || 14 (of which 6 provide PWM output) ||
 * Analog Input Pins || 6 ||
 * DC Current per I/O Pin || 40 mA ||
 * DC Current for 3.3V Pin || 50 mA ||
 * Flash Memory || 16 KB (of which 2 KB used by bootloader) ||
 * SRAM || 1 KB ||
 * EEPROM || 512 bytes ||
 * Clock Speed || 16 MHz ||

Of course as usual, here is the power information from the main:

**Power **
The Arduino BT can be powered via the V+ and GND screw terminals. The board contains a DC-DC convector that allows it to be powered with as little as 1.2V, but a maximum of 5.5V. **Higher voltages or reversed polarity in the power supply can damage or destroy the board.** The power pins are as follows:
 * **9V.** The input voltage to the Arduino board (i.e. the same as the V+ screw terminal). You can supply voltage through this pin, or, if supplying voltage via the screw terminals, access it through this pin. **Warning: despite the label, do not attach 9V to this pin. It will damage the board.**
 * **5V.** The regulated power supply used to power the microcontroller and other components on the board. This can come either from V+ via the on-board DC-DC convertor, or be supplied by a regulated 5V supply.
 * **GND.** Ground pins.

Of these our main idea should be to use the lilypad around the important parts of the suit and the Fio/Bt around dedicated parts where we would send wireless signals. Would we have 1 lily pad coupled with a fio/bt and have each set talk to each other? maybe, maybe not because it might be better to send all the data to a computer and have it determine what should happen.

// Ferdinand you bring up something important here, whatever components we decide to make this prototype out of - we will have to design by the limits and capabilities of our arrangements. For example if we use the Lilly, or any Arduino micro controller for that matter, we have a voltage limitation. If we were to use the Lilly we could only have TECs of less than 4 volts. This also means we can't plug more than one TEC on one controller. This is a concern of mine because a 4 volt TEC might or might not have the power we need to penetrate the skin significantly enough. If you or anyone else can aid me in coming up with component combinations and the corresponding pwer equations to prove the device will work we would be making a significant step. Also see the Xee-Bee radio controller that can be paired with the Lilly. // // - //

//Joel Daniel -// //What language does Ardunio use? Please post an instructional PDF of the language on wikipages.// //Google search examples of Ardunio code and give a general explanation about what the code is for and what it does. The more thorough the explanation the better. Look for codes involving any combination of variables such as time, temperature, pressure, voltage output vs time, voltage output vs temperature.// //+++++++++++++++++++++++++++++++++++++++++//

//According to their website (arduino.cc), the Arduino board is codded in a language that is a set of C/C++ functions. The only difference is some strange function prototypes however once it is completed it uses a C/C++ compiler (specifically avr-g++*). So basically, if the version of C/C++ you know is supported by avr-g++, it should work fine.//

*Info on avr-g++ can be found here. **Audrino discussion boards can be found here.

Specific changes and information were posted on their website and is worth a read:

**Overview**
A number of things have to happen for your Arduino code to get onto the Arduino board. First, the Arduino environment performs some small transformations to make sure that the code is correct C or C++ (two common programming languages). It then gets passed to a compiler (avr-gcc), which turns the human readable code into machine readable instructions (or object files). Then, your code gets combined with (linked against), the standard Arduino libraries that provide basic functions like digitalWrite or Serial.print. The result is a single Intel hex file, which contains the specific bytes that need to be written to the program memory of the chip on the Arduino board. This file is then uploaded to the board: transmitted over the USB or serial connection via the bootloader already on the chip or with external programming hardware.

**Multi-file sketches**
A sketch can contain multiple files (tabs). To manage them, click on the right-facing arrow just above the scroll bar near the top of the environment. Tabs have one of four extensions: no extension, .c, .cpp, or .h (if you provide any other extension, the period will be converted to an underscore). When your sketch is compiled, all tabs with no extension are concatenated together to form the "main sketch file". Tabs with .c or .cpp extensions are compiled separately. To use tabs with a .h extension, you need to #include it (using "double quotes" not ).

**Transformations to the main sketch file**
The Arduino environment performs a few transformations to your main sketch file (the concatenation of all the tabs in the sketch without extensions) before passing it to the avr-gcc compiler. First, #include " WProgram .h" is added to the top of your sketch. This header file (found in /hardware/cores//) includes all the defintions needed for the standard Arduino core. Next, the environment searches for function definitions within your main sketch file and creates declarations (prototypes) for them. These are inserted after any comments or pre-processor statements (#includes or #defines), but before any other statements (including type declarations). This means that if you want to use a custom type as a function argument, you should declare it within a separate header file. Also, this generation isn't perfect: it won't create prototypes for functions that have default argument values, or which are declared within a namespace or class. Finally, the contents of the current target's main.cxx file are appended to the bottom of your sketch.

**Targets**
The Arduino environment supports multiple target boards with different chips (currently, only AVRs ), CPU speeds, or bootloaders. These are defined in a board [|preferences file]. Relevant variables include: .name: the name to display in the Boards menu <BOARD>.build.mcu: the microcontroller on the board (normally "atmega8" or "atmega168"). <BOARD>.f_cpu: the clock speed at which the microcontroller operates (normally "16000000L", or, for an ATmega168 running on its internal clock, "8000000L"). <BOARD>.core: which sub-directory of the hardware/cores/ directory to link sketches against (normally "arduino"). Also useful is this setting in the main preferences.txt file: build.verbose: whether or not to print debugging messages while building a sketch (e.g. "false"). If true, will print the complete command line of each external command executed as part of the build process. //Note:// that in Arduino 0004 and later, build.extension is **unused** - the main sketch file is always treated as a .cpp file.

**Build process**
Sketches are compiled by avr-gcc. The include path includes the sketch's directory, the target directory (<ARDUINO>/hardware/core/<CORE>/) and the avr include directory (<ARDUINO>/hardware/tools/avr/avr/include/), as well as any library directories (in <ARDUINO>/hardware/libraries/) which contain a header file which is included by the main sketch file. When you verify a sketch, it is built in a temporary directory in the system temp directory (e.g. /tmp on the Mac). When you upload it, it is built in the applet/ subdirectory of the sketch's directory (which you can access with the "Show Sketch Folder" item in the "Sketch" menu). The .c and .cpp files of the target are compiled and output with .o extensions to this directory, as is the main sketch file and any other .c or .cpp files in the sketch and any .c or .cpp files in any libraries which are #included in the sketch. These .o files are then linked together into a static library and the main sketch file is linked against this library. Only the parts of the library needed for your sketch are included in the final .hex file, reducing the size of most sketches. The .hex file is the final output of the compilation which is then uploaded to the board. During a "Verify" the .hex file is written to /tmp (on Mac and Linux) or \Documents and Settings\<USER>\Local Settings\Temp (on Windows). During upload, it's written to the applet sub-directory of the sketch directory (which you can open with the "Show Sketch Folder" item in the Sketch menu).

**Upload process**
Sketches are uploaded by avrdude. The upload process is also controlled by variables in the boards and main preferences files. Those in the boards file include: <BOARD>.upload.protocol: the protocol that avrdude should use to talk to the board (typically "stk500"). <BOARD>.upload.speed: the speed (baud rate) avrdude should use when uploading sketches (typically "19200"). <BOARD>.upload.maximum_size: the maximum size for a sketch on the board (dependent on the chip and the size of the bootloader). And in the main preferences file: upload.verbose: whether or not to dump debugging messages while upload a sketch to a board (defaults to "false"). ---

//James Hall -// //Google search examples of Ardunio code and give a general explanation about what the code is for and what it does. The more thorough the explanation the better. Look for codes involving any combination of variables such as time, temperature, pressure, voltage output vs time, voltage output vs temperature.// //++++++++++++++++++++++++++++++++++++++//

//Arduino code is written in C. Here is a link to the reference for code straight from the arduino website- http://arduino.cc/en/Reference/HomePage//

Depending on the type of arduino board we use will change the output voltage and timing and everything else. After reading a bit the Uno board has six pulse wave output pins, we may be able to use this with proper timing to adjust the rate we cool down the TEC.

The IDE used specifically for arduino to code on your computer can be found at this link - http://arduino.cc/en/Main/Software