1. Overview 2. Hardware 3. Set up the Hardware: Line Scan Camera/Microcontroller Hardware Setup 4. Build the Code 5. Download/Debug/Run 6.Example Code Functions ImageCapture(); ReadADCChannel() Initialize the ADC Header File Definitions Initialize the GPIO Other Tutorials: This tutorial covers the details of obtaining data from the line scan camera on the Kinetis K40 using the TWR-K40X256-KIT evaluation board. General details of the line scan camera not related to the Kinetis can be found in the general Line Scan Camera Theory article. This tutorial will help students familiarize themselves with how to interface the camera with the microcontroller, how to configure GPIO pins to create clock signals and also how to utilize the microcontroller's ADC to read the data from the camera. Outside of control algorithms, configuring the camera is one of the more complex tasks necessary to create a Freescale Cup Vehicle. 1.  Overview In this exercise students will access the line scan camera, create a clock signal and create the initialization pulse which tells the camera to begin the exposure period. This tutorial will not describe line recognition or line following algorithms - these concepts are beyond its scope. Students will: Create the code using Codewarrior Build a project Download the code to the board connect the microcontroller to the camera. Run the program view the camera data, clock and Si pulse on an oscilloscope view the data from the camera in the CodeWarrior Debugger for verification purposes   To successfully complete this exercise, the following software and hardware are required: The K40 Tower card, TWR-K40x256 CodeWarrior for Microcontrollers Freescale Line Scan Camera Motor Board Tower Prototyping board Soldering Iron Solder Tower Elevators USB Cord 2. Hardware   Read the Line Scan Camera Overview article for general information on the camera, ADC, and GPIO microcontroller configuration settings. 3. Set up the Hardware: Line Scan Camera/Microcontroller Hardware Setup It is crucial for an engineer to have the proper test equipment and tools for the job. In this case, without an oscilloscope, students will not be able to verify whether the proper signals are being sent to the camera. 4. Build the Code If there is more than one project in your project view, make sure the proper project is the focus. The most reliable way to do this is to right click the project and choose Build Project as shown below. You can also go to the Project menu and choose the same command. If errors are encountered, look in the Problems view and resolve them. For now ignore any warnings. 5. Download/Debug/Run Download the code to your board, once this process is complete resume the project so that the code runs. If you want more information on how to complete this step see the download debug run section of the Kinetis Blinking Led tutorial. 6.Example Code What will happen: the function ImageCapture() is called in main.c with a pointer to the first element in the array. This function completes the processes necessary to capture images using the camera. To become more familiar with Pointers and Arrays - navigate to the C Programming Tutorial. Knowledge of Pointers and Arrays is a pre-requisite for understanding the Camera Code. Functions The camera code utilizes the following function: within main.c ImageCapture(&Line.RawCameraData[0]); is called to initiate the step of capturing an image into the first position of the array. ImageCapture(); from Camerainterface.c This function captures the images by creating the SI Pulse, and clock signals, capturing the data into an Array using the ADC features of the K40. It calls the function ReadADCChannel() at the proper time which then inputs data from the camera AO line. void ImageCapture(int * ImageData){//this is a pointer to a single character in memory   unsigned char i;   TAOS_SI_HIGH;   TAOS_EXPOSURE_DELAY;   TAOS_CLK_HIGH;   TAOS_EXPOSURE_DELAY;   TAOS_SI_LOW;   TAOS_EXPOSURE_DELAY;   ImageData[0] = (int)ReadADCChannel(19);// inputs data from camera (first pixel)   TAOS_CLK_LOW;   for(i=1;i<128;i++)   {   TAOS_EXPOSURE_DELAY;   TAOS_EXPOSURE_DELAY;   TAOS_CLK_HIGH;   TAOS_EXPOSURE_DELAY;   TAOS_EXPOSURE_DELAY;   ImageData[i] = (int)ReadADCChannel(19); // inputs data from camera (one pixel each time through loop)   TAOS_CLK_LOW;   }   TAOS_EXPOSURE_DELAY;   TAOS_EXPOSURE_DELAY;   TAOS_CLK_HIGH;   TAOS_EXPOSURE_DELAY;   TAOS_EXPOSURE_DELAY;   TAOS_CLK_LOW;  } ReadADCChannel() from readADC.c this function does the analog to digital conversion and returns a value between 0 and 255. It takes the proper ADC channel, in this case 19. Channel 19 corresponds to analog input pin ADC1_DM0 (see page 117 in the K40 Sub-Family Reference Manual). unsigned char ReadADCChannel(unsigned char Channel)   {   ADC1_SC1A = Channel;   while((ADC1_SC1A & ADC_SC1_COCO_MASK) == 0)   {   }   return ADC1_RA;    } Initialize the ADC Before utilizing the ADC it must be calibrated and initialized. The details for how to do this can be found in Chapter 19 Using Peripheral Delay Block (PDB) to Schedule Analog to Digital Converter (ADC) Conversions of the Kinetis Peripheral Module Quick Reference manual. The PDB portions of the code have been removed for the Cup Car Demo Code. Header File Definitions from k40_TOWER_BOARD_SUPPORT.h The following code enables the GPIO on the two pins: #define TAOS_CLK_LOC (1<<28) #define TAOS_SI_LOC (1<<18) Initialize the GPIO From K40_TOWER_BOARD_SUPPORT.c The InitK40GPIO Function sets up the ports for use: Relevant code SIM_SCGC5 = SIM_SCGC5_PORTA_MASK | SIM_SCGC5_PORTB_MASK | SIM_SCGC5_PORTC_MASK | SIM_SCGC5_PORTD_MASK | SIM_SCGC5_PORTE_MASK; //CLK and SI signal PORTC_PCR18 = PORT_PCR_MUX(1) | PORT_PCR_DSE_MASK; PORTE_PCR28 = PORT_PCR_MUX(1) | PORT_PCR_DSE_MASK; //Make Sure the GPIO is setup to be an output GPIOC_PDDR |= LED_E1_LOC | LED_E2_LOC | LED_E3_LOC | TAOS_SI_LOC; GPIOE_PDDR |= TAOS_CLK_LOC; GPIOB_PDDR |= LED_E4_LOC; Other Tutorials: K40:Blinking LED Tutorial K40:Drive DC Motor Tutorial K40:Turning a Servo Tutorial   

