Embedded Systems Learning Academy - User contributions [en]

File:Git icon.svg.png

2018-05-03T03:45:51Z

Kammce: test

test

MP3 Player

2017-12-10T23:57:41Z

Kammce: /* Functional Requirements */

== Project Summary ==
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.
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.
User would be able to use player controls (start/stop/pause) for playing MP3 songs and view the track information on a display.

== Block Diagram ==

[[File : Mp3_player_block_diagram.png|center|frame|]]

== Project Requirements ==
=== Non-Functional Requirements: ===
* Should be dynamic.
** As in, you should be able to add more songs and play them
* Should be accurate.
** Audio should not sound distorted,
** Audio should not sound slower or faster when running on your system.
* Should be user friendly.
** User should be able to figure out how to use the device without a user manual.
** Product must be packaged in some enclosure. No wires can be vision for the project.

=== Functional Requirements ===
# System must use the SJOne on board SD card to read MP3 audio files.
# System must communicate to an external MP3 decoder
# System must allow users to control the MP3 player (You may use the onboard buttons for this)
## User must be able to play and pause of song
## user must be able to select a song
# System must use an external display to show a menu providing the following information:
## Current playing song
## Information about current playing song
## Menu showing how to select a different song
## (Not all of the above need to be shown on the same display)
# System software must separated into tasks. EX: Display task, MP3 Read Task, Controller Task etc...
# System software must be thread safe always.
# System software must use OS structures and primitives where applicable.
# System software may only utilize 50% or less CPU

=== Prohibited Actions: ===
# System MAY NOT use an external SD card reader embedded into MP3 device. YOU MAY use an external SD card reader if your SD card reader is broken
# Use of any external libraries (specifically Arduino) that drive the hardware you intent to use. You must make the drivers from scratch for every part you make.

=== Permitted Action: ===
# You may use the internal buttons for controlling the MP3 player.
# You may use the 7-segment display and LEDs above buttons for debugging but not as the main menu.

MP3 Player

2017-12-10T23:25:39Z

Kammce: /* Permitted Action: */

== Project Summary ==
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.
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.
User would be able to use player controls (start/stop/pause) for playing MP3 songs and view the track information on a display.

== Block Diagram ==

[[File : Mp3_player_block_diagram.png|center|frame|]]

== Project Requirements ==
=== Non-Functional Requirements: ===
* Should be dynamic.
** As in, you should be able to add more songs and play them
* Should be accurate.
** Audio should not sound distorted,
** Audio should not sound slower or faster when running on your system.
* Should be user friendly.
** User should be able to figure out how to use the device without a user manual.
** Product must be packaged in some enclosure. No wires can be vision for the project.

=== Functional Requirements ===
# System must use the SJOne on board SD card to read MP3 audio files.
# System must communicate to an external MP3 decoder
# System must allow users to control the MP3 player (You may use the onboard buttons for this)
## User must be able to play and pause of song
## user must be able to select a song
# System must use an external display to show a menu providing the following information:
## Current playing song
## Information about current playing song
## Menu showing how to select a different song
## (Not all of the above need to be shown on the same display)
# System software must separated into tasks. EX: Display task, MP3 Read Task, Controller Task etc...
# System software must be thread safe always.
# System software must use OS structures and primitives where applicable.

=== Prohibited Actions: ===
# System MAY NOT use an external SD card reader embedded into MP3 device. YOU MAY use an external SD card reader if your SD card reader is broken
# Use of any external libraries (specifically Arduino) that drive the hardware you intent to use. You must make the drivers from scratch for every part you make.

=== Permitted Action: ===
# You may use the internal buttons for controlling the MP3 player.
# You may use the 7-segment display and LEDs above buttons for debugging but not as the main menu.

MP3 Player

2017-12-10T23:25:11Z

Kammce: /* Prohibited Actions: */

== Project Summary ==
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.
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.
User would be able to use player controls (start/stop/pause) for playing MP3 songs and view the track information on a display.

== Block Diagram ==

[[File : Mp3_player_block_diagram.png|center|frame|]]

== Project Requirements ==
=== Non-Functional Requirements: ===
* Should be dynamic.
** As in, you should be able to add more songs and play them
* Should be accurate.
** Audio should not sound distorted,
** Audio should not sound slower or faster when running on your system.
* Should be user friendly.
** User should be able to figure out how to use the device without a user manual.
** Product must be packaged in some enclosure. No wires can be vision for the project.

