http://socialledge.com/sjsu/api.php?action=feedcontributions&feedformat=atom&user=SreeEmbedded Systems Learning Academy - User contributions [en]2026-05-09T21:45:10ZUser contributionsMediaWiki 1.27.1http://socialledge.com/sjsu/index.php?title=Embedded_System_Tutorial_FreeRTOS&diff=51341Embedded System Tutorial FreeRTOS2019-01-25T20:11:27Z<p>Sree: </p>
<hr />
<div>Socialledge is moving to two portals. <br />
* The Wiki will remain here for general references about the SJ-One board, and to document student reports.<br />
* The bookstack will now be used for SJSU assignments<br />
<br />
[http://books.socialledge.com/books/embedded-drivers-real-time-operating-systems/page/freertos-tasks This article has been moved here]<br />
<br />
<!--<br />
<br />
The objective of this assignment is to show you how to create a FreeRTOS task a few different ways. The [[FreeRTOS Tutorial]] is definitely a must read before going through this lesson.<br />
<br />
== FreeRTOS "Hello World" Task ==<br />
A task just needs memory for its stack and an infinite loop. To prevent "hogging" the CPU, you should use a delay such that the CPU can be allocated to other tasks. Here is the simplest FreeRTOS task:<br />
<br />
<syntaxhighlight lang="cpp"><br />
void hello_world_task(void* p)<br />
{<br />
while(1) {<br />
puts("Hello World!");<br />
vTaskDelay(1000);<br />
}<br />
}<br />
<br />
int main()<br />
{<br />
xTaskCreate(hello_world_task, (signed char*)"task_name", STACK_BYTES(2048), 0, 1, 0);<br />
vTaskStartScheduler();<br />
<br />
return -1;<br />
}<br />
</syntaxhighlight><br />
<br />
<BR/><br />
<br />
== C++ based FreeRTOS task ==<br />
As a project gets more complex, it becomes difficult to manage initialization and share queue or semaphore handles. This was the motivation to create a C++ based FreeRTOS task.<br />
<br />
=== Share "Objects" ===<br />
A task can "share" its pointers, handles, or "objects" with another task by name. This way, we don't have to worry about declaring handles into a common header file, hence we do not plague the global namespace :) See the next examples on how a task can share a handle with another task by an intuitive string name.<br />
<br />
=== C++ Task ===<br />
<syntaxhighlight lang="cpp"><br />
<br />
/// IDs used for getSharedObject() and addSharedObject()<br />
typedef enum {<br />
shared_SensorQueueId,<br />
} sharedHandleId_t;<br />
<br />
/// Orientation type enumeration<br />
typedef enum {<br />
invalid,<br />
left,<br />
right,<br />
} orientation_t;<br />
<br />
class orient_compute : public scheduler_task<br />
{<br />
public:<br />
orient_compute(uint8_t priority) : scheduler_task("compute", 2048, priority)<br />
{<br />
/* We save the queue handle by using addSharedObject() */<br />
QueueHandle_t my_queue = xQueueCreate(1, sizeof(orientation_t));<br />
addSharedObject(shared_SensorQueueId, my_queue);<br />
}<br />
<br />
bool run(void *p)<br />
{<br />
/* Compute orientation here, and send it to the queue once a second */<br />
orientation_t orientation = invalid;<br />
xQueueSend(getSharedObject(shared_SensorQueueId), &orientation, portMAX_DELAY);<br />
<br />
vTaskDelay(1000);<br />
return true;<br />
}<br />
};<br />
<br />
class orient_process : public scheduler_task<br />
{<br />
public:<br />
orient_process (uint8_t priority) : scheduler_task("process", 2048, priority)<br />
{<br />
/* Nothing to init */<br />
}<br />
<br />
bool run(void *p)<br />
{<br />
/* We first get the queue handle the other task added using addSharedObject() */<br />
orientation_t orientation = invalid;<br />
QueueHandle_t qid = getSharedObject(shared_SensorQueueId);<br />
<br />
/* Sleep the task forever until an item is available in the queue */<br />
if (xQueueReceive(qid, &orientation, portMAX_DELAY))<br />
{<br />
}<br />
<br />
return true;<br />
}<br />
};<br />
</syntaxhighlight><br />
<br />
Note that a better design is to minimize the use of <b><code>getSharedObject()</code></b>. So it is recommended that the creator of the handle add the shared object in its <b><code>init()</code></b>, and other tasks can store the handle in their <b><code>taskEntry()</code></b> function.<br />
<BR/><br />
<br />
=== Add the task in main() ===<br />
<syntaxhighlight lang="c"><br />
int main()<br />
{<br />
scheduler_add_task(new orient_compute(PRIORITY_LOW));<br />
scheduler_add_task(new orient_process(PRIORITY_LOW));<br />
scheduler_start();<br />
return 0;<br />
}<br />
</syntaxhighlight><br />
<br />
<BR/><br />
== Assignment ==<br />
This assignment is based on SJ-One board, but you can alter the requirement to fit your own hardware.<br />
# Create a task (task1) that computes the orientation of the board.<br />
#: You can use the acceleration sensor to figure out the orientation of the board<br />
#: Send the orientation enumeration, such as "up", "down", "left", "right" to a queue every 1 second<br />
# Create another task (task2) that waits on the queued item<br />
#: If the orientation is left or right, light up the LEDs (otherwise turn them off)<br />
# Note down the observations by doing the following:<br />
#: Print a message before and after sending the orientation to the queue<br />
#: Print a message after the second task receives an item from the queue<br />
#: Use the same priority for both tasks, and note down the order of the print-outs<br />
#: Use higher priority for the receiving task, and note down the order of the print-outs.<br />
# Create a terminal command: "orientation on" and "orientation off"<br />
#: If orientation is commanded on, resume the task1, otherwise suspend it<br />
#: See code below on hints of how this command can get control of another task.<br />
# Answer the following questions:<br />
#: What if you use ZERO block time while sending an item to the queue, will that make any difference?<br />
#: What is the purpose of the block time during xQueueReceive() ?<br />
<br />
<syntaxhighlight lang="c"><br />
// At the terminal tasks taskEntry() function :<br />
bool terminalTask::taskEntry()<br />
{<br />
cp.addHandler(orientationCmd, "orientation", "Two options: 'orientation on' or 'orientation off'");<br />
}<br />
<br />
// Somewhere else:<br />
CMD_HANDLER_FUNC(orientationCmd)<br />
{<br />
// Our parameter was the orientation tasks' pointer, but you may want to check for NULL pointer first.<br />
scheduler_task *compute = scheduler_task::getTaskPtrByName("compute");<br />
<br />
// You can use FreeRTOS API or the wrapper resume() or suspend() methods<br />
if (cmdParams == "on") {<br />
vTaskResume(compute->getTaskHandle()); // Can also use: compute->resume();<br />
}<br />
else {<br />
vTaskSuspend(compute->getTaskHandle()); // Can also use: compute->suspend();<br />
}<br />
<br />
return true;<br />
}<br />
</syntaxhighlight><br />
--></div>Sreehttp://socialledge.com/sjsu/index.php?title=Embedded_System_Tutorial_File_I/O&diff=51340Embedded System Tutorial File I/O2019-01-25T20:10:02Z<p>Sree: </p>
<hr />
<div>Socialledge is moving to two portals. <br />
* The Wiki will remain here for general references about the SJ-One board, and to document student reports.<br />
* The bookstack will now be used for SJSU assignments<br />
<br />
[http://books.socialledge.com/books/embedded-drivers-real-time-operating-systems/chapter/lesson-watch-dogs This article has been moved here]<br />
<br />
<!--<br />
<br />
In this project, we will attempt to "combine" all the FreeRTOS knowledge into a single assignment.<br />
<br />
<br />
After completing the assignment, you will get a sense of how the CPU is utilized, and how to use a new FreeRTOS event group API. All together, you should achieve a better sense of designing your tasks and using the File I/O for debugging purposes.<br />
<br />
<br />
== Assignment ==<br />
Please follow the steps precisely in order to complete the objectives of the assignment. If you use the C++ FreeRTOS framework, it should make the assignment significantly easy.<br />
<br />
<br />
# Create a '''<code>producer task</code>''' that takes 1 light sensor value every 1ms.<br />
#* After collecting 100 samples (after 100ms), compute the average.<br />
#* Write average value every 100ms (avg. of 100 samples) to the '''<code>sensor queue</code>'''.<br />
#* Use medium priority for this task<br />
# Create a '''<code>consumer task</code>''' that pulls the data off the '''<code>sensor queue</code>''' <br />
#* Use infinite timeout value during queue receive API<br />
#* Open a file (sensor.txt), and append the data to an output file on the SD card.<br />
#* Save the data in this format: '''<code>printf("%i, %i\n", time, light)"</code>'''<br />
#* Note that if you write and close a file every 100ms, it may be very inefficient, so try to come up with a better method such that the file is only written once a second or so...<br />
#* Use medium priority for this task<br />
# At the end of the loop of each task, set a bit using FreeRTOS event group API.<br />
#* At the end of each loop of the tasks, set a bit using the '''<code>xEventGroupSetBits()</code>'''<br />
#* Task 1 should set bit1, Task 2 should set bit2 etc.<br />
# Create a '''<code>watchdog task</code>''' that monitors the operation of the two tasks.<br />
#* Use high priority for this task.<br />
#* Use a timeout of 1 second, and wait for all the bits to set. If there are two tasks, wait for bit1, and bit2 etc.<br />
#* If you fail to detect the bits are set, that means that the other tasks did not reach the end of the loop.<br />
#* In the event of failed to detect the bits, append a file (stuck.txt) with the information about which task may be "stuck"<br />
#* Open the file, append the data, and close the (stuck.txt) file to flush out the data immediately.<br />
#* Extra Credit: Every sixty seconds, save the CPU usage info to a file named "cpu.txt". See terminal command "infoHandler" for reference. Open the file, write the file, and close it immediately so the data is immediately flushed.<br />
# Create a terminal command to "suspend" and "resume" a task by name.<br />
#* "task suspend task1" should suspend a task named "task1"<br />
#* "task resume task2" should suspend a task named "task2"<br />
# Run the system, and under normal operation, you will see a file being saved with sensor data values.<br />
#* Plot the file data in Excel to demonstrate.<br />
# Suspend the producer task. The watchdog task should display a message and save relevant info to the SD card.<br />
# Let the system run for a while, and note down the CPU usage in your text file.<br />
<br />
What you created is a "software watchdog". This means that in an event when a loop is stuck, or a task is frozen, you can save relevant information such that you can debug at a later time.<br />
--></div>Sreehttp://socialledge.com/sjsu/index.php?title=Embedded_System_I2C_Tutorial&diff=51339Embedded System I2C Tutorial2019-01-25T20:06:48Z<p>Sree: </p>
<hr />
<div><br />
Socialledge is moving to two portals. <br />
* The Wiki will remain here for general references about the SJ-One board, and to document student reports.<br />
* The bookstack will now be used for SJSU assignments<br />
<br />
[http://books.socialledge.com/books/embedded-drivers-real-time-operating-systems/chapter/lesson-i2c This article has been moved here]<br />
<br />
<!--<br />
== Theory of Operation ==<br />
I2C is prounced "eye-squared see". It is also known as "TWI" because of the intial patent issues of this BUS. This is a popular, low throughput (100-1000Khz), half-duplix BUS that only uses two wires regardless of how many devices are on this BUS. Many sensors use this BUS because of its ease of adding to a system.<br />
<br />
=== Open-Collector BUS ===<br />
I2C is an open-collector BUS, which means that no device shall have the capability of internally connecting either SDA or SCL wires to power source. The communication wires are instead connected to the power source through a "pull-up" resistor. When a device wants to communicate, it simply lets go of the wire for it to go back to logical "high" or "1" or it can connect it to ground to indicate logical "0".<br />
<br />
=== Pull-up resistor ===<br />
Using a smaller pull-up can acheiver higher speeds, but then each device must have the capability of sinking that much more current. For example, with a 5v BUS, and 1K pull-up, each device must be able to sink 5mA.<br />
<br />
[http://www.falstad.com/circuit/#%24+1+5.0E-6+3.3115451958692312+28+5.0+50%0Ac+192+176+192+240+0+1.0E-7+4.950495049504418%0Aw+192+176+256+176+0%0Ag+192+304+192+320+0%0As+112+176+112+256+0+1+false%0Ag+112+256+112+272+0%0Aw+192+176+112+176+0%0Ar+192+176+192+80+0+10000.0%0AR+192+80+192+32+0+0+40.0+5.0+0.0+0.0+0.5%0Ap+112+176+64+176+0%0Aw+256+176+320+176+0%0Ag+320+304+320+320+0%0Ar+192+240+192+304+0+100.0%0Ac+272+176+272+240+0+1.0E-7+-0.0%0Ar+272+240+272+304+0+100.0%0Ag+272+304+272+320+0%0Ar+320+304+320+176+0+1000000.0%0Ax+3+93+159+99+0+24+I2C+Simulation%0Ax+2+116+132+120+0+14+Switch+Shows+an+I2C%0Ax+2+142+119+146+0+14+grounding+a+signal%0Ao+8+64+0+34+5.0+9.765625E-5+0+-1%0A I2C Circuit Simulation]<br />
<br />
<BR/><br />
== Protocol Information ==<br />
I2C was designed to be able to read and write memory on a slave device. The protocol may be complicated, but a typical "transaction" involving read or write of a register on a slave device is simple granted a "sunny-day scenario" in which no errors occur.<br />
<br />
'''The code given below illustrates I2C transaction split into functions, but this is the wrong way of writing an I2C driver. An I2C driver should be "transaction-based" and the entire transfer should be carried out using a state machine. The idea is to design your software to walk the I2C hardware through its state to complete an I2C transfer.'''<br />
<br />
In the diagrams given below, your software should take the step given in the arrow, and the hardware will go to the next state granted that no errors occur. To implement this in your software, you should follow the following steps :<br />
# Perform the action given by the arrow<br />
# Clear the "SI" (state change) bit for HW to take the next step<br />
# Wait for "SI" (state change) bit to set, then take the next action<br />
<br />
The master will always initiate the transfer, and the device reading the data should always "ACK" the byte. For example, the master sends the 8-bit address after the START condition and the addressed slave should ACK the 9th bit (pull the line LOW). Likewise, when the master sends the first byte after the address, the slave should ACK that byte if it wishes to continue the transfer.<br />
<br />
When the master enters the "read mode" after transmitting the read address after a repeat-start, the master begins to "ACK" each byte that the slave sends. When the master "NACKs", it is an indication to the slave that it doesn't want to read anymore bytes from the slave.<br />
<br />
<BR/><br />
=== Write Transaction ===<br />
<br />
{| class="wikitable"<br />
|-<br />
| Code Sample<br />
| State Machine<br />
|-<br />
| <br />
<br />
A typical I2C write is to be able to write a register or memory address on a slave device. Here are the steps:<br />
# Master sends START condition followed by device address.<br />
#: Device should then "ACK" using 9th bit.<br />
# Master sends device's "memory address" (1 or more bytes).<br />
#: Each byte should be ACK'd by slave.<br />
# Master sends the data to write (1 or more bytes).<br />
#: Each byte should be ACK'd by slave.<br />
# Master sends the STOP condition.<br />
<br />
To maximize throughput and avoid having to do this for each memory location, the memory address is considered "starting address". If we continue to write data, we will end up writing data to M, M+1, M+2 etc.<br />
<br />
The ideal way of writing an I2C driver is one that is able to carry out an entire transaction given by the function below. Note that the function only shows the different actions hardware should take to carry out the transaction, but your software should be state machine based as illustrated on the state machine diagram on the right.<br />
<br />
<BR/><br />
<syntaxhighlight lang="c"><br />
void i2c_write_slave_reg(void)<br />
{<br />
i2c_start();<br />
i2c_write(slave_addr);<br />
i2c_write(slave_reg);<br />
i2c_write(data);<br />
<br />
/* Optionaly write more data to slave_reg+1, slave_reg+2 etc. */<br />
// i2c_write(data); /* M + 1 */<br />
// i2c_write(data); /* M + 2 */<br />
<br />
i2c_stop();<br />
}<br />
</syntaxhighlight><br />
| [[File:tutorial_i2c_write.png|center|frame|I2C Write Transaction]]<br />
|}<br />
<br />
<BR/><br />
<br />
=== Read Transaction ===<br />
<br />
{| class="wikitable"<br />
|-<br />
| Code Sample<br />
| State Machine<br />
|-<br />
| <br />
<br />
An I2C read is slightly more complex and involves more protocol to follow. What we have to do is switch from "write-mode" to "read-mode" by sending a repeat start, but this time with an ODD address. To simplify things, you can consider an I2C even address being "write-mode" and I2C odd address being "read-mode".<br />
<br />
Again, the function shows what we want to accomplish. The actual driver should use state machine logic to carry-out the entire transaction.<br />
<br />
<BR/><br />
<syntaxhighlight lang="c"><br />
void i2c_write_slave_reg(void)<br />
{<br />
i2c_start();<br />
i2c_write(slave_addr);<br />
i2c_write(slave_reg);<br />
<br />
i2c_start(); // Repeat start<br />
i2c_write(slave_addr | 0x01); // Odd address<br />
<br />
char data = i2c_read(0); // NACK if reading last byte<br />
<br />
/* If we wanted to read 3 register, it would look like this:<br />
* char d1 = i2c_read(1);<br />
* char d2 = i2c_read(1);<br />
* char d3 = i2c_read(0);<br />
*/<br />
<br />
i2c_stop();<br />
}<br />
</syntaxhighlight><br />
| [[File:tutorial_i2c_read.png|center|frame|I2C Read Transaction]]<br />
|}<br />
<br />
<BR/><br />
== I2C Slave State Machine Planning ==<br />
Before you jump right into the assignment, do the following:<br />
* Read and understand how an I2C master performs slave register read and write operation<br />
*: Look at existing code to see how the master operation handles the I2C state machine function<br />
*: This is important so you can understand the existing code base<br />
* Next to each of the master state, determine which slave state is entered when the master enters its state<br />
* Determine how your slave memory or registers will be read or written<br />
<br />
''' It is important to understand the states, and use the datasheet to figure out what to do in the state to reach the next desired state given in the diagrams below. '''<br />
<br />
=== Master Write ===<br />
In the diagram below, note that when the master sends the "R#", which is the register to write, the slave state machine should save this data byte as it's INDEX location. Upon the next data byte, the indexed data byte should be written.<br />
<br />
[[File:tutorial_i2c_master_write_state.png|center|frame|I2C Master Write Transaction]]<br />
<br />
=== Master Read ===<br />
In the diagram below, the master will write the index location (the first data byte), and then perform a repeat start. After that, you should start returning your indexed data bytes.<br />
<br />
[[File:tutorial_i2c_master_read_state.png|center|frame|I2C Master Read Transaction]]<br />
<br />
== Assignment ==<br />
<br />
=== I2C State Machine Assignment ===<br />
Design your I2C state machine. Look at the "Master Write" and "Master Read", and do the following:<br />
<br />
*Right underneath the Master State, determine which state the slave will enter when the master is in each of the states<br />
*In each slave state, determine the action you will perform for the transaction<br />
*You can design your own state machine, or augment the existing one, whichever method can yield the maximum clarify for your I2C slave state.<br />
<br />
=== I2C Code Assignment ===<br />
==== Assignment Outline ====<br />
<b>This is a group of two assignment; submit one copy of code per team and put down the names of your group members as part of the source code you turn in. Only turn in the new code you added, not the entire file.</b><br />
* The I2C#2 driver is already implemented and used for on-board sensors.<br />
* Study the existing I2C code: i2c_base.cpp. Please ask any questions if you have any, but the driver was implemented using the state machine diagrams given at the below wikipedia page.<br />
* On your master board, you can just use i2c terminal command to write a register to the other board which is acting as a slave. Hence, you only need to write code on one board (I2C slave board).<br />
<br />
==== Guidelines ====<br />
Design an I2C slave interface, and use one person's board as MASTER and communicate with the second person's SLAVE board. Here are the guidelines:<br />
Extend the I2C base class to also support slave operation. Test your I2C driver by using one board as a master, and another board as a slave.<br />
# Study <B><CODE>i2c_base.cpp</CODE></B>, particularly the following methods:<br />
#* <B><CODE>init()</CODE></B><br />
#* <B><CODE>i2cStateMachine()</CODE></B><br />
#*: Note that this function is called by the hardware interrupt asynchronously whenever I2C state changes.<br />
#*: The other I2C master will simply "kick off" the START state, and this function carries the hardware through its states to carry out the transaction.<br />
#* The functions you add to this base class are accessible by the I2C2 instance.<br />
# Add <B><CODE>initSlave()</CODE></B> method to the I2C to initialize the slave operation.<br />
#* Allow the user to supply a memory to be read or written by another master.<br />
# Extend the state machine for I2C slave operation.<br />
#* Study the CPU user manual first, and create a state machine diagram on paper.<br />
#* The first register supplied after the slave address should be used as an "offset" of the memory to read or write.<br />
# Demonstrate the following :<br />
#* Demonstrate that you are able to read and write the slave memory.<br />
#* For extra credit and bragging rights, create state machine diagrams, and if you can make better ones, I will use your diagrams at this wikipedia page :)<br />
<br />
=== Sample Code ===<br />
<syntaxhighlight lang="cpp"><br />
#include "i2c2.hpp"<br />
#include <stdint.h><br />
#include <stdio.h><br />
<br />
int main(void)<br />
{<br />
I2C2& i2c = I2C2::getInstance(); // Get I2C driver instance<br />
const uint8_t slaveAddr = 0xC0; // Pick any address other than the used used at i2c2.hpp<br />
uint8_t buffer[256] = { 0 }; // Our slave read/write buffer<br />
<br />
// high_level_init() will init() I2C, let's init slave<br />
i2c.initSlave(slaveAddr, &buffer, sizeof(buffer));<br />
<br />
// I2C interrupt will (should) modify our buffer.<br />
// So just monitor our buffer, and print and/or light up LEDs<br />
// ie: If buffer[0] == 0, then LED ON, else LED OFF<br />
uint8_t prev = buffer[0];<br />
while(1)<br />
{<br />
if (prev != buffer[0]) {<br />
prev = buffer[0];<br />
printf("buffer[0] changed to %#x\n", buffer[0]);<br />
}<br />
}<br />
<br />
return 0;<br />
}<br />
</syntaxhighlight><br />
<br />
=== Warning ===<br />
Since the I2C state machine function is called from inside an interrupt, you may not be able to to use <B><CODE>printf()</CODE></B>, especially if you are running FreeRTOS. As an alternative, use the debug printf methods from the <B><CODE>printf_lib.h</CODE></B> file.<br />
<br />
=== Hints ===<br />
* Start by hooking up master microcontroller running the default, unmodified sample FreeRTOS project<br />
* Familiarize yourself with the master microcontroller I2C commands: "help i2c"<br />
* Initialize the slave microcontroller's slave address such that you will get an interrupt when your address is sent by the master microcontroller<br />
* Add printfs to the I2C state machine code to identify what states you enter when the other master microcontroller is trying to do an I2C transaction<br />
* Follow your diagram and figure out how to make the I2C slave state machine walk through to read and write registers<br />
<BR/><br />
--></div>Sreehttp://socialledge.com/sjsu/index.php?title=Embedded_System_Tutorial_UART&diff=51338Embedded System Tutorial UART2019-01-25T20:05:38Z<p>Sree: </p>
<hr />
<div>Socialledge is moving to two portals. <br />
* The Wiki will remain here for general references about the SJ-One board, and to document student reports.<br />
* The bookstack will now be used for SJSU assignments<br />
<br />
[http://books.socialledge.com/books/embedded-drivers-real-time-operating-systems/chapter/lesson-uart This article has been moved here]<br />
<br />
<!--<br />
== Introduction ==<br />
The objective of this lesson is to understand UART, and use two boards and setup UART communication between them.<br />
<br />
'''UART''' stands for '''U'''niversal '''A'''synchronous '''R'''eceiver '''T'''ransmitter. There is one wire for transmitting data, and one wire to receive data. A common parameter is the baud rate known as "bps" which stands for '''b'''its '''p'''er '''s'''econd. If a transmitter is configured with 9600bps, then the receiver must be listening on the other end at the same speed.<br />
<br />
UART is a serial communication, so bits must travel on a single wire. If you wish to send a '''char''' over UART, the char is enclosed within a '''start''' and a '''stop''' bit, so to send 8-bits of '''char''' data, it would require 2-bit overhead; this 10-bit of information is called a '''UART frame'''. Let's take a look at how the character 'A' is sent over UART. In ASCII table, the character 'A' has the value of 65, which in binary is: 0100-0001. If you inform your UART hardware that you wish to send this data at 9600bps, here is how the frame would appear on an oscilloscope :<br />
[[File:uart_tutorial_frame.jpg|center|frame|UART Frame of 'A']]<br />
<br />
A micrcontroller can have multiple UARTs in its hardware, and usually UART0 is interfaced to a "USB to serial" converter chip which is then connected to your computer. In this exercise, you will write a driver for UART-2 and attempt to communicate between two boards.<br />
<br />
I encourage you to fully read this article first, and here is a video about the UART0 tutorial. This is a FAST PACED video, so learn to pause the video and look over your LPC user manual frequently :) '''Note that I forgot to configure the PINSEL registers, which are covered by this tutorial below.'''<br />
* [https://www.youtube.com/watch?v=RU_NUPprx2Y UART Driver Video]<br />
<br />
<BR/><br />
<br />
== UART Pins ==<br />
Before you write a UART software driver, you need to understand the physical constraints and identify the UART pins on your processor. A GPIO (general purpose input output) is a multi-purpose pin, and certain pins are used for certain functions. For example, P0.0 and P0.1 on your LPC17xx processor can be used for an LED (output), a switch (input), or as UART transmitter and receive signals. We will configure the microcontroller's internal MUX (multiplexor) to connect internal UART to external pins.<br />
<br />
[[File:tutorial_uart_pinsel.png|center|Find RXD2 and TXD2 of UART2]]<br />
<BR/><br />
[[File:tutorial_gpio_mux.png|center|Example MUX that we need to configure for a PIN selection]]<br />
<br />
<BR/><br />
<br />
== Clock System & Timing ==<br />
A crystal drives a processor clock, and it is usually less than 20Mhz. A processor usually uses a "PLL" or "phased-lock-loop" to generate a faster clock than the crystal. So, you could have a 4Mhz clock, and the PLL can be used to internally multiply the clock to provide 48Mhz to the processor. The same 48Mhz is then fed to processor peripherals, and sometimes you have a register that can divide this higher clock to slower peripherals that may not require a high clock rate. Remember that lower clock speed means lower power consumption.<br />
<br />
9600bps means that one bit takes 1/9600 = 104uS (micro-seconds) per bit. The idea is that we want to divide the peripheral clock to UART hardware by a number that yields roughly 104uS per bit. The '''Software Driver''' section goes over how to configure your UART driver to divide the clock to yield the desired baud rate.<br />
<br />
[[File:uart_tutorial_clock.jpg|center|frame|Example clock system of LPC17xx]]<br />
<br />
== Hardware Design ==<br />
There is not much hardware design other than to locate UART-2 pins on your processor board and connecting these wires to the second board. Each pin on a microcontroller may be designed to provide specific feature. So the first thing to do is identify which physical pins can provide UART-2 signals.<br />
<br />
After you identify the physical pins, you would connect these pins to the second board. '''Remember that your TX pin should be connected to second board's RX pin''' and vice versa. Connecting two TX pins together will damage your processor. After you connect the Rx/Tx pairs together, you also need to connect the '''ground''' wire of two boards together. Not connecting the ground reference together is essentially like asking the other board "How far is my hand from the ground" when the ground reference is missing.<br />
<br />
<br />
== Software Driver ==<br />
[[File:uart_tutorial_overview.jpg|center|frame|UART chapter summary]]<br />
<br />
{|<br />
| <br />
The UART chapter on LPC17xx has a really good summary page on how to write a UART driver. '''Read the register description of each UART register to understand how to write a driver.''' This tutorial gives away answers but unless you spend 1-2 hours reading the UART chapter, you will forget this knowledge. The datasheet shows many registers but remember that for a simple driver, we will not need interrupts so you can skip the sections that talk about the UART interrupts.<br />
<br />
<BR/><br />
Writing a uart initialization routine is simple except that some registers require a special setup to access them. In the sample code below, we power up UART0, and use the PINSEL register to configure the Rx/Tx Uart pins as the pin functionality. Finally, we just set the divider to achieve 9600bps. The exception here is that we have to read the datasheet carefully which states that the '''DLM''' and the '''DLL''' registers are only accessible if the '''DLAB''' bit is set at the '''LCR''' register.<br />
<br />
Notice that four registers have the same address. The UART divider registers are only accessible if DLAB bit is 1; this was done to protect accidental change of baud rate. Furthermore, notice that the CPU is intelligent enough to know if you are accessing the RX or the TX register based on if the register is being read or written.<br />
<br />
<syntaxhighlight lang="c"><br />
void uart0_init(void)<br />
{<br />
LPC_SC->PCONP |= (1 << 3); // Enable power to UART0<br />
LPC_SC->PCLKSEL0 &= ~(3 << 6);<br />
LPC_SC->PCLKSEL0 |= (1 << 6); // Uart clock = CPU / 1<br />
<br />
LPC_PINCON->PINSEL0 &= ~(0xF << 4); // Clear values<br />
LPC_PINCON->PINSEL0 |= (0x5 << 4); // Set values for UART0 Rx/Tx<br />
<br />
LPC_UART0->LCR = (1 << 7); // Enable DLAB<br />
/* See the formula picture to get more info.<br />
* Default values of fractional dividers simplifies the equation<br />
* Warning: You need to set DLM/DLL correctly, but if divider is small enough, it will fit inside DLL<br />
*/<br />
LPC_UART0->DLM = 0;<br />
LPC_UART0->DLL = CPU_CLOCK / (16 * 9600) + 0.5);<br />
<br />
LPC_UART0->LCR = 3; // 8-bit data<br />
}<br />
</syntaxhighlight><br />
| [[File:uart_tutorial_dlab.jpg|center|frame|DLAB bit to access registers]]<br />
[[File:uart_tutorial_formula.jpg|center|frame|Baud rate formula]]<br />
|}<br />
<br />
<syntaxhighlight lang="c"><br />
char uart0_putchar(char out)<br />
{<br />
LPC_UART0->THR = out;<br />
while(! (LPC_UART0->LSR & (1 << 6)));<br />
return 1;<br />
}<br />
</syntaxhighlight><br />
<br />
<BR/><br />
To send a char over UART, the code looks incredibly easy; just two lines! It is supposed to be very easy because the UART hardware is supposed to handle the UART frame, and send start bit, followed by 8-data bits, and a stop bit by simply writing the '''THR''' register. The moment you write this register, the hardware will start shifting bits out of the wire. The while loop is present because after you write the '''THR''' register, we want to wait until hardware is done sending the bits out of the wire otherwise writing the same register again will corrupt the on-going transfer.<br />
<BR/><br />
<br />
== Advanced Design ==<br />
What you've done so far is wrote a polling UART driver. If you used 9600bps, and sent 1000 characters, your processor would basically enter a "busy-wait" loop and spend 1040ms to send 1000 bytes of data. You can enhance this behavior by allowing your <code>uart_putchar()</code> function to enter data to a queue, and return immediately, and you can use the "THRE" or "Transmitter Holding Register Empty" interrupt indicator to remove your busy-wait loop while you wait for a character to be sent.<br />
<br />
== Assignment ==<br />
* <b>Assignment Outline</b><br />
*: Form 2 people teams for this assignment.<br />
*: Write a driver for UART2 or UART3<br />
*: Do not use the pre-built driver or Uart2/3 class<br />
*: Connect your UART to your partner's UART (to his board)<br />
*: Prove that you can send/receive data across multiple boards.<br />
*: Upload Logic Analyzer Screenshot for the UART Frame.<br />
* <b>Extra Credit</b>: <br />
*: Use Uart interrupt to queue the received data to avoid polling. You just need to enable UART RX interrupt and then hookup an interrupt callback to do the receive.<br />
* <b>Steps</b><br />
*: Locate the physical pins for a UART that is not already used by your board<br />
*: Configure the PINSEL to use the pins for UART Rx/Tx<br />
*: Initialize your UART at any baud rate<br />
*: Write uart_putchar(char) and uart_getchar() functions<br />
*: Interface your UART with someone else's board, and test the communication.<br />
--></div>Sreehttp://socialledge.com/sjsu/index.php?title=Embedded_System_Tutorial_GPIO&diff=51337Embedded System Tutorial GPIO2019-01-25T20:02:33Z<p>Sree: </p>
<hr />
<div>Socialledge is moving to two portals. <br />
* The Wiki will remain here for general references about the SJ-One board, and to document student reports.<br />
* The bookstack will now be used for SJSU assignments<br />
<br />
[http://books.socialledge.com/books/embedded-drivers-real-time-operating-systems/chapter/lesson-gpio This article has been moved here]<br />
<br />
<!--<br />
== Objective ==<br />
Interface your LPC17xx to a switch and an LED.<br />
<br />
Although the interface may seem simple, you do need to consider hardware design and know some of the fundamental of electricity. There are a couple of goals for us :<br />
* No hardware damage if faulty software is written.<br />
* Circuit should prevent excess amount of current to avoid processor damage.<br />
<br />
== Required Background ==<br />
* You should know how to bit-mask variables<br />
* You should know how to wire-wrap<br />
* You should know fundamentals of electricity and the famous '''V = IR''' equation.<br />
<br />
== GPIO ==<br />
{| class="wikitable"<br />
|-<br />
|<br />
GPIO stands for "General Purpose Input Output". Each pin can at least be used as an output or input. In an output configuration, the pin voltage is either 0v or 3.3v. In input mode, we can read whether the voltage is 0v or 3.3v.<br />
<br />
You can locate a GPIO that you wish to use for a switch or an LED by first starting with the schematic of the board. The schematic will show which pins are "available" because some of the microcontroller pins may be used internally by your development board. After you locate a free pin, such as P2.0, then you can look-up the microcontroller user manual to locate the memory that you can manipulate.<br />
<br />
|[[File:tutorial_gpio_design.png|center|frame|GPIO Design]]<br />
|}<br />
<br />
== Coding ==<br />
=== Hardware Registers ===<br />
The hardware registers map to physical pins. If we want to attach our switch and the LED to our microcontroller's PORT0, then here are the relevant registers and their functionality :<br />
{| class="wikitable"<br />
|+LPC17xx Port0 Registers<br />
|-<br />
|'''LPC_GPIO0->FIODIR'''<br />
|Direction of the port pins, 1 = output<br />
|-<br />
|'''LPC_GPIO0->FIOPIN'''<br />
|<br />
Read : Sensed inputs of the port pins, 1 = HIGH<br />
Write : Control voltage level of the pin, 1 = 3.3v<br />
|-<br />
|'''LPC_GPIO0->FIOSET'''<br />
|Write only : Any bits written 1 are OR'd with FIOPIN<br />
|-<br />
|'''LPC_GPIO0->FIOCLR'''<br />
|Write only : Any bits written 1 are AND'd with FIOPIN<br />
|}<br />
<br />
<BR/><br />
=== Switch ===<br />
{| class="wikitable"<br />
|+ We will interface our switch to PORT0.2, or port zero's 3rd pin (counting from 0).<br />
|-<br />
|<br />
<syntaxhighlight lang="c"><br />
/* Make direction of PORT0.2 as input */<br />
LPC_GPIO0->FIODIR &= ~(1 << 2);<br />
<br />
/* Now, simply read the 32-bit FIOPIN registers, which corresponds to<br />
* 32 physical pins of PORT0. We use AND logic to test if JUST the<br />
* pin number 2 is set<br />
*/<br />
if (LPC_GPIO0->FIOPIN & (1 << 2)) {<br />
// Switch is logical HIGH<br />
}<br />
else {<br />
// Switch is logical LOW<br />
}<br />
</syntaxhighlight><br />
|Note that the "inline" resistor is used such that if your GPIO is mis-configured as an OUTPUT pin, hardware damage will not occur from badly written software.<br />
[[File:gpio_switch_circuit.png|center|frame|Switch Circuit]]<br />
|}<br />
<br />
=== LED ===<br />
{| class="wikitable"<br />
|+ We will interface our LED to PORT0.3, or port zero's 4th pin (counting from 0).<br />
|-<br />
|<br />
<syntaxhighlight lang="c"><br />
/* Make direction of PORT0.3 as OUTPUT */<br />
LPC_GPIO0->FIODIR |= (1 << 3);<br />
<br />
/* Setting bit 3 to 1 of IOPIN will turn ON LED<br />
* and resetting to 0 will turn OFF LED.<br />
*/<br />
LPC_GPIO0->FIOPIN |= (1 << 3);<br />
<br />
/* Faster, better way to set bit 3 (no OR logic needed) */<br />
LPC_GPIO0->FIOSET = (1 << 3);<br />
<br />
/* Likewise, reset to 0 */<br />
LPC_GPIO0->FIOCLR = (1 << 3);<br />
</syntaxhighlight><br />
|Given below are two configurations of an LED. Usually, the "sink" current is higher than "source", hence the active-low configuration is used more often.<br />
[[File:gpio_led_active_low.png|center|frame|Active-low LED circuit]] [[File:gpio_led_active_high.png|center|frame|Active-high LED circuit]]<br />
|}<br />
<br />
== Assignment ==<br />
At the end of this lab, you should be familiar with how a microcontroller's memory can access physical pins. Test your knowledge by doing the following:<br />
* Interface your board's GPIO pin to an external switch<br />
* Interface your board's GPIO pin to an LED<br />
* If the switch is pressed, light up an LED<br />
* Do not use any pre-existing library such as a GPIO class<br />
<br />
Upload into the textbox just the relevant code, probably just main.cpp<br />
<br />
<b>Extra Credit:</b> Do something creative, such as lighting up an LED based on a terminal command.<br />
<br />
[[Embedded System GPIO Assignment]]<br />
<br />
--></div>Sreehttp://socialledge.com/sjsu/index.php?title=Embedded_System_Tutorial_Tasks&diff=51336Embedded System Tutorial Tasks2019-01-25T19:55:41Z<p>Sree: </p>
<hr />
<div>Socialledge is moving to two portals. <br />
* The Wiki will remain here for general references about the SJ-One board, and to document student reports.<br />
* The bookstack will now be used for SJSU assignments<br />
<br />
[http://books.socialledge.com/books/embedded-drivers-real-time-operating-systems/page/lab-assignment-freertos-tasks This article has been moved here]</div>Sreehttp://socialledge.com/sjsu/index.php?title=Embedded_System_Tutorial_Tasks&diff=51335Embedded System Tutorial Tasks2019-01-25T17:07:27Z<p>Sree: </p>
<hr />
<div>Socialledge is moving to two portals. <br />
* The Wiki will remain here for general references about the SJ-One board, and to document student reports.<br />
* The bookstack will now be used for SJSU assignments<br />
<br />
[http://books.socialledge.com/books/embedded-drivers-real-time-operating-systems/chapter/lesson-gpio This article has been moved here]</div>Sreehttp://socialledge.com/sjsu/index.php?title=Embedded_System_Tutorial_GPIO&diff=51334Embedded System Tutorial GPIO2019-01-25T17:05:14Z<p>Sree: </p>
<hr />
<div>Hello world<br />
<br />
<!--<br />
== Objective ==<br />
Interface your LPC17xx to a switch and an LED.<br />
<br />
Although the interface may seem simple, you do need to consider hardware design and know some of the fundamental of electricity. There are a couple of goals for us :<br />
* No hardware damage if faulty software is written.<br />
* Circuit should prevent excess amount of current to avoid processor damage.<br />
<br />
== Required Background ==<br />
* You should know how to bit-mask variables<br />
* You should know how to wire-wrap<br />
* You should know fundamentals of electricity and the famous '''V = IR''' equation.<br />
<br />
== GPIO ==<br />
{| class="wikitable"<br />
|-<br />
|<br />
GPIO stands for "General Purpose Input Output". Each pin can at least be used as an output or input. In an output configuration, the pin voltage is either 0v or 3.3v. In input mode, we can read whether the voltage is 0v or 3.3v.<br />
<br />
You can locate a GPIO that you wish to use for a switch or an LED by first starting with the schematic of the board. The schematic will show which pins are "available" because some of the microcontroller pins may be used internally by your development board. After you locate a free pin, such as P2.0, then you can look-up the microcontroller user manual to locate the memory that you can manipulate.<br />
<br />
|[[File:tutorial_gpio_design.png|center|frame|GPIO Design]]<br />
|}<br />
<br />
== Coding ==<br />
=== Hardware Registers ===<br />
The hardware registers map to physical pins. If we want to attach our switch and the LED to our microcontroller's PORT0, then here are the relevant registers and their functionality :<br />
{| class="wikitable"<br />
|+LPC17xx Port0 Registers<br />
|-<br />
|'''LPC_GPIO0->FIODIR'''<br />
|Direction of the port pins, 1 = output<br />
|-<br />
|'''LPC_GPIO0->FIOPIN'''<br />
|<br />
Read : Sensed inputs of the port pins, 1 = HIGH<br />
Write : Control voltage level of the pin, 1 = 3.3v<br />
|-<br />
|'''LPC_GPIO0->FIOSET'''<br />
|Write only : Any bits written 1 are OR'd with FIOPIN<br />
|-<br />
|'''LPC_GPIO0->FIOCLR'''<br />
|Write only : Any bits written 1 are AND'd with FIOPIN<br />
|}<br />
<br />
<BR/><br />
=== Switch ===<br />
{| class="wikitable"<br />
|+ We will interface our switch to PORT0.2, or port zero's 3rd pin (counting from 0).<br />
|-<br />
|<br />
<syntaxhighlight lang="c"><br />
/* Make direction of PORT0.2 as input */<br />
LPC_GPIO0->FIODIR &= ~(1 << 2);<br />
<br />
/* Now, simply read the 32-bit FIOPIN registers, which corresponds to<br />
* 32 physical pins of PORT0. We use AND logic to test if JUST the<br />
* pin number 2 is set<br />
*/<br />
if (LPC_GPIO0->FIOPIN & (1 << 2)) {<br />
// Switch is logical HIGH<br />
}<br />
else {<br />
// Switch is logical LOW<br />
}<br />
</syntaxhighlight><br />
|Note that the "inline" resistor is used such that if your GPIO is mis-configured as an OUTPUT pin, hardware damage will not occur from badly written software.<br />
[[File:gpio_switch_circuit.png|center|frame|Switch Circuit]]<br />
|}<br />
<br />
=== LED ===<br />
{| class="wikitable"<br />
|+ We will interface our LED to PORT0.3, or port zero's 4th pin (counting from 0).<br />
|-<br />
|<br />
<syntaxhighlight lang="c"><br />
/* Make direction of PORT0.3 as OUTPUT */<br />
LPC_GPIO0->FIODIR |= (1 << 3);<br />
<br />
/* Setting bit 3 to 1 of IOPIN will turn ON LED<br />
* and resetting to 0 will turn OFF LED.<br />
*/<br />
LPC_GPIO0->FIOPIN |= (1 << 3);<br />
<br />
/* Faster, better way to set bit 3 (no OR logic needed) */<br />
LPC_GPIO0->FIOSET = (1 << 3);<br />
<br />
/* Likewise, reset to 0 */<br />
LPC_GPIO0->FIOCLR = (1 << 3);<br />
</syntaxhighlight><br />
|Given below are two configurations of an LED. Usually, the "sink" current is higher than "source", hence the active-low configuration is used more often.<br />
[[File:gpio_led_active_low.png|center|frame|Active-low LED circuit]] [[File:gpio_led_active_high.png|center|frame|Active-high LED circuit]]<br />
|}<br />
<br />
== Assignment ==<br />
At the end of this lab, you should be familiar with how a microcontroller's memory can access physical pins. Test your knowledge by doing the following:<br />
* Interface your board's GPIO pin to an external switch<br />
* Interface your board's GPIO pin to an LED<br />
* If the switch is pressed, light up an LED<br />
* Do not use any pre-existing library such as a GPIO class<br />
<br />
Upload into the textbox just the relevant code, probably just main.cpp<br />
<br />
<b>Extra Credit:</b> Do something creative, such as lighting up an LED based on a terminal command.<br />
<br />
[[Embedded System GPIO Assignment]]<br />
<br />
--></div>Sreehttp://socialledge.com/sjsu/index.php?title=MP3_Player&diff=40314MP3 Player2017-11-10T08:10:16Z<p>Sree: /* Project Requirements */</p>
<hr />
<div>== Project Summary ==<br />
The goal of this project is to create a fully functional MP3 music player using SJOne Microcontroller board as the source for music and control.<br />
MP3 files will be present on an SD card. SJOne board reads these files and transfers data to a audio decoding peripheral for generating music.<br />
User would be able to use player controls (start/stop/pause) for playing MP3 songs and view the track information on a display.<br />
<br />
== Block Diagram ==<br />
<br />
[[File : Mp3_player_block_diagram.png|center|frame|]]<br />
<br />
== Project Requirements ==<br />
* Use the sdcard slot on SJOne microcontroller for reading MP3 files from a preloaded SD Card<br />
* Use audio encoder/decoder peripheral board to decode mp3 data sent from SJ One Board using serial(preferably SPI) bus</div>Sreehttp://socialledge.com/sjsu/index.php?title=MP3_Player&diff=40313MP3 Player2017-11-10T08:05:17Z<p>Sree: /* Project Requirements */</p>
<hr />
<div>== Project Summary ==<br />
The goal of this project is to create a fully functional MP3 music player using SJOne Microcontroller board as the source for music and control.<br />
MP3 files will be present on an SD card. SJOne board reads these files and transfers data to a audio decoding peripheral for generating music.<br />
User would be able to use player controls (start/stop/pause) for playing MP3 songs and view the track information on a display.<br />
<br />
== Block Diagram ==<br />
<br />
[[File : Mp3_player_block_diagram.png|center|frame|]]<br />
<br />
== Project Requirements ==<br />
* Use the sdcard slot on SJOne microcontroller for reading MP3 files from a preloaded SD Card<br />
* Use audio encoder/decoder peripheral interface board to decode mp3 data from SJ One Board using serial(preferably SPI) protocol</div>Sreehttp://socialledge.com/sjsu/index.php?title=MP3_Player&diff=40312MP3 Player2017-11-10T08:00:43Z<p>Sree: /* Block Diagram */</p>
<hr />
<div>== Project Summary ==<br />
The goal of this project is to create a fully functional MP3 music player using SJOne Microcontroller board as the source for music and control.<br />
MP3 files will be present on an SD card. SJOne board reads these files and transfers data to a audio decoding peripheral for generating music.<br />
User would be able to use player controls (start/stop/pause) for playing MP3 songs and view the track information on a display.<br />
<br />
== Block Diagram ==<br />
<br />
[[File : Mp3_player_block_diagram.png|center|frame|]]<br />
<br />
== Project Requirements ==</div>Sreehttp://socialledge.com/sjsu/index.php?title=MP3_Player&diff=40311MP3 Player2017-11-10T07:58:52Z<p>Sree: /* Block Diagram */</p>
<hr />
<div>== Project Summary ==<br />
The goal of this project is to create a fully functional MP3 music player using SJOne Microcontroller board as the source for music and control.<br />
MP3 files will be present on an SD card. SJOne board reads these files and transfers data to a audio decoding peripheral for generating music.<br />
User would be able to use player controls (start/stop/pause) for playing MP3 songs and view the track information on a display.<br />
<br />
== Block Diagram ==<br />
<br />
[[File : Mp3_player_block_diagram.png]]<br />
<br />
== Project Requirements ==</div>Sreehttp://socialledge.com/sjsu/index.php?title=File:Mp3_player_block_diagram.png&diff=40310File:Mp3 player block diagram.png2017-11-10T07:56:59Z<p>Sree: </p>
<hr />
<div></div>Sreehttp://socialledge.com/sjsu/index.php?title=MP3_Player&diff=40309MP3 Player2017-11-10T07:28:33Z<p>Sree: </p>
<hr />
<div>== Project Summary ==<br />
The goal of this project is to create a fully functional MP3 music player using SJOne Microcontroller board as the source for music and control.<br />
MP3 files will be present on an SD card. SJOne board reads these files and transfers data to a audio decoding peripheral for generating music.<br />
User would be able to use player controls (start/stop/pause) for playing MP3 songs and view the track information on a display.<br />
<br />
== Block Diagram ==<br />
<br />
== Project Requirements ==</div>Sreehttp://socialledge.com/sjsu/index.php?title=MP3_Player&diff=40308MP3 Player2017-11-10T06:54:23Z<p>Sree: Blanked the page</p>
<hr />
<div></div>Sreehttp://socialledge.com/sjsu/index.php?title=MP3_Player&diff=40307MP3 Player2017-11-10T06:53:02Z<p>Sree: /* Project Requirements */</p>
<hr />
<div>== Project Overview ==<br />
The goal of this project is to create a fully functional MP3 player using SJOne Microcontroller board as the <br />
<br />
== Project Requirements ==</div>Sreehttp://socialledge.com/sjsu/index.php?title=MP3_Player&diff=40306MP3 Player2017-11-10T06:45:28Z<p>Sree: Created page with "== Project Requirements =="</p>
<hr />
<div>== Project Requirements ==</div>Sreehttp://socialledge.com/sjsu/index.php?title=Realtime_OS_on_Embedded_Systems&diff=40305Realtime OS on Embedded Systems2017-11-10T06:44:29Z<p>Sree: </p>
<hr />
<div>== Program History ==<br />
My contribution in Embedded System courses started with CmpE146. This course teaches students on how to write UART, SPI, and I2C Drivers and interface their drivers to peripherals. There are about 8 weekly labs in which students not only write drivers, but also learn the core of Real-time Operating Systems including threading (tasks), and inter-task communication using Queues and Semaphores. FreeRTOS is the operating system used with C/C++ Compiler based on GNU.<br />
<br />
When the course was started by Dr. Ozemek @ SJSU (sometime before 2005), not many resources were out there. Still, with helpful guidance from Dr. Ozemek, interesting projects were created. This is when I started to help out in Embedded System Courses, and by collecting and sharing knowledge, we've raised the bar at SJSU! <br />
<br />
There have been many great projects at SJSU, but since no one knew about them, the hard work went to a waste for anyone but the creator. But now we've got the infrastructure to share the projects, which turn out as great references for future students. Here is my project that started around 2007, and turned into Bachelor's Senior Design Project: <br/><br />
[http://www.youtube.com/watch?v=QEadXdRl3ws&feature=plcp YouTube Video of Self-Navigating Car]<br />
<br />
As of 2013, I have broadened my contribution to other embedded system courses like CmpE240, CmpE243 and CmpE244.<br />
<br />
== Lab Assignments ==<br />
This article contains laboratory assignments and resources. The assignments are under construction as we move towards SJ-One development board.<br />
* [[Embedded System Tutorial GPIO | Lesson 1 : GPIO]]<br />
* [[Embedded System Tutorial UART | Lesson 2 : UART]]<br />
* [[Embedded System Tutorial SPI | Lesson 3 : SPI]]<br />
* [[Embedded System I2C Tutorial | Lesson 4 : I2C]]<br />
* [[Embedded System Tutorial Interrupts | Lesson 5 : Interrupts]]<br />
* [[Embedded System Tutorial FreeRTOS | Lesson 6 : FreeRTOS Tasks]]<br />
* [[Embedded System Tutorial File I/O | Lesson 7 : FreeRTOS Application Programming]]<br />
<br />
==== Class Project ====<br />
* [[MP3 Player]]<br />
<br />
==Other reference articles==<br />
* [[Bitmasking Tutorial]] (+ GPIO Example)<br />
* [[ LPC17xx Memory Map & Interrupts]]<br />
<br />
<BR/><br />
== Senior Design Projects ==<br />
<br />
<BR/><br />
== Semester Projects ==<br />
Every semester, students are given about 7-10 weeks to complete their projects. During this short time-span, students form groups, order parts, and begin working on their projects. The work performed during the semester is documented at this Wiki.<br />
<br />
Here is the list of Preet's documented projects:<BR/><br />
* [[Preet's Relay Controller Project]]<br />
* [[Nordic Low Powered Mesh Network stack]]<br />
* [http://www.youtube.com/watch?v=QEadXdRl3ws&feature=plcp Senior Design Project (MS-CmpE) Video]<br />
<br />
Here is another resource for good project references :<br />
[http://people.ece.cornell.edu/land/courses/ece4760/FinalProjects/ Cornell EE476 Projects]<br />
<br />
<BR/><br />
<HR><br />
=== Appendix ===<br />
<br />
=== [[Spring 2017 | Spring 2017]] ===<br />
<br />
* [[S17: Wake up Barista]]<br />
* [[S17: Propeller Clock]]<br />
* [[S17: Sky Knight]]<br />
* [[S17: MyAutoHealth]]<br />
* [[S17: Logan]]<br />
* [[S17: ElectricBoard]]<br />
* [[S17: CamBot]]<br />
* [[S17: Sphero Droid]]<br />
* [[S17: Smart Planter]]<br />
* [[S17: Boom-Z Equalizer]]<br />
* [[S17: Interactive Snake and ladder ]]<br />
* [[S17: Smart Health Gear]]<br />
* [[S17: Halo]]<br />
* [[S17: Squad]]<br />
* [[S17: Smart security system]]<br />
<BR/><br />
<br />
=== [[Fall 2016 | Fall 2016]] ===<br />
<br />
CMPE146:<br />
* [http://www.socialledge.com/sjsu/index.php?title=F16:_Seismograph F16: Seismograph]<br />
* [[F16: Piano Glove]]<br />
* [[F16: Object Detector]]<br />
* [[F16: Autonomous Nautical System]]<br />
* [[F16: Autonomous Fire Extinguishing Vehicle]]<br />
* [[F16: Autonomous Runaway Alarm Car]]<br />
* [[F16: E-Bike]]<br />
* [[F16: NotifyBox]]<br />
* [[F16: Wireless Tilt Controlled Camera Arm]]<br />
* [[F16: OBD2 Reader]]<br />
* [[F16: Micro Watch Monitoring System]]<br />
* [[F16: Door Alarm System]]<br />
* [[http://www.socialledge.com/sjsu/index.php?title=F16:_I2Coffee F16: UART Coffee]]<br />
* [[F16: SJone to FPGA wireless integration]]<br />
<br />
=== [[Spring 2016 | Spring 2016]] ===<br />
* [[S16: Fantastic Four]]<br />
* [[S16: Simpsons]]<br />
* [[S16: Mars 1]]<br />
* [[S16: OpenSJ Bluz]]<br />
* [[S16: Motion Copy Bot]]<br />
* [[S16: Biker Assist]]<br />
* [[S16: Helios]]<br />
* [[S16: Sound Buddy]]<br />
* [[S16: Warriors]]<br />
* [[S16: Expendables]]<br />
* [[S16: Ahava]]<br />
* [[S16: Number 1]]<br />
* [[S16: SkyNet]]<br />
* [[S16: SmartDoorLock]]<br />
<br />
<br />
Cmpe 146:<br />
* [[S16: Camera Gimbal]]<br />
* [[S16: Laser Harp]]<br />
* <strike>[[S16: Laser Cutter Motor Controller]]</strike><br />
* [[S16: Sprinkler]]<br />
* [[S16: The Jatrick Car]]<br />
* [[S16: Dan]]<br />
* [[S16: Robolamp]]<br />
* [[S16: Pinball]]<br />
<br/><br />
<HR><br />
<br />
=== [[Fall 2015 | Fall 2015]] ===<br />
<br />
CmpE146:<br />
* [[F15: Autonomous Mobile]]<br />
* [[F15: Car Report]]<br />
* [[F15: Electronic Piano]]<br />
* [[F15: Doorknock over Bluetooth]]<br />
* [[F15: Smart Car]]<br />
* [[F15: Plant Control]]<br />
* [[F15: Laser Security System]]<br />
<br />
<br/><br />
<HR><br />
<br />
=== [[CmpE244 Spring 2015 | Spring 2015]] ===<br />
<br />
<br/><br />
* [[S15: Quadcopter - It flies]]<br />
* [[S15: Remote Learner]]<br />
* [[S15: Protocol Interface: I2C - CAN Bridge]]<br />
* [[S15: Vision RC Car]]<br />
* [[S15: SJeight Octocopter]]<br />
* [[S15: Swarm Robots]]<br />
* [[S15: Smart Sparta Parking System]]<br />
* [[S15: Touch Navigator]]<br />
* [[S15: Wizard's Chess System]]<br />
* [[S15: Bug Rider]]<br />
* [[S15: Real Time Brake Assist (RTBA)]]<br />
* [[S15: Wireless Mesh Network]]<br />
* [[S15: Wireless Power Transfer System]]<br />
* [[S15: Drone]]<br />
* [[S15: Tree Node using Google Protocol Buffers]]<br />
* [[S15: Multi-media Car]]<br />
* [[S15: Hand Gesture Recognition using IR Sensors]]<br />
* [[S15: CAN controlled RGB LED cubes]]<br />
* [[S15: Rubik's Cube Solver]]<br />
* [[S15: RFID Security Box]]<br />
* [[S15: Automated Meeting Room Reservation]]<br />
* [[S15: Patient Buddy System (PBS)]]<br />
<br />
CmpE146:<br />
* [[S15: Hovercopter]]<br />
* [[S15: Triclops: Smart RC Car]]<br />
* [[S15: Connect Four - Robotic Player]]<br />
* [[S15: Self-Balancing Robot]]<br />
* [[S15: MP3 Player with Graphic Equalizer Display]]<br />
* [[S15: Motion-Controlled RC Car]]<br />
* [[S15: MENL (Monster Encounter Night Light) ]]<br />
* [[S15: Tilt Motion Controlled LED Alarm Clock]]<br />
* [[S15: Alarm Based Coffee Maker]]<br />
<br />
=== [[CmpE244 Spring 2014 | Spring 2014]] ===<br />
<br />
<br/><br />
* Senior Project: [[Project Advising: Remote Security System]]<br />
<br />
<br/><br />
* [[S14: Quadcopter]]<br />
* [[S14: Smart Weather Clock]]<br />
* [[S14: Divine WINd]]<br />
* [[S14: Data Acquisition using CAN bus]]<br />
* [[S14: E-Ink Display for Shopping Tags]]<br />
* [[S14: Spectrum Analyzer for Audio Frequency Signals]]<br />
* [[S14: CAN Firmware Uploader]]<br />
* [[S14: Asset Management and Location System]]<br />
* [[S14: Location Tracker]]<br />
* [[S14: Androbot]]<br />
* [[S14: Virtual Dog]]<br />
* [[S14: Android based Automation]]<br />
* [[S14: FaceTime Robo]]<br />
* [[S14: Wireless Control Car]]<br />
* [[S14: Power Efficient Security Door System for Light-rail using CAN Bus]]<br />
* [[S14: Android based home monitoring system]]<br />
* [[S14: Need For Speed]]<br />
<br />
CmpE146<br />
* [[S14: Hyperintelligent NFC Locker of the Future]]<br />
* [[S14: Smart Planter]]<br />
* [[S14: Modular Security System]]<br />
* [[S14: Autonomous Control System]]<br />
* [[S14: Anti-Crash Car]]<br />
* [[S14: Tricopter]]<br />
<br />
=== [[CmpE240 Fall 2013 | Fall 2013]] ===<br />
<br />
* [[F13: POV Display]]<br />
* [[F13: Line Following Robot]]<br />
* [[F13: LED Display]]<br />
* [[F13: Bulb Ramper]]<br />
* [[F13: Garage Parking Assistant]]<br />
* [[F13: Quadcopter]]<br />
* [[F13: BarkMaster2000]]<br />
* [[F13: Remote Control Car]]<br />
* [[F13: Obstacle Avoidance Robot]]<br />
* [[F13: Vehicle On Board Diagnostics]]<br />
<br />
=== [[CmpE146 Spring 2013 | Spring 2013]] ===<br />
<br />
* [[S13: 2D Plotter]]<br />
* [[S13: Smart Cube]]<br />
* [[S13: Garage Parking Aid]]<br />
* [[S13: Smart Security]]<br />
* [[S13: Door Alarm System]]<br />
* [[S13: Solar Panel Tracker]]<br />
<br />
=== [[CmpE146 Fall 2012|Fall 2012]] ===<br />
<br />
* [[F12: Evil Watchdog]]<br />
* [[F12: Smart Bulb]]<br />
* [[F12: All Your Base are Belong to You]]<br />
* [[F12: Android Controlled MP3]]<br />
* [[F12: Unified Wireless Health Monitoring System]]<br />
* [[F12: OBD-II Android Monitor]]<br />
* [[F12: Self-Driving GPS Following Car]]<br />
* [[F12: Android Door Lock]]<br />
<br />
=== [[CmpE146 Spring 2012|Spring 2012]] ===<br />
* [[S12: FreeRTOS based QuadCopter]]<br />
* [[S12: Web-based MP3 Player]]<br />
* [[S12: Self Drive Car]]<br />
* [[S12: VAndroid]]<br />
* [[S12: Traffic Light Sensing Vehicle]]<br />
* [[S12: Sound Reader]]<br />
* [[S12: Remote Controlled MP3 Player]]<br />
* [[S12: Android Controlled Robot]]<br />
* [[S12: Eyes-Free GPS]]<br />
<br />
<br/><br />
<br />
== Handy References ==<br />
* [[Sample Project Report]]<br />
* [[Project Proposal Guidelines]]<br />
* [[CmpE146 Lab. Resources]]</div>Sree