Getting Started with the NXP CUP These pages help you with the question of how to achieve the goal of creating an autonomous vehicle that quickly navigates around a track (timed race) and solves precision tasks (Figure 8, Speed limit zone, Obstacle avoidance) What is a Microcontroller? For information on what a microcontroller is head to the microcontrollers article. Getting Started - Learn to Program a microcontroller First off, you are going to need to know C programming. For a crash-course head to c-programming-for-embedded-systems. The classic first application to learn how to program a microcontroller is to get through the process of Blinking an LED. This wiki contains a tutorial for each of the Cup microprocessors which simplifies the process of setting up the evaluation board, installing the Integrated Development Environment, and programming the board with a simple set of software which blinks a LED. The Blink a LED tutorial is the first of 4 tutorials designed to familiarize students with the process of designing a cup car. These four tutorials will introduce students to many of the fundamentals of robotics, the software used to control the locomotion and sensors on an autonomous line following vehicle, and provide example code which help simplify the process of creating a competitive entry in the NXP CUP. Here is an outline of the Basic Microcontroller Programming Tutorial: Read the microcontroller article Choose a microcontroller Set up the development environment Set up the microcontroller evaluation board Program A LED move to the next tutorial… Course Material from the NXP CUP professors and supporters: Thanks to our professors and NXP CUP supporters we created an exclusive starter kit. It includes lecture material, information on the car, useful tips on the board etc. Download the file below and dive into a huge support portfolio! ARC Ingenierie Files - The Champions Board! ARC Ingenierie has been very generous in providing us with their PCB layout and Gerber files to produce your own NXP CUP board. They also provided sample code and drivers plus instructions (in French) to get you started. How cool is that?! Many thanks to ARC, this is much appreciated! Download the files below. If you want to build your own board, please contact us. When do so please keep in mind to give credit to ARC university. All boards should have "HE-ARC Ingenierie" inscription.   Further support links: Information on Line Scan Camera Use The Book of Eli - Microcontrollers, robotics and warp drives Microcontrollers MCU 101 - C Programming for Embedded Systems NXP CUP Shield for the FRDM KL25Z

This past Tuesday June 25th, 2013, the UNICAMP E-Racing compete against 19 teams and won the first place with a score of 985 points of a total of 1000. The car used an electric motor of 120 V and a chassis that weighted 250 kg (551.2 lbs). That allows the car with a charging time of 2 hours to be driving for 25 km (15.5 miles) and race up to speeds of 170 km/h (105.6 mph). Check out this video of the car: The official results: http://www.sae.org/images/cds/selfservice/372162833_FSAE_EV_2013%20result.pdf

Hardware Servos are specialized dc motors geared to produced high-torques and set at specific angles vs rotating continously. The ability to position the servo at a specific angle over and over makes them ideal for robotics, radio controlled car and other various applications. A typical servo will have range of motion from 180-270 degrees. Most modern servos have a three wire interface, red (V+), black (ground), and white (control). To control a servo you must send it a variable length commands (pulse) in 20ms increments. This type of control is called Pulse Width Modulation. Pulse Width Modulation is a square wave with a set period. By changing the width controlling the proportion of on versus off time, you can obtain a digital ratio from 0-100%. That ratio of on versus off time is called the duty cycle. A microcontroller generates a PWM signal using a timer. The time from the beginning of one sequence to the next is called the period. The main timer registers include: Counter, Modulo, Count Initialization Value, Channel Value, FTM Status & Control, and Channel Status & Control. The Counter will count up from the Count Initialization Value and reset after reaching Modulo. One tradeoff of the design is the Modulo value we set. It represents the count value of a full duty cycle and also the resolution of our servo control. Setting a higher Modulo value allows for more precise variation in the servo, i.e. more accurate steering. The downside is that a higher value requires more time per cycle. It is necessary to configure a timer module for the drive motor separate from the servo because they each require different clock frequencies. Another tradeoff of pulse width modulation is whether it is edge-aligned or center-aligned. Edge-aligned PWM, where the channel is cleared at counter overflow and set at channel match, is simpler to implement in hardware. Center-aligned PWM, where the counter counts up and down, is more difficult to implement but does not give as much noise interference when the channel matches. Servos have 3 wires coming out of them: Ground: Black, Brown Power: Red PWM Signal: White, Yellow, Orange Spec Sheet for Servo used in Freescale Cup Futaba-S-3010 Creating the PWM Signal Much of what is needed to create this signal is discussed in the Motor Control tutorial. Click here to review how to configure a PWM signal on your microcontroller. The same microcontroller configuration utilized to drive a motor can be modified slightly to rotate the arm of a servo. Since the Servo and motor require different clock frequencies, it is necessary to configure a timer module for the servo separate from the motor. Freescale Cup participants will configure the timer modules to output signals that control a steering Servo via varying the Duty Cycle of a PWM signal. Microcontroller Reference Manual: Timer Information You will find high level information about Timer usage in several different areas of a reference manual. See the reference-manual article for more general information. Relevant Chapters: Introduction: Timer modules - lists the memory map and register definitions for the GPIO System Modules: System Integration Modules (SIM) - provides system control and chip configuration registers Chip Configuration: Timers Signal Multiplexing: Port control and interrupts Methods of controlling steering angles Construct a look-up table One way of controlling the steering angles is to construct a look-up table. The input of the look-up table can be the shift distance(in pixels) from the center, and the output could be the steering angles. The look-up table can be put into an excel file. So when you want to use it, just copy and paste the table into your code file. Here is an example of how to construct a look-up table. 1. Set up basic parameters of your car: height of camera(h), angle of camera(theta), velocity of car(v), servo delay(s).. 2. Draw a graph to help you develop a function between your input parameters and your output steering angles 3. Put all paraments into excel. So if you want to change any parameters in the future it will be very convenient. 4. Copy and paste look-up table into code file Note: depending on how you define your parameters, the look-up table may not work as well as you expected. Experiments show that the look-up table works well when the shift distance is small( small turns) and the car tends to go off track when the shift distance is big(sharp turns). Poportional Control (P Control) You can map your servo angle based directly on your line location. Take the derivative of the camera signal and use the derivative peaks as the edges of the line. Take the location of each peak and subtract them from each other to get the line width. Taking the min line peak plus line width will give you the location of the line. Now take that location and map it to your servo. We made Camera.Lock = loc and using this we made Motor.ServoAngle = Camera.Lock»1; This made our line location map directly to our servo and it seemed to work well for us. Additional Theory Training Resources Freescale Motor Control Tutorial Freescale Lecture 1: Introduction and Motor Basics Freescale Lecture 2: Pulse Width Modulaiton Freescale Lecture 3: Control Design Freesacle Lecture 4: Speed and Position Freescale Lecture 5: MPC5607B Overview