=== Functional Requirements ===
# System must use the SJOne on board SD card to read MP3 audio files.
# System must communicate to an external MP3 decoder
# System must allow users to control the MP3 player (You may use the onboard buttons for this)
## User must be able to play and pause of song
## user must be able to select a song
# System must use an external display to show a menu providing the following information:
## Current playing song
## Information about current playing song
## Menu showing how to select a different song
## (Not all of the above need to be shown on the same display)
# System software must separated into tasks. EX: Display task, MP3 Read Task, Controller Task etc...
# System software must be thread safe always.
# System software must use OS structures and primitives where applicable.

=== Prohibited Actions: ===
# System MAY NOT use an external SD card reader embedded into MP3 device. YOU MAY use an external SD card reader if your SD card reader is broken
# Use of any external libraries (specifically Arduino) that drive the hardware you intent to use. You must make the drivers from scratch for every part you make.

=== Permitted Action: ===
# You may use the internal buttons for controlling the MP3 player.
# You may use the 7-segment display and buttons for debugging but not as the main menu.

MP3 Player

2017-11-12T23:14:18Z

Kammce: /* Project Requirements */

== Project Summary ==
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.
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.
User would be able to use player controls (start/stop/pause) for playing MP3 songs and view the track information on a display.

== Block Diagram ==

[[File : Mp3_player_block_diagram.png|center|frame|]]

== Project Requirements ==
=== Non-Functional Requirements: ===
* Should be dynamic.
** As in, you should be able to add more songs and play them
* Should be accurate.
** Audio should not sound distorted,
** Audio should not sound slower or faster when running on your system.
* Should be user friendly.
** User should be able to figure out how to use the device without a user manual.
** Product must be packaged in some enclosure. No wires can be vision for the project.

=== Functional Requirements ===
# System must use the SJOne on board SD card to read MP3 audio files.
# System must communicate to an external MP3 decoder
# System must allow users to control the MP3 player (You may use the onboard buttons for this)
## User must be able to play and pause of song
## user must be able to select a song
# System must use an external display to show a menu providing the following information:
## Current playing song
## Information about current playing song
## Menu showing how to select a different song
## (Not all of the above need to be shown on the same display)
# System software must separated into tasks. EX: Display task, MP3 Read Task, Controller Task etc...
# System software must be thread safe always.
# System software must use OS structures and primitives where applicable.

=== Prohibited Actions: ===
# System MAY NOT use an external SD card reader embedded into MP3 device. YOU MAY use an external SD card reader if your SD card reader is broken
# ''Will add more things as they pop up ...''

=== Permitted Action: ===
# You may use the internal buttons for controlling the MP3 player.
# You may use the 7-segment display and buttons for debugging but not as the main menu.

MP3 Player

2017-11-12T23:12:46Z

Kammce: /* Project Requirements */

== Project Summary ==
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.
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.
User would be able to use player controls (start/stop/pause) for playing MP3 songs and view the track information on a display.

== Block Diagram ==

[[File : Mp3_player_block_diagram.png|center|frame|]]

== Project Requirements ==
=== Non-Functional Requirements: ===
* Should be dynamic.
** As in, you should be able to add more songs and play them
* Should be accurate.
** Audio should not sound distorted,
** Audio should not sound slower or faster when running on your system.
* Should be user friendly.
** User should be able to figure out how to use the device without a user manual.

=== Functional Requirements ===
# System must use the SJOne on board SD card to read MP3 audio files.
# System must communicate to an external MP3 decoder
# System must allow users to control the MP3 player (You may use the onboard buttons for this)
## User must be able to play and pause of song
## user must be able to select a song
# System must use an external display to show a menu providing the following information:
## Current playing song
## Information about current playing song
## Menu showing how to select a different song
## (Not all of the above need to be shown on the same display)
# System software must separated into tasks. EX: Display task, MP3 Read Task, Controller Task etc...
# System software must be thread safe always.
# System software must use OS structures and primitives where applicable.

=== Prohibited Actions: ===
# System MAY NOT use an external SD card reader embedded into MP3 device. YOU MAY use an external SD card reader if your SD card reader is broken
# ''Will add more things as they pop up ...''

=== Permitted Action: ===
# You may use the internal buttons for controlling the MP3 player.
# You may use the 7-segment display and buttons for debugging but not as the main menu.

CAN BUS Tutorial

2017-10-12T23:13:24Z

Kammce:

== CAN BUS ==

 This article is under construction 
 
CAN BUS (Controller Area Network) is a very deterministic BUS heavily used in the automotive industry. It is a half-duplex BUS, that operates using a pair of differential signals. Typically, the speed standards are 100K, 250K, 500K or 1Mbit.

