Gráfica 99. Que Éxitos Ha Logrado En Su Vida
8.1.12 Patrón rol relaciones
small enough to fit into the application code area taking into account the amount of size used by the boot loader.
BOOT LOADER
The boot loader is special software that allows the micro-controller to reprogram itself. You may see advertisements for Atmel® devices where it states that it has the Arduino® boot loader programmed in. This boot loader is what allows the Arduino® to be programmed from the IDE. While I wont go to deep into the details of everything that the boot loader does, the primary purpose is to check if a reprogram cycle is being requested and if not then to launch the application code that has been stored in the application section of the flash memory. Because the boot loader and
application code share the same flash memory, keeping the size of the boot loader to a minimum is usually considered best practice. For your own projects, this may not be a requirement depending on the size of your application software. For more details of what goes into a boot loader for an Atmel® type micro-controller, take a look at the following .
APPLICATION CODE
The application code area is where all of the end user's application code is stored. It can be reprogrammed by the user via the IDE or other means such as from the command line using a program like avrdude[ ]. This memory is persistent in nature where it will retain the programming for a number of years well beyond the typical life span of the product. The application code is called by the boot loader once the boot loader determines that the user does not want to reprogram the device.
Design Note (32)
For our applications, this would be the setup and loop methods we created along with any additional libraries we may have used and the base Arduino® code.
SRAM
The static random access memory, SRAM, is where all of the application data is stored during the execution of your application. Unlike the flash memory, it can be written to fairly fast and the device doesn't need to be configured in any specific way to do this. The down side of SRAM is that if power is lost, the memory contents are lost unless there is a battery installed in the system to preserve it. This makes it good for run time data however not so good for long term storage. Another thing to note regarding SRAM, and RAM in general, is that it will typically power on with arbitrary values contained within it. This is why it is always good idea to initialize your variables when they are first declared to ensure the value stored there is something reasonable given its purpose. While this
memory is called static it is not persistent. The name static indicates that the memory does not have to be refreshed periodically to retain its data. The complimentary memory to static is dynamic
memory. Dynamic memory requires that a memory controller refresh the data periodically in order to maintain its state. I won't get too deep into the details however it should be noted that dynamic
memory, DRAM, circuits are smaller then their SRAM counterparts resulting in higher densities and thus cheaper memory. Typically you will find DRAM in computer systems as the main memory or used in conjunction with video cards or other peripherals.
The other downside to SRAM for the Atmel® micro-controllers is that is very limited in size. When developing your applications i.e. sketches, you will want to ensure that you keep your memory usage fairly conservative. In the chapter, , I created a library for an LCD which uses 1024 bytes of SRAM to store the current screen image. For the Arduino® UNO, this was half of all the memory my board had!
EEPROM
Electrically erasable programmable read only memory or EEPROM is a good compromise between flash memory and SRAM. Like flash memory, it is persistent and can be written to although is fairly slow. Unlike flash memory, the EEPROM cannot store program code as the micro-controller cannot directly execute code stored in EEPROM. You could load it from EEPROM and place it into
SRAM however that is a bit beyond what I want to cover at this time. Like SRAM, it doesn't require
any special configuration and can be directly written to by the application code. This makes the name somewhat a misnomer in that it isn't quite read only any longer however in general usage, it will be written to in order store configuration or other persistent data that is read more often then written to. Typically I would use EEPROM memory area for storing items such as a serial number, board
configuration, or other somewhat static data. The Arduino® UNO™ micro-controller has 1K (1024 bytes) of EEPROM memory available to it. Given the various temperature circuits we have looked at, we could use this memory to store the high and low temperature for each day throughout a given year. Over time we could see the range of temperatures and could offload the data to a computer for further processing.
As seen in previous chapters, the Arduino™ has a rich set of libraries to work with various aspects of the micro-controller. For the EEPROM, the following library is included:
#include <EEPROM.h>
which allows us to simply write and read to and from the EEPROM like most any other memory using a couple of provided commands.
byte dataValue = EEPROM.read(offset); EEPROM.write(offset, dataValue);
The only downside with the EEPROM library is that you must manage the offset into the
storage area yourself. This however isn't a major concern given the amount used is typically low and helper functions can be written as I have done in the chapter on .
I/O Memory
This is memory or memory like data located external to the micro-controller and is accessed by mapping it through the I/O registers. This could be done for a number of devices such as an LCD panel or other device that has a data bus. Because we are using an Arduino®, I am not going to delve into this particular area other than to say it can be used with the Arduino® however the number of I/O pins required to operate it quickly grows limiting your options.
External Memory
In addition to the memory that is internal to the micro-controller, additional memory can be utilized by the Arduino® using various communication interfaces such as SPI, I2C, etc. One example of this is the SD micro-card that can be accessed depending on what shield is being used in
conjunction with the Arduino®. Previously we have utilized an SPI based digital potentiometer
which also contained persistent memory. Another example would be a real time clock RTC where the system has an external battery and crystal to keep the time while the system is powered off.
Summary
In this chapter we have looked at the various types of storage available to the Arduino® and how they are typically used. In general, the FLASH, SRAM, and EEPROM are the main types of memory you will use most often. Of the three, EEPROM is the one that will most likely be used the least however it will be very convenient when you need to persist data between application runs. SRAM will be the one that you wish you had more of while the FLASH memory will probably be sufficient for your application needs.
When one just isn't enough
E
nsuring that you have identified all of the functions that you need up front is always a good idea when working with a micro-controller. Not having to go back and rework your complete design because you need another output line is best to say the least. Of course not having to buy morecomputing power than you need is always good too, especially if you plan on building a number of the same items. For the next project I have in mind, I want to add two, seven segment, displays to the pinewood derby car's my children are making. In order to do this, I will need two of the seven
segment displays representing each digit along with an Arduino® to drive them. Because weight and size is a concern, I want to utilize the smallest Arduino® that I can while still having enough I/O's to drive the displays. For good measure, I also want to add two headlights because I can. I think this will also look very cool so there you go. With all of that, I need 14 digital outputs to drive each of the segments of the displays along with two additional outputs for the headlights. So overall I needed 16 digital outputs to drive all of the lights I have in mind. I also would like to flash the lights on and off and perhaps do some sequencing through the displays in order to catch the eye of the onlookers.
Requirements
The first thing I need to do is ensure I capture all of my requirements so I know what I need up front. From there I can look at what pieces of hardware I will need. The following is my first pass at some requirements.
16 digital outputs
Interrupt to update the displays Input to trigger the head lights
Input to set the display value from 00 to 99
Expansion board to mount the seven segment displays and the headlights
As mentioned before, the digital I/O pins will drive the individual segments of the displays and will also be used to turn on and off the headlights. I am thinking perhaps I could use a photodetector to determine when the headlights should be turned on. In addition, having a way to set the displays to a value dynamically would be very beneficial as I can then use the same code regardless of which car is adorned with the electronics. I can also change the assigned number to whatever the race officials assign to each child's car. Given all of the pieces I will need to do this, I had better plan on having an expansion board to hold the additional components given a bread board will not fit on the derby car and would likely push me over the maximum weight limit.
Constraints
With all of the requirements captured, I now need to look at what constraints I have in order to meet all of my requirements but not exceed any of the constraints that I have.
Cost - I need to create 4 of these
Size - this needs to be mounted to a pine wood derby car which has a width of 1.75" and a length of 7.0"
Weight - a pinewood derby car is limited to 5 ounces
Reproducible - I need to make 4 of these and simplicity is always a good thing
So of the all of the constraints that I have, cost is the one that is the most flexible. The size and weight are hard and fast rules set by the derby regulations. While I could possibly do something with reproducibility in mind, I only need four (4) so in the long run that will not be as important to me.
Design
With my requirements and constraints detailed, I can now start looking at a design that will meet my needs. The first thing is to decide which Arduino® will meet my needs while not breaking the bank in terms of cost. The most common choices are as follows:
Board Digital I/O Interrupts Analog Inputs Length (In) Width (In) Cost *
NANO 14 2 8 1.7 0.7 $25.00
UNO 14 2 6 2.95 2.1 $30.00
MEGA 54 6 16 4.25 2.1 $60.00
* Cost is variable and will depend on when and where you purchase it. I am listing some average prices I have seen online however I expect that you can find better pricing if you shop around. There is also the Arduino® Pro Mini from Sparkfun Electronics however it requires an USB to FTDI cable negating some of the cost savings.
While the MEGA has more than enough digital I/O's, it also costs a significant amount more than the other options. In addition, it is also a good bit larger than the others with a dimension of 4.25" x 2.1". All things considered, the Arduino® NANO will be the best choice not only because it is the most inexpensive but also because it will fit nicely on the pinewood derby car. The biggest issue I am going to have is that it only has 14 digital I/O's and I need at least 16 not counting the interrupt and a sensor for the head lights. This was assuming I would use a simple on/off for each of the headlights. If I was to instead make that an analog input than I could turn the headlights on when a certain darkness was detected.
The best way I can see to handle the digital I/O issue is to add a couple of chips to expand my I/O pins. I can place these additional chips on the expansion board that will hold the 7 segment displays and the headlights which will be two LED's. The chips I have in mind are some that I have used in the past on other designs so I have good understanding of how they work and any limitations that they may have. The chip's that I have in mind are the SN74LS595[ ] shift register. The beauty of this device is that it takes a serial input and converts it to a parallel output. I can shift in a value to represent my 7 segment display and use this device to drive the actual segments of the display. At a minimum, I only need two digital I/O lines to operate this device and I end up with 8 output lines. Not a bad trade off to go from 2 digital I/O's to 8. Now granted, this is one way and I can only use it to expand my outputs however for my current project, this is perfect. For this particular device, it has two clock signals, one for the shift register and one for the storage register. The storage register is a buffer of sorts that allows you to build up the complete 8 bit data value before sending it to the output pins. The choice to make is whether you want to have a separate output for each of these clock lines which, if your output is better to turn on all at the same time, then the second clock line is what you need. I would like to be able to shift out the whole value at once to reduce flicker so I will utilize this additional clock line and use three digital I/O lines for each of my 7 segment displays. I am doing this so when I write a value to the SN74LS595, I will see a clean transition from one number to the next. I will also use two digital I/O's for my headlights so I can turn them on and off independently. So with this, I am now using 8 digital I/O's opposed to 16. Not a bad savings overall and I have enough digital I/O's on the Arduino® NANO to do this. Of course I need to factor in the cost and space of two
additional components however they will still be less than what an UNO or MEGA would cost. Now that I have my design started I can see that some of my requirements are going to be
impractical. In order to adjust the number for each car, I will either have to have a couple of switches which will increase the number of digital I/O's I need or I will need to use an analog input and
convert the analog value to a digital equivalent. As for the photodetector, I think I will just pass on this. While it would be cool to have the lights come on when needed and turn off when not needed, I am going for the flashy look where I want them flashing all the time. Later on if I change my mind, I can always update my sketch to use photodetectors connected to the analog input pins however the devices themselves would have to be mounted separately. Another thing I was thinking about had been utilizing an interrupt to trigger when the lights should change. I can still do this as it will be simple to be done in code without any additional hardware however it isn't really necessary. I can simply have a loop do this given the actual micro-controller will not be doing much else in terms of work. I will however tie the input buttons to the interrupt pins so I can increase the number as
required and reduce the potential of missing an input form the button. With the above design considerations my final requirements are as follows:
8 digital outputs 2 push buttons
Inputs to set the display value from 00 to 99
Expansion board to mount the seven segment displays and the headlights
Implementation
Now that I have my main board selected and I have determined what additional major
components I will need, I can start implementing my design. I have also refined my requirements to match my needs with the capabilities I have available or can easily obtain.
My first task is to design my expansion card and identify any possible issues that might come up due to that. I could look into the software I will need but given my hardware is currently just a good idea and not a concrete design, it would be a waste of time writing any software at this point.
HARDWARE
I know I will need two SN74LS595 devices to run each of the seven segment displays. I will also need a way to drive the LED's without overpowering the Arduino® output pins. The
SN74LS595's can handle 24 milliamps. While the Radio Shack™ 7 segment displays have limited
information posted regarding them, I found that they are similar or the same as the Everlight[ ] 7 segment display which indicates that each segment requires a maximum of 15 milliamps. In order to ensure I don't over power any of my devices, I will place pull-up resistors inline with the various LED lights. This will allow me to drive the LED's while not over powering my devices. Given the number of LED's I will look into resistor arrays to minimize the amount of space required on my final board.
The first thing I am going to do is create a simplified circuit on my breadboard in order to test out what I believe will work. Right now there has been a lot of theory however I need to verify the design before trying to move forward. In this prototype, I will connect up one of the SN74LS595, a resistor network, and a seven segment display to test out both the hardware and the software
interface.
PROTOTYPE
In my prototype I only wired up one of the SN74LS595 chips given they are both going to be
doing the same thing. I didn't hook up the headlights as of yet as they are fairly simple to wire i.e. a voltage supply, a resistor, and the LED. I connected the Arduino® to my laptop via USB however also used an external six (6) volt supply to drive the circuits on the breadboard. While none of the