MathWorks is a proud global sponsor of The NXP Cup If you are a member of a NXP Cup team, you have access to a complimentary Software License for MATLAB / Simulink. Visit the NXP Cup - MathWorks Deutschland website to learn more about the Software offering.  Examples for using Simulink in the NXP Cup are packaged with the Simulink Coder Support Package for  FRDM-KL25Z available from the Hardware Support Page.  Additional examples for reading and analyzing live data from the Line Scan Camera are available in the NXP Cup Companion App available on the MATLAB File Exchange.  Additionally, there is an example which uses the Simulink Coder product from MathWorks to target the FRDM-KL25Z. Feel free to use the forum on MATLAB Answers or here below to ask your questions about MATLAB use with The NXP Cup.  You can also email [email protected] with any questions.

Freescale india and CEDT, IISc organised Smart car race india 2010 winner team from NIT,Surat. Students: Maulik Gandhi , Rikil Shah and Samir Sirohi.

The first step of starting your TFC project is to get to know your microcontroller. This article serves you as an introduction of Qorivva MPC560xB microcontroller. Qorivva MPC5604B Summary The Qorivva MPC560xB/C/D family of 32-bit microcontrollers (MCUs) includes the latest in integrated devices for automotive electronics applications. These scalable Power Architecture® devices are supported by an enablement ecosystem that includes software drivers, operating systems and configuration code to help you quickly implement your designs.  For the Freescale Cup Challenge, we have provided Tutorials, example code and projects which are based on the trk-mpc5604b StarterTRAK evaluation board. Which Chip do you have? The chipset mounted on the boards for the Freescale Cup can vary. Always validate your chipset to know it's full capabilities. MPC560xB Product Information Page Difference's At-a-Glance: 5604B = 512MB Flash; no DMA 5606B = 1MB Flash; Has 16-Channel DMA 5607B = 1.5Mb Flash; Has 16-Channel DMA Getting Started Presentation Getting Started with MPC5600B.pptx (2Mb) Important Resources: e200z0 Core Reference Manual TRK-MPC5604B User's Manual TRK-MPC5604BQuick Reference Guide TRK-MPC5604B Schematics Reference manual Freescale's Qorivva MPC560xB Page Power.Org