CAN BUS may have several tens of controllers on the same BUS and you can typically go relatively long distances such as 10 meters without compromising the speed or reliability. The message id of each message can address other nodes on a CAN BUS (more on this later).

=== CAN BUS Frame ===
A CAN frame may contain 50-114 bits which includes data bits like message id, the real payload (0-8 bytes), and some CRC bytes. After the hardware captures the CAN frame, it stores it into a simpler frame that contains frame information, message id, and the data bytes.

A CAN frame may contain one of two message id types :
* 11-bit
* 29-bit

| Frame Information | Message ID | 0-8 bytes |
| RTR, Msg ID Type, Byte Count | 11 or 29-bit | 0-8 bytes |

* RTR : Remote transmission frame
*: This bit indicates to the destination that an empty message is being sent.
*: You can consider this "PING" or a signal to send something back to the source
* Message ID Type
*: This bit (when 1) indicates it is a 29-bit ID or else an 11-bit ID
* Data bytes
*: The payload can be zero bytes, or up to full 8 bytes in a CAN frame.

=== Message ID ===
A message ID of a CAN frame is very unique in the sense that it is used as a priority on the physical BUS. '''A lower message ID has higher priority''' since logical 0s are dominant and they override logical 1s on the BUS. This is a key feature of the CAN BUS because you can guarantee that your message will get across above everyone else if it has the highest priority.

Another property of the message id is that each node on a CAN bus MUST acknowledge a chosen message id for a message to be successful. If a message is not acknowledged, retransmissions will take place by the hardware, which can eventually lead to "BUS-OFF" state as given by the CAN specifications.

=== Transceiver ===
Unlike other BUSes that can be up and running without any external hardware, CAN BUS '''REQUIRES''' a voltage transceiver that converts logical Rx/Tx pins into a single differential pair wire that is hooked up on the CAN BUS.

 
== Multi-node CAN BUS ==
Before the CAN BUS is used in an application, it helps to know some basic characteristics of the BUS :
* No two nodes shall send the same message ID
*: Doing so will cause two nodes to cause collisions on the BUS, since arbitration will not take place.
* No two nodes shall acknowledge the same message ID
*: Doing so will cause two nodes to acknowledge the same packet.

So knowing the above requirements, there is a dilemma for us:
* How can two nodes send a message to another node using the same message id ?

=== Message ID Design ===
What we can do is split the message id into separate fields so each node on a CAN bus can address any other node:

| 4-bit destination id | 4-bit source id | 3-bit message id |

What we have done now is added the capability that multiple nodes can speak to each other, and whoever has the lowest source id has the highest priority on the CAN BUS. So suppose that we are a "lights controller" on a vehicle's CAN BUS, then we can specify the following standard :
* Lights Controller ID: 5
* Message ID : 1 = Lights command
* Message ID : 2 = Clear Faults

With this in mind, we would tell our CAN controller to accept the following range of all message ids:
| 0101 | xxxx | xxx |
Therefore, our CAN acceptance filter is 0x280 - 0x2FF. If we do this, anyone can send us a message, and no two nodes will send the same message id. Likewise, we can send a response message back to anyone using a unique message id.

 

