This project was designed with Clang on OS X and the application was tested standalone in a terminal environment. The dev requirements for this project can be found in the CHALLENGE.MD file under the root of this project.
This project uses:
- C99 - 1999 C Standard
This project has been compiled and tested on:
- Mac OS X
- Compiler: Apple LLVM version 8.0.0 (clang-800.0.38)
- Requires: Xcode CLI toolset
- CentOS 7
- Compiler: GCC 4.8.5 20150623 (Red Hat 4.8.5-16)
- Requires: "Development Tools" and libnetd
usage: ./ring-pong [button state] [current voltage]
button state is either 1 or 0, current voltage is 0.0 - 5.0 volts
----
example usage: ./ring-pong 1 3.5After cloning the project, go into the base directory and create two subdirectories.
cd ./RingPong
mkdir bin obj
Following this, a simple make call should compile and drop the binary into the ./RingPong/bin folder
make #build the binary
make clean #remove the object files
make remove #remove the binary and object files The Makefile was originally hand-rolled from simple commands, but for better project management an open-source example was used that allowed for a refined directory structure.
The stdout is verbose in terms of logging the actions that happen; quickly the red LED flashing and the udp_server sending/receiving flood the terminal with output. The top few messages show the state of all the peripherals if they haven't been updating. Also note: for testing the TARGET_ADDR domain name macro found in udp_server.h was appended to localhost in the /etc/hosts file.
./ring-pong 1 3.5 #simulates button press, and 3.5V battery charge
./ring-pong 1 2.7 #simulates button press, and 2.7V battery charge./ring-pong 0 4.5 #simulates no button press, and 4.5V battery charge./ring-pong 0 1.3 #simulates no button press, and 1.3V battery charge File: hw_setup.c/.h
- Contains all hardware setup functionality for interfacing with the various peripherals and modifying their states
File: udp_server.c/.h
- Is the UDP server implementation; it uses a few global variables so that minimal state can be held while allowing control of sending and receiving to be handled outside the scope of the file directly. An educational reference for this development can be found at this Rutger's tutorial; the man pages for recvfrom and sendto were also used.
File: main.c
- Imploys the CLI interface and main handling of the system logic. If it were implemented on a real embedded system, a loop that waits for a system signal would need to be employed around the main logic (the location of which is marked in main.c). As such, testing is limited to the states that one can change through the CLI and dynamic change in system state is currently not possible.
The determined resolution (as it was not explicitly stated) for the ADC was 12-bit or ( 212 - 1 ). Using calculations found at sparkfun.com for ADC measurments with millivolt system voltage reference (assumed to be 3.5V as that's when board functionality cuts off) made the equation come out to
(4095/3500 mV) * V * 1000 = Current Voltage Level
Where V is the voltage read in from the ADC and in the program from the second command line parameter.
The embedded system has a red LED which must work at 2Hz and 25% duty cycle. With the average LED pulse width and the total signal period both at 1 second, a 25% duty cycle would end up being 1/4 the pulse width over a 1 second period. So in 1 second @ 2Hz the LED would be sent to a high state for two quarter pulse width periods. These are the sources for duty cycle and Hertz research.