1. Overview   This article is the umbrella entry point for a series of automotive embedded workshops built on the FRDM-A-S32K3xx microcontroller family. It groups together five hands-on modules — Lights, Brakes, Steering, Comfort, and Transmission — each demonstrating a different real-world automotive function that a modern Body Control Module (BCM), Chassis ECU, or Powertrain ECU would implement in production vehicles. All five modules share the same educational philosophy: they take a simple, low-risk hardware setup (FRDM board + FRDM-K64 Click Shield + a few MikroE Click modules) and use it to teach the core embedded concepts that underlie automotive software: analog and digital signal acquisition, real-time processing, actuator control, and safety-aware system design. Together they cover the most common peripherals of the S32K3 family — ADC, GPIO, PWM, FlexIO, LPI2C, eMIOS — and expose students to the same tool-chain used by NXP customers: S32 Design Studio 3.6.5, the S32K3 Real-Time Drivers (RTD), the Application Code Hub (ACH), and the underlying Automotive Software Package. Learning philosophy — Eat-Sleep-Code-Repeat The whole workshop series is designed around the Eat-Sleep-Code-Repeat initiative — a learn-by-doing culture where students continuously iterate on real hardware, break things, fix them, refactor, and re-flash until the concepts stick. Every module is small enough to be completed in one lab session, yet rich enough to leave room for extensions (state machines, filtering, CAN networking, closed-loop control, safety fall-backs). Concepts covered across the series Analog sensing: potentiometers, force sensors, resistor-ladder buttons → ADC conversion, scaling, debouncing. Digital I/O: GPIO input handling (buttons, switches), GPIO output sequencing (stepper coils). Actuation: PWM-based motor speed control (DC motors, fans), PWM-based servo positioning, WS2812 LED driving through FlexIO. Communication: I²C configuration of external PWM drivers (Servo Click / PCA9685). Control patterns: continuous mapping, threshold-based decisions, state machines, safety interlocks. Automotive concepts: Body Control Module (BCM) behavior, functional safety (ISO 26262), fail-safe defaults, redundancy considerations. What this article gives you Each of the next five sections provides a short summary of one module — what it demonstrates, which hardware it uses, which peripherals are involved, and a direct link to the full detailed workshop article. Students should read this page first to understand where each module fits in the bigger picture, then dive into the individual articles for step-by-step instructions.   2. Vehicle Lighting Control   The Lights module implements a simplified automotive lighting system that mirrors the behavior of a real vehicle Body Control Module. Six buttons on the Analog Key Click command different lighting functions — low beam, high beam, left/right turn signals, brake lights, and hazard lights — all displayed in real time on a 16-LED 4x4 RGB Click matrix. Key learning points Multi-button decoding on a single ADC channel (resistor-ladder input). Software debouncing and command decoding. Driving WS2812 LEDs through FlexIO (precise sub-microsecond timing without CPU load). BCM safety interlocks: high beam requires low beam ON; hazards synchronize left + right turn signals; high beam state preserved between blink cycles. Peripherals used: ADC0, FlexIO, GPIO. Boards: FRDM-A-S32K312 or FRDM-A-S32K344. Reference project:Automotive Lighting Control Using FRDM-A-S32K3XX Microcontrollers - NXP Community Demo: Vehicle Lighting Control on FRDM-A-S32K344 Automotive relevance: lighting is one of the most safety-critical driver-visibility functions in modern vehicles — this module teaches how a real BCM manages dependencies, blinking patterns, and fail-safe defaults.   3. Brake Status Monitoring   The Brakes module implements a simplified brake status monitoring system where a Force Click sensor simulates the driver's brake-pedal pressure. As pressure increases, the ADC value grows and the application progressively lights up the 4x4 RGB Click LEDs in green → yellow → orange → red, providing immediate visual feedback of the current braking level. Key learning points Continuous analog sensor acquisition through ADC. Threshold-based decision logic: converting a raw ADC value into discrete alert levels. Driving the RGB LED matrix through FlexIO to reflect the current system state. Introduction to real-time monitoring and safety-oriented visual feedback. Peripherals used: ADC0, FlexIO. Boards: FRDM-A-S32K312 or FRDM-A-S32K344. Reference project: Automotive Brake Control Using FRDM-A-S32K3XX Microcontrollers - NXP Community Demo: Brake Status Monitoring on FRDM-A-S32K344 Automotive relevance: brake status is a core input for many downstream ECUs (ABS, ESC, hill-hold, brake lights). This module teaches the fundamental pattern of sensor → threshold → visual/electrical output that appears everywhere in automotive software.   4. Assisted Steering Control   The Steering module demonstrates a simplified Electric Power Steering (EPS) / steer-by-wire concept. A POT Click potentiometer simulates the steering-wheel angle; the MCU reads it through ADC, scales it linearly, and generates a PWM command through the Servo Click (configured over I²C) that positions a Micro Servo SG 180° in real time. Key learning points Analog input scaling and linear mapping (ADC range → servo angle range). Using an external PWM controller configured over I²C (LPI2C1) — a common embedded pattern that offloads timing-critical work. Working with the Output Enable (OE) pin for safe-stop behavior. Understanding the actuation chain sensor → MCU → PWM → actuator. Peripherals used: ADC0, LPI2C1, GPIO. Boards: FRDM-A-S32K312 or FRDM-A-S32K344. Reference projects: Automotive Steering Control Using FRDM-A-S32K3XX Microcontrollers - NXP Community Demo: PWM-Based Steering Control on FRDM-A-S32K344 Automotive relevance: steering is a strictly safety-relevant function (ISO 26262 typically classifies it as ASIL C or D). This module introduces the concepts behind EPS and steer-by-wire and lays the foundation for future work with redundant sensors and fault detection.   5. Vehicle Comfort Control   The Comfort module implements two independent comfort functions typical of vehicle body electronics: cabin cooling (a 5 V fan driven through a DC Motor 2 Click using PWM) and electric window control (a NEMA17 stepper motor driven through an H-Bridge Click using full-step GPIO sequencing). On-board push-buttons act as the driver's HVAC and window switches. Key learning points PWM motor speed control (fan simulation). Stepper motor full-step sequencing (A → B → C → D and reverse) through four GPIO outputs. Handling multiple independent actuators from a single MCU without blocking. Introduction to window anti-pinch and other real BCM safety concepts. Peripherals used: GPIO, eMIOS (PWM). Boards: FRDM-A-S32K344 (only). Reference project: Automotive Comfort Control Using FRDM-A-S32K344 Microcontrollers - NXP Community Demo: Vehicle Comfort Control on FRDM-A-S32K344 Automotive relevance: comfort systems (HVAC, windows, mirrors, seats) form a huge share of modern body electronics. This module shows how one ECU can coordinate multiple actuators of different types (rotational-speed and positional) using the same S32K3 platform.   6. Transmission Control   The Transmission module demonstrates a continuous, proportional transmission control concept. A POT Click potentiometer represents the driver's acceleration command; the MCU samples it, applies linear scaling, and simultaneously drives two actuators: a Servo Click + Micro Servo that simulates the transmission selector position, and a DC Motor 2 Click + DC motor whose speed reflects the powertrain response. Key learning points Dual-actuator control from a single analog input (one MCU commands both servo angle and DC motor speed in parallel). Linear signal mapping to two different PWM ranges simultaneously. Combining I²C-configured PWM (Servo Click) and eMIOS-generated PWM (DC Motor 2 Click) in the same application. Understanding continuous vs. discrete control and how continuous mapping better mirrors real automotive behavior. Peripherals used: ADC0, LPI2C1, eMIOS. Boards: FRDM-A-S32K344 (only). Reference project: Automotive Transmission Control Using FRDM-A-S32K344 Microcontrollers - NXP Community Demo: Transmission Control on FRDM-A-S32K344 Automotive relevance: transmission control is part of the powertrain domain and requires deterministic response and safety-aware design. This module introduces the concepts and prepares students for more advanced topics such as closed-loop control, transmission-mode logic (P/R/N/D), and CAN networking with the engine ECU.   7. Conclusion   Together, these five modules give students a complete tour of what a modern Body Control Module, Chassis ECU, and Powertrain ECU actually do in a vehicle — from reading sensors and buttons, through processing and safety interlocks, to driving lights, motors, and actuators. Each module can be studied independently, but the real value emerges when they are viewed as pieces of one coherent picture: the same MCU family (S32K3), the same tool-chain (S32 Design Studio + Application Code Hub), the same hardware base (FRDM-A-S32Kxxx + FRDM-K64 Click Shield + MikroE Click modules), applied to five different automotive domains. The series is intentionally aligned with the Eat-Sleep-Code-Repeat philosophy: start with a working example, then experiment — add filtering, replace polling with interrupts, introduce a state machine, add CAN communication, or refactor for functional safety. Every extension is a step closer to the way production automotive software is actually written. Recommended learning path: Lights — simplest, teaches ADC, FlexIO and BCM logic. Brakes — introduces continuous sensor thresholds. Steering — adds I²C-controlled PWM and actuator positioning. Comfort — multi-actuator, dual-technology control (PWM + stepper). Transmission — combines everything into a proportional, dual-actuator system.   If you have questions, suggestions for improvement, or ideas for new modules that could extend this series, please leave a comment below — feedback from students and instructors is what keeps the workshops relevant and up to date.  