== OBDII ==
OBDII standard uses CAN BUS to communicate to the ECU. You can connect a CAN controller to an OBDII port easily by using an [https://www.sparkfun.com/products/10087 OBDII to Serial] cable. Since this kind of cable doesn't convert the CAN voltage signals to logical signals that a microcontroller can understand, you would also need an MCP2561 based transceiver which would allow your controller to be interfaced to an OBDII port.

The block diagram would be as follows :
| Car's computer --> CAN BUS --> (OBDII Port) --> MCP2561 --> Your CAN controller |

 
== CAN on LPC17xx ==
LPC17xx or the '''SJ-One Board''' has two CAN controllers and the Sourceforge development package' projects contain the CAN driver. Therefore, you can connect to two separate CAN BUSes, however, some of the internal hardware is shared between the two CAN controllers. Note that a CAN controller needs to setup its filters such that it can generate ACKs and accept the chosen messages when another controller sends the specific CAN messages. The LPC17xx CAN allows you to setup your CAN acceptance filters in one of several ways :
* FullCAN message reception
* Standard (11-bit) ID list
* Standard ID range (low to high)
* Extended (29-bit) ID list
* Extended ID range (low to high)

Also note that the space for these filters are limited to 2Kb internal RAM, however, this is enough to setup 512 individual 29-bit addresses or 1024 standard message IDs. Generally, if you exhaust this space, you are doing something wrong or your CAN BUS protocol is badly designed.

=== LPC FullCAN ===
Using FullCAN is one of the ways to setup a CAN message acceptance filter, and you have to know the exact id of each message. The LPC FullCAN is a way for us to specify specific message IDs and these messages are stored straight to RAM without our software getting interrupted! This is a neat away to automatically accept and store messages without using CPU cycles. There exist a means to test if the HW has updated a specific message and you can even get interrupt notifications for up to first 64 FullCAN messages.

=== Hardware Filters ===
The hardware filters (apart from FullCAN) provide second means of accepting specific message ids. Furthermore, you can also specify a range, for example, you can program it to accept all messages from standard 11-bit id range 0x100 to 0x200. The CPU can or will get interrupted upon accepting a message, and then your software can queue or process the incoming message. The hardware filter also provide a way to setup 29-bit message id acceptance filter.

 

=== DBC ===
http://www.socialledge.com/sjsu/index.php?title=DBC_Format

== Resources ==
=== External Resources ===
* LPC2000 CAN BUS Appnote
*: [[File:CAN_AN10674.pdf]]
* Keil CAN BUS Primer
*: [[File:CAN_keil_primer_v2.pdf]]
* Microchip CAN BUS Appnote
*: [[File:CAN_microchip_appnote.pdf]]
* TI CAN Bus tutorial
*: [http://www.ti.com/lit/an/sloa101a/sloa101a.pdf CAN Bus]

Embedded System Tutorial UART

2017-09-27T03:05:14Z

Kammce:

== Introduction ==
The objective of this lesson is to understand UART, and use two boards and setup UART communication between them.

'''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.

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 :
[[File:uart_tutorial_frame.jpg|center|frame|UART Frame of 'A']]

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.

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.'''
* [https://www.youtube.com/watch?v=RU_NUPprx2Y UART Driver Video]

 

== UART Pins ==
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.

[[File:tutorial_uart_pinsel.png|center|Find RXD2 and TXD2 of UART2]]
 
[[File:tutorial_gpio_mux.png|center|Example MUX that we need to configure for a PIN selection]]

 

== Clock System & Timing ==
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.

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.

[[File:uart_tutorial_clock.jpg|center|frame|Example clock system of LPC17xx]]

== Hardware Design ==
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.

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.

== Software Driver ==
[[File:uart_tutorial_overview.jpg|center|frame|UART chapter summary]]

{|
|
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.

 
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.

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.

<syntaxhighlight lang="c">
void uart0_init(void)
{
LPC_SC->PCONP |= (1 << 3); // Enable power to UART0
LPC_SC->PCLKSEL0 &= ~(3 << 6);
LPC_SC->PCLKSEL0 |= (1 << 6); // Uart clock = CPU / 1

LPC_PINCON->PINSEL0 &= ~(0xF << 4); // Clear values
LPC_PINCON->PINSEL0 |= (0x5 << 4); // Set values for UART0 Rx/Tx

LPC_UART0->LCR = (1 << 7); // Enable DLAB
/* See the formula picture to get more info.
* Default values of fractional dividers simplifies the equation
* Warning: You need to set DLM/DLL correctly, but if divider is small enough, it will fit inside DLL
*/
LPC_UART0->DLM = 0;
LPC_UART0->DLL = CPU_CLOCK / (16 * 9600) + 0.5);

LPC_UART0->LCR = 3; // 8-bit data
}
</syntaxhighlight>
| [[File:uart_tutorial_dlab.jpg|center|frame|DLAB bit to access registers]]
[[File:uart_tutorial_formula.jpg|center|frame|Baud rate formula]]
|}

<syntaxhighlight lang="c">
char uart0_putchar(char out)
{
LPC_UART0->THR = out;
while(! (LPC_UART0->LSR & (1 << 6)));
return 1;
}
</syntaxhighlight>

 
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.
 

== Advanced Design ==
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.

== Assignment ==
* Assignment Outline
*: Form 2 people teams for this assignment.
*: Write a driver for UART2 or UART3
*: Do not use the pre-built driver or Uart2/3 class
*: Connect your UART to your partner's UART (to his board)
*: Prove that you can send/receive data across multiple boards.
*: Upload Logic Analyzer Screenshot for the UART Frame.
* Extra Credit:
*: 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.
* Steps
*: Locate the physical pins for a UART that is not already used by your board
*: Configure the PINSEL to use the pins for UART Rx/Tx
*: Initialize your UART at any baud rate
*: Write uart_putchar(char) and uart_getchar() functions
*: Interface your UART with someone else's board, and test the communication.