1. Overview   This module demonstrates how to implement a steering control system using Pulse Width Modulation (PWM) on NXP S32K3 microcontrollers. The application reads an analog input from a potentiometer (simulating a steering wheel) and converts it into a servo motor position. As the input changes, the servo motor reacts in real time, mimicking how steering systems work in modern vehicles. This example is based on Application Code Hub demonstrations for: PWM-Based Steering Control for FRDM-A-S32K344 PWM-Based Steering Control for FRDM-A-S32K312 In this workshop, a POT Click simulates the steering wheel position. When the student rotates it, an analog voltage proportional to the angle is read by the MCU through the ADC, scaled in software, and converted into a PWM duty cycle. The PWM is generated by the Servo Click (configured by the MCU over I²C) and drives a Micro Servo motor SG 180°, whose angle tracks the potentiometer in real time. Beyond the technical implementation, the course serves as a foundation for the Eat-Sleep-Code-Repeat learning initiative, encouraging a hands-on approach where students continuously learn, develop, test, and improve automotive embedded applications using real hardware and practical examples.   2. Learning Scope   After completing this course, participants should be able to:   Understand a basic steering control system and the ideas behind EPS and steer-by-wire. Use the POT Click as a simulated steering-wheel input. Acquire analog values (0–3.3 V) using the ADC and understand analog-to-digital conversion. Perform signal scaling from the ADC range to a servo angle / PWM duty cycle. Generate PWM signals to drive a servo motor. Configure the Servo Click over I²C using the OE (Output Enable) pin. Recognize the actuation data flow: sensor input → MCU processing → PWM actuation. Import, build, flash, and debug an ACH project in S32 Design Studio 3.6.5. Understand why steering functions are relevant for functional safety. 3. System Architecture   The three elements capture exactly the basic idea of the system in the demo: Input: Potentiometer (POT Click simulates the steering-wheel position) Processing: S32K3 MCU (reads the ADC, scales the value, commands the actuator) Output: Servo motor controlled via PWM (Micro Servo SG 180°) This matches the classic flow of an embedded actuation system: sensor → processing → actuator. Functional Flow The system operates continuously as follows: The potentiometer generates an analog voltage based on its position The ADC converts this voltage into a digital value The application scales this value into a steering angle The system generates a PWM signal based on the angle The servo motor moves accordingly This loop runs continuously to ensure real-time control. Steering Monitoring Application Architecture 4. Key Concepts   4.1 ADC (Analog-to-Digital Converter) The POT Click outputs 0–3.3 V depending on the wiper position. The ADC samples this voltage at regular intervals and quantizes it into a digital code (a 12-bit ADC produces values between 0 and 4095). The further the potentiometer is turned, the higher (or lower) the digital sample. ADC acquisition is the foundation of automotive sensing — used for torque, throttle, battery voltage, and many others. 4.2 Signal Scaling — From ADC to Servo Angle The ADC range (for example 0–4095) and the servo range (0°–180°, expressed as a PWM duty cycle) are different. The application performs a linear mapping so that one end of the potentiometer corresponds to one steering extreme and the other end to the opposite. This is the same scaling used in real EPS systems, where a hardware reading is converted into a normalized control command. 4.3 PWM — Pulse-Width Modulation and Servo Control PWM switches a digital output on and off at a fixed frequency, varying the duty cycle (the fraction of time the signal is high). A hobby servo such as the SG 180° interprets this duty cycle as a position command. In this demo, the PWM is not generated by the MCU itself but by the Servo Click's dedicated PWM controller, which the MCU configures over I²C — a typical embedded pattern that offloads time-critical signal generation and keeps the CPU free for application logic. 4.4 I²C — Configuring the Servo Click I²C — Inter-Integrated Circuit is a two-wire serial bus made of SDA (data) and SCL (clock). The S32K3 uses LPI2C1 on PTC6 (SDA) and PTC7 (SCL) to configure the Servo Click — PWM frequency, channel, and duty cycle. The OE — Output Enable pin on PTB17 is an additional control line that enables or disables the PWM outputs without reconfiguring the chip, which is also useful for a quick "safe stop" behavior. 4.5 POT Click as Steering Wheel The POT Click is a simplified, safe stand-in for a real steering sensor. The student rotates it by hand, the voltage changes, the MCU reads it through the ADC, scales it, and the servo reacts. 4.6 Data Flow at a Glance Physical rotation → analog voltage → ADC sample → scaled command (angle / duty cycle) → I²C configuration of the Servo Click → PWM signal → servo angle. This direct chain from the student's hand to the servo shaft is the main educational value of the demo. 5. Hardware and Software Setup   Required Hardware Component Image Purpose FRDM-A-S32K312 Alternative MCU platform used to run the steering application and process steering inputs. FRDM-A-S32K344 Alternative MCU platform used to run the steering application and control connected peripherals. FRDM-K64 Click Shield mikroBUS expansion board used to connect Click modules to the FRDM platform. Servo Click PWM driver board used to control the servo motor position. POT Click   Potentiometer module used to simulate steering wheel input. Micro Servo SG 180°                     Actuator used to convert control signals into steering movement. USB-C / 12 V supply — Provides power and enables programming and debugging of the system.   The example applications demonstrate how these peripherals are connected to the MCU pins and used to simulate steering wheel input and actuator control.   Steering Control Monitoring on FRDM-A-S32K312 Steering Control Monitoring on FRDM-A-S32K344       Software Environment S32 Design Studio IDE S32K3 Automotive Software Package Application Code Hub project import PWM-Based Steering Control for FRDM-A-S32K344 PWM-Based Steering Control for FRDM-A-S32K312 6. Implementation Guide   Step Action Sub-steps Expected Result 1 Import the Project Open S32 Design Studio Select “Import project from Application Code Hub” Search for the steering demo Use the GitHub link for automatic configuration Select main branch Import project Project successfully appears in workspace 2 Build the Application Right-click project Select “Update Code and Build Project” Confirm SDK component management Build completes with no errors and generates .elf file 3 Connect Hardware Connect USB cable (and 12V supply for S32K312) Attach click boards Verify wiring Board is powered and detected by IDE 4 Flash and Run Open Debug Configurations Select “debug_flash_pemicro” Start debugging Application runs continuously 5 Functional Validation Rotate the potentiometer Observe servo movement Servo follows potentiometer position in real time   7. Signal Behavior and Control Logic     Figure: Steering control signal mapping. The 12-bit ADC value (0–4095) is linearly mapped to a servo angle (0°–180°) and a matching PWM duty cycle (1.0–2.0 ms), with reference points at Left, Center and Right. At startup the servo moves to the neutral position; during operation, any input change produces an immediate, proportional reaction — implementing a basic steer-by-wire behavior.   8. Troubleshooting   Issue Possible Actions Board Not Detected Check USB cable and drivers Verify debugger connection Restart IDE No Servo Movement Verify PWM configuration Check servo wiring Ensure correct power supply Incorrect Behavior Check ADC configuration Validate scaling function Ensure PWM duty cycle mapping is correct Unstable Movement Add signal filtering Check power stability   9. Extending the Application   The basic implementation can be extended in several ways: Steering Range Control Restrict or extend the actuator's range of motion Define software-based limits to protect the mechanics Input Direction Inversion Reverse how the actuator responds to the input Useful for left-hand vs. right-hand drive calibration Noise Filtering Apply software filtering to stabilize readings Avoid jitter near the center position Scaling Logic Exploration Identify and analyze how the input is mapped to the output Connect software math with hardware behavior Fault-Handling Behavior Add a mechanism that reacts to a detected fault Transition the system into a safer state State Machine Implementation A more advanced approach is to implement a state machine: Idle Active Fault 10. Safety Context   This example reflects key automotive principles: Continuous monitoring of driver input Immediate response to control signals Reliable actuator control In real systems: Redundancy is required Fault detection mechanisms are implemented Systems must comply with ISO 26262 (functional safety standard) Steer-by-wire systems require high reliability since there is no direct mechanical link. 11. Conclusion   This module demonstrates how a simple embedded system can implement steering control using ADC input and PWM output. It shows how: Analog input is acquired Data is processed in real time Actuators are controlled using PWM   Result on FRDM-A-S32K312 Result on FRDM-A-S32K344   The course provides a strong foundation for more advanced systems, including filtering, state machines, and safety-oriented designs.

The course serves as a foundation for the Eat-Sleep-Code-Repeat learning initiative, encouraging a hands-on approach where students continuously learn, develop, test, and improve automotive embedded applications using real hardware and practical examples.

The course serves as a foundation for the Eat-Sleep-Code-Repeat learning initiative, encouraging a hands-on approach where students continuously learn, develop, test, and improve automotive embedded applications using real hardware and practical examples.

The course serves as a foundation for the Eat-Sleep-Code-Repeat learning initiative, encouraging a hands-on approach where students continuously learn, develop, test, and improve automotive embedded applications using real hardware and practical examples.

1. Overview   This module demonstrates how to implement a vehicle lighting control system using analog input acquisition and FlexIO-based LED driving on NXP S32K3 microcontrollers. The application reads analog inputs from the Analog Key Click module (six push-buttons, each generating a distinct voltage level) and converts them into commands that drive a 4x4 RGB LED matrix. Each button press activates a specific lighting function — low beam, high beam, turn signals, brake lights, or hazard lights — while safety interlocks and blinking patterns run continuously in the background, mimicking how a real automotive Body Control Module (BCM) manages vehicle lighting. This example is based on Application Code Hub demonstrations for: Vehicle Lighting Control for Daylight and Hazard Signals on FRDM-A-S32K344 Vehicle Lighting Control for Daylight and Hazard Signals on FRDM-A-S32K312 In this workshop, the Analog Key Click simulates six vehicle lighting controls. When the student presses a button, an analog voltage proportional to the pressed key is read by the MCU through the ADC (with software debouncing), decoded into a specific lighting command, and translated into an RGB pattern generated by the FlexIO peripheral. The 4x4 RGB Click then displays the corresponding automotive lighting behavior in real time — warm white for low beams, cool white for high beams, blinking amber for turn signals and hazards, and red for brake lights. Beyond the technical implementation, the course serves as a foundation for the Eat-Sleep-Code-Repeat learning initiative, encouraging a hands-on approach where students continuously learn, develop, test, and improve automotive embedded applications using real hardware and practical examples.   2. Learning Scope   After completing this course, participants should be able to:   Understand a basic vehicle lighting control system and the ideas behind an automotive Body Control Module (BCM). Use the Analog Key Click as a simulated multi-button user interface (six inputs on a single analog line). Acquire analog values (0–3.3 V) using the ADC and understand how multiple buttons share one channel through voltage division. Perform software debouncing and decode which button was pressed based on ADC value ranges. Drive an RGB LED matrix using the FlexIO peripheral, generating precise timing for WS2812-style LEDs. Implement safety interlocks between lighting functions (e.g., high beam requires low beam ON). Implement continuous background patterns such as blinking turn signals and synchronized hazards. Recognize the actuation data flow: analog input → ADC → command decoding → FlexIO LED output. Import, build, flash, and debug an ACH project in S32 Design Studio 3.6.5. Understand why lighting functions are relevant for automotive safety and driver visibility. 3. System Architecture   The three elements capture exactly the basic idea of the system in the demo: Input: Analog Key Click (six buttons T1–T6, each generating a distinct analog voltage level) Processing: S32K3 MCU (reads the ADC, decodes the button, applies BCM logic, updates the LED state) Output: 4x4 RGB Click (16-LED matrix driven by FlexIO to display lighting patterns) This matches the classic flow of an embedded body-control system: sensor → processing → actuator. Functional Flow The system operates continuously as follows: The user presses a button on the Analog Key Click (T1–T6) Each button generates a distinct analog voltage on the shared output line The ADC samples the voltage and converts it into a digital value The application decodes which button was pressed (with debouncing) The BCM logic applies interlocks and dependencies (e.g., high beam requires low beam) The FlexIO peripheral drives the RGB Click LEDs with the corresponding color pattern This loop runs continuously to ensure real-time lighting control, with blinking patterns and safety interlocks maintained in the background. Vehicle Lighting Control Application Architecture    4. Key Concepts   4.1 ADC (Analog-to-Digital Converter) The Analog Key Click outputs 0–3.3 V on a single analog line, with each button generating a specific voltage step. The ADC samples this voltage on ADC0_P0 (pin PTD1) at regular intervals and quantizes it into a digital code (a 12-bit ADC produces values between 0 and 4095). Each button corresponds to a specific value range, allowing six digital inputs to be read through a single ADC channel. ADC acquisition is the foundation of automotive sensing — used for switches, buttons, sensors, and many others. 4.2 Analog Multi-Button Decoding Instead of using six separate GPIO pins, the Analog Key Click uses a resistor ladder that produces a different voltage for each button press. The application performs software debouncing (multiple ADC samples must agree before a press is confirmed) and then compares the ADC value against predefined thresholds to identify which button (T1–T6) was pressed. This technique is common in automotive steering-wheel controls, where many buttons share a single analog line to save wiring and pins. 4.3 FlexIO — Driving the RGB Click LEDs FlexIO is a highly flexible peripheral on S32K3 that can emulate serial protocols like WS2812/NeoPixel. The RGB Click uses individually addressable LEDs that require precise timing (~800 kHz with strict pulse widths). FlexIO on PTA13 (FlexIO_D8) generates this waveform in hardware, without loading the CPU. Each of the 16 LEDs receives its color data through a serial stream, allowing independent control of color and brightness per LED. 4.4 RGB LED Mapping and Lighting Zones The 16 LEDs of the RGB Click are logically grouped into automotive lighting zones: LEDs 13, 14 → Low Beam Headlights (warm white) LEDs 8, 9, 10, 11 → High Beam Headlights (cool white) LEDs 0, 12 → Left Turn Signal (blinking amber) LEDs 3, 15 → Right Turn Signal (blinking amber) LEDs 1, 2, 5, 6 → Brake Lights (red) LEDs 0, 3, 12, 15 → Hazard Lights (synchronized blinking amber) 4.5 BCM Safety Interlocks and State Dependencies The application implements safety logic typical of a real Body Control Module: high beam can only be activated when low beam is already ON; turning OFF the low beam automatically disables the high beam; hazard lights synchronize left and right turn signals simultaneously; high beam state is preserved during hazard blinking and restored between cycles. These interlocks illustrate how real automotive lighting logic prevents unsafe combinations and preserves driver intent. 4.6 Data Flow at a Glance Button press → analog voltage on shared line → ADC sample → software debouncing → button decoding → BCM logic (interlocks + dependencies) → FlexIO WS2812 output stream → RGB LED color update. This direct chain from the student's finger to the LEDs is the main educational value of the demo. 5. Hardware and Software Setup   Required Hardware Component Image Purpose FRDM-A-S32K312 Alternative MCU platform used to run the lighting application and process user inputs. FRDM-A-S32K344 Alternative MCU platform used to run the lighting application and control connected peripherals. FRDM-K64 Click Shield mikroBUS expansion board used to connect Click modules to the FRDM platform. Analog Key Click Six-button analog module used to simulate the vehicle lighting controls (headlights, indicators, brakes, hazards). 4x4 RGB Click 16-LED RGB matrix used to display the automotive lighting patterns in real time. USB-C / 12 V supply — Provides power and enables programming and debugging of the system through a single USB-C connection.   The example applications demonstrate how these peripherals are connected to the MCU pins and used to simulate a complete vehicle lighting control system.   Vehicle Lighting Control on FRDM-A-S32K312 Vehicle Lighting Control on FRDM-A-S32K344   Software Environment S32 Design Studio IDE S32K3 Automotive Software Package Application Code Hub project import Vehicle Lighting Control for Daylight and Hazard Signals on FRDM-A-S32K344 Vehicle Lighting Control for Daylight and Hazard Signals on FRDM-A-S32K312 6. Implementation Guide   Step Action Sub-steps Expected Result 1 Import the Project Open S32 Design Studio 3.6.5 Select “Import project from Application Code Hub” Search for “Lighting” Select the desired project for your FRDM board Use the GitHub link for automatic configuration Select main branch Import project Project successfully appears in workspace 2 Build the Application Right-click project Select “Update Code and Build Project” Confirm SDK component management Build completes with no errors and generates .elf file 3 Connect Hardware Connect USB-C cable (and 12 V supply for FRDM-A-S32K312) Attach FRDM-K64 Click Shield, Analog Key Click and 4x4 RGB Click Verify wiring on PTA13 (FlexIO) and PTD1 (ADC) Board is powered and detected by IDE 4 Flash and Run Open Debug Configurations Select “debug_flash_pemicro” Start debugging Application runs continuously; LEDs perform startup test sequence 5 Functional Validation Press buttons T1–T6 on the Analog Key Click Observe corresponding LED patterns on the RGB Click Verify safety interlocks (high beam requires low beam) Verify continuous blinking on turn signals and hazards RGB LEDs display the correct automotive lighting patterns for each button   7. Signal Behavior and Control Logic   The following diagram illustrates how each user input on the Analog Key Click is mapped to a specific lighting function and to the individual LEDs of the 4×4 RGB Click matrix. Each button (T1–T6) triggers a unique combination of LEDs, colors, and patterns, reproducing the behavior of a simplified automotive lighting system.    The MCU continuously monitors the analog input from the Analog Key Click and decodes which button is pressed. Based on the detected input, the application activates the corresponding lighting function by driving the assigned LEDs on the 4×4 RGB Click through the FlexIO serial interface. Steady functions (Low Beam, High Beam, Brake) keep the associated LEDs constantly ON, while directional functions (Left Turn, Right Turn, Hazard) toggle the LEDs at approximately 1 Hz to reproduce the blinking behavior of real vehicle indicators. Additional control rules — such as High Beam requiring Low Beam to be active, or Hazard Lights preserving and restoring the High Beam state — reflect the interdependencies found in a real automotive body control module.   8. Troubleshooting   Issue Possible Actions Board Not Detected Check USB-C cable and drivers Verify debugger connection Restart IDE No LEDs Lighting Up Verify FlexIO configuration on PTA13 Check 3.3 V and GND wiring on RGB Click Confirm data-line wiring to IN1 Buttons Not Detected Verify ADC0_P0 configuration on PTD1 Check 3.3 V and GND wiring on Analog Key Click Confirm software debouncing thresholds Wrong Button Triggered Recalibrate ADC value ranges for each button Verify power supply stability (3.3 V) Check for noise on the analog line Incorrect LED Colors or Timing Verify FlexIO clock configuration (WS2812 timing) Check LED index → color mapping in code Ensure RGB order (GRB vs. RGB) matches the LED type High Beam Not Activating Ensure low beam (T1) is ON first — BCM interlock Check application logic for beam dependencies   9. Extending the Application   The basic implementation can be extended in several ways: Additional Lighting Functions Add fog lights, parking lights, or daytime running lights (DRL) Simulate reverse lights that activate when a specific input is triggered Adaptive Front Lighting Integrate a steering angle input (e.g., POT Click) to swivel the headlights Simulate cornering lights that turn on when indicators are active Ambient Light Sensing Add a light sensor to automatically enable low beams at dusk Implement smooth dimming between day and night modes Brake Light Enhancements Add an emergency brake flashing pattern for hard braking Implement a third brake light (single LED, always ON with brakes) CAN Communication Enable communication with other vehicle ECUs (e.g., BCM master, doors) Receive lighting commands over the vehicle network State Machine Implementation A more advanced approach is to implement a formal state machine covering: Off DRL / Parking Low Beam High Beam Hazard / Fault 10. Safety Context   This example reflects key automotive principles: Continuous monitoring of driver input Immediate response to control signals Reliable actuator (LED) control with predictable timing Safety interlocks between lighting functions (high beam requires low beam) In real systems: Redundancy is required for safety-relevant functions (e.g., brake lights, hazards) Fault detection mechanisms are implemented (open lamp, short circuit, overcurrent) Systems must comply with ISO 26262 (functional safety standard) Vehicle lighting is one of the most safety-critical automotive functions because it directly affects driver visibility and vehicle conspicuity. Modern Body Control Modules implement extensive diagnostics, backup lighting strategies, and fail-safe defaults (e.g., hazard lights activated on power-loss recovery). 11. Conclusion   This module demonstrates how a simple embedded system can implement complete vehicle lighting control using ADC input and FlexIO output on the S32K3 platform. It shows how: Multiple digital inputs can share a single analog line through resistor-ladder decoding Analog data is acquired, debounced and processed in real time Complex automotive lighting patterns are controlled through FlexIO-driven WS2812 LEDs Safety interlocks and background blinking patterns are managed by BCM-style logic   Result on FRDM-A-S32K312 Result on FRDM-A-S32K344 FRDM-A-S32K312 FRDM-A-S32K344   The course provides a strong foundation for more advanced systems, including adaptive lighting, CAN networking, ambient sensing, and safety-oriented designs typical of automotive body-control modules.

Continue discussion on the line scan camera. A completely interrupt driven approach to the interface will be illustrated.

Harvard Extension School CSCI E-251, Fall 2012: Principles of Operating Systems Final Project Presentations Presentation by Ram Garlapati

Harvard Extension School CSCI E-251, Fall 2012: Principles of Operating Systems Final Project Presentations Presentation by Eric Pedersen

Harvard Extension School CSCI E-251, Fall 2012: Principles of Operating Systems Final Project Presentations Presentation by Ethan Tavan

Harvard Extension School CSCI E-251, Fall 2012: Principles of Operating Systems Final Project Presentations Introduction by Prof. James L. Frankel

Harvard Extension School CSCI E-251, Fall 2012: Principles of Operating Systems Final Project Presentations Presentation by Timothy O'Keefe