The line scan camera module consists of a CMOS linear sensor array of 128 pixels and an adjustable lens. This camera has a 1x128 resolution. Line Scan Camera Board Details Schematics, BOM, and datasheets: Line Scan Camera featuring TAOS 1401 Mounting Options You will likely want to mount the camera on a mast or boom above the car to ensure the greatest field of view. Determining the angle of orientation about the pivot at the top of the boom will change the “look ahead” distance of the camera and enable more efficient steering algorithms DIY Camera Mounts Solution Overview One method of implementation is to take the entire readout of the camera and store it in the memory. Then a line detection algorithm can be used to locate the position of the black line. Due to varying lighting conditions, some level of pixel thresholding may be necessary as the intensity differences across the data may not always produce a clear indication of the line location. A good approach is to use an algorithm that looks for changes in the magnitude of voltage from one portion of the array to another, since the camera’s AO magnitude is directly related to the brightness the pixel array senses. If the microcontroller finds a significant decrease in magnitude followed by large increase in magnitude this would give us a good indication of the location of the line. For this a derivative function can be utilized. Once we have successfully determined the position of the black line, immediately adjust the wheels to adjust the direction of the car so that the black line will remain in the center of the camera’s view. Sample camera output (for illustrative purposes only) The camera outputs an analog signal from 0 to 5V depending on the grey-scale value of the image. to simplify our sample we will assume that we have set limits for the line and have transformed the data to digital bits using a threshold value. 0’s are high intensity (non-line locations), 1’s are low intensity (black or line locations) 10000000000000000000000000000000001111101000000000000000000010000000000000000 Since the camera provides a 128x1 bit picture, and the camera will be pointing down at the track which is a fixed width. A control algorithm should be developed to line up the 1’s in the center of the 128 bits. The center of the field of view will be require calibration and testing, but it is assumed that the camera will remain in a fixed location pointing down the center of the forward looking axis of rotation. Signals For normal operation of the camera, the following signals must be produced and processed: CK (clock) - latches SI and clocks pixels out (low to high) continuous signal SI (serial input to sensor) begins a scan / exposure discrete pulses, pulse must go low before rising edge of next clock pulse AO (analog output) - Analog pixel input from the sensor (0-Vdd) or or tri-stated The CK and SI signals are simple ON/OFF signals which can be produce using a GPIO Pin, setting the pin high and low corresponding to the desired exposure time of the camera. The only other requirement is to read the Analog Output of the camera which requires the initialization of the Analog Module and setting it to the proper pinout. Acutal camera output image: Yellow = SI, Green = Camera Signal, Purple = clock More camera waveforms and information (Power Point) available here This link shows a video of the camera connected to the oscilloscope http://www.youtube.com/watch?v=YOAd3ERnXiQ To obtain this signal, connect channel 1, 2 and 3 of an oscilloscope to the SI pulse (Trigger off this signal), CLK, and AO signals. Timing The timing for creation and read of the signals is crucial and is detailed in the diagram below. This information can also be found in the Line Scan Datasheet. Analog Read: The Analog Output (AO) signal from the camera needs to be processed and read by the microcontroller's Analog to Digital Converter (ADC). This ADC device converts a continuous signal into a discrete number which is proportional to the signal voltage. An 8 bit ADC has 256 discrete levels (2^8). If a analog signal between 0 and 5 volts is sampled, a digital discrete number of 0 would correspond to zero volts, and a digital discrete number of 255 would correspond to 5 volts. A number such as 145w would correspond to about 2.8 volts. The maximum signal sample rate is limited by the microcontroller. Proper configuration of the ADC peripheral and the multiplexer of the chip will configure a pin to read in an analog signal when calling the function. More details on analog to digital converters can be found on the wikipedia site here. Read/Write In write mode, the GPIO pin can be set, cleared, or toggled via software initiated register settings. Microcontroller Reference Manual: Analog to Digital Converter You will find high level information about GPIO usage in several different areas of a reference manual. See the reference-manual article for more general information. Relevant Chapters: (see GPIO chapters for clock and SI Creation) Introduction: System Modules: System Integration Modules (SIM) - provides system control and chip configuration registers Chip Configuration: Signal Multiplexing: Port control and interrupts Focusing the camera: Once the sensor is perfectly working the next step is to find the best position of the lens that will generate the clearest images. The best way to do it is using an oscilloscope: Connect the SI and AO signals to the oscilloscope Set the SI pulse so that it can be clearly seen and then trig the AO signal with the SI signal using the trig function Fix the camera looking at a sheet of paper with a black line in the center The image of the black line will appear on the oscilloscope screen Screw the camera until you find the position where the line seems the clearest Camera Circuit   5 wires must be connected ground power SI CLK AO Camera Limitations   According to the datasheet:   " The sensor consists of 128 photodiodes arranged in a linear array. Light energy impinging on a photodiode generates photocurrent, which is integrated by the active integration circuitry associated with that pixel. During the intergration period, a sampling capacitor connects to the output of the integrator through an analog swith. The amount of charge accumulated at each pixel is directly proportional to the light intensity and the integration time." Integration Time: T T = (1/fmax)*(n-18)pixels + 20us, where n is the number of pixels Minimum integration time: 33.75us Maximum integration time: capacitors will saturate if exceeding 100ms frequency range 5 Khz - 8 Mhz (8 Mhz is fmax in equation above) The integration time is the following: It occurs between the 19th CLK cycle and the next SI pulse. The CLK frequency itself has little to do with the integration time. One each rising edge, the clock outputs one of the previously sampled intensity values. This means that integration time should be set by varying the time between SI pulses, not changing the clock frequency. Make the CLK frequency high, and have as much time as needed between the two SI pulses to obtain the desired intensity value. Pro Tips: #1 - Avoid Light Noise Light can be transmitted through the pcb on the back of the camera. This unwanted extra light shining on the CMOS linear sensor can induce significant errors into your signals received. A shroud or housing for the camera unit can easily eliminate this problem. One of the easiest solutions is to place a piece of electrical tape across the back of the camera in the highlighted area indicated in the picture below. #2 - Know your Settings When testing the car on the track or transporting it, it is not uncommon for the focus on the camera to loosen or change. Therefore it is recommended that after adjusting your camera focus for maximum performance you make mark (ex. metallic sharpie) between the lens and its body so you can realign the camera lens to it's proper position easily if it does shift. #3 - Know your Zone When hooking up the linescan camera, regardless of position or focus there is a drop off at each end of the image data. This is easily viewed with an oscilloscope. This effect is undesirable, particularly when you are finding your line position utilizing a derivative approach. These fallouts cause erroneous derivative values, and hence a poor line position solution. Two solutions we found useful were: (1) Ignoring the first 10-15 pixels and last 10-15 pixels of the image data array, and then determining the line position; (2) Often when making decisions in the code as to where the line was at it was found useful to use a threshold value for the difference in the derivative position, and secondly a binary threshold on the camera data. Note that the falloff depends on camera focus, position, etc. Therefore, these threshold values and pixels in which to ignore are relative to a specific instance. The problem however is common to the camera. #4 - Buffer Data Since the camera can read the line very quickly while the servo can only update every 20ms, there are multiple camera reads before the servo can update, if you are reading the camera fast and then overriding without saving them in some form then those camera reads are being wasted and are better off not having occurred. What can help is to create some sort of filter by bringing new values into an array with previous values and preforming some sort of averaging. The following code will take the new line position value and place it in a 1xA array where A is defined by CAMERA_AVG. NO AVERAGING IS OCCURRING HERE all that is happening is the camera values are being saved in a simple array, what is done with them is up to you. The way this works is that it shifts the entire array so the oldest data point is discarded in order to make room for the new line position at the other end of the array. It will only adds the new value if there is one available if not it copies the previous first position value to the new first position value. CAMERA_AVG => an integer value for how long the averaging length will occur gfpLineAverage => global floating point array of camera center line values fpLinePos => returned from read camera this is the center line position ReadCamera() => is the read camera function call returns a floating point value of fpLinePos // this will shift the values up and throw away the oldest value // then add a new reading for (i=CAMERA_AVG;i>0;i—) { gfpLineAverage[i]=gfpLineAverage[i-1]; } // if no line was detected the previous camera value will be passed on if (fpLinePos=ReadCamera()) { gfpLineAverage[0]= fpLinePos; } For example an array of of center line position values ranging from 0-127 could look like. Initial values [51 50 52 54 58 55] New position of 45 read [45 51 50 52 54 58] New position of 44 read [44 45 51 50 52 58] No value read [44 44 45 51 50 52] No value read [44 44 44 45 51 50] New position of 50 read [50 44 44 44 45 51] Program Exercise Specifics of how to configure the K40 ADC, to create the delay code is covered in the K40: Line Scan Camera Tutorial. Additional 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 Additional Resources Freescale app note on interfacing with a linescan camera Freescale app note on interfacing with an RCA camera

Here is a simple example developed at Politecnico di Torino, to show how the NXP CUP car can be managed using Simulink-generated code. The Simulink model is intended to move the car forward and backward for 20 seconds, or until an obstacle is found. Any comment is welcome.

This tutorial covers the details of Blinking an LED on the Kinetis K40 using the TWR-K40X256-KIT evaluation board. It will introduce the evaluation board, and some basic CodeWarrior features. Overview 1. Hardware 2. Set up the Software Development Environment A. Download and Install Codewarrior B. Download and Install Drivers 3. Set up the Hardware: Twr K40x256 Hardware Setup 4. Import the LED Project 5. Build the Code 6. Download/Debug/Run 7. Learning Step: LED Code Description Read/Write Functions Variables Header File Definitions Initialize the GPIO Blink the LED: Other K40 Tutorials: K40 Related Pages Credits / References Overview   In this exercise students will explore a Freescale Cup Car application which targets a Freescale K40 board attached to the Tower System.   Students will: Configure the Software Development Environment Configure the evaluation board hardware Learn how to import example files into a CodeWarrior project Build a project Download and run the code on a Kinetis K40 Tower System board Learn how to utilize the GPIO Peripheral to blink a LED     To successfully complete this exercise, students will need the following board and development environment. The K40 Tower card, TWR-K40x256 CodeWarrior for Microcontrollers USB Cord 1. Hardware     Read the Blink LED overview article for general information on LED circuits, GPIO pins and reference manuals.   2. Set up the Software Development Environment   There are several steps necessary to prepare the evaluation board and PC for microcontroller programming and development. Interfacing the evaluation board with a PC requires downloading and Install the CodeWarrior IDE, as well as the device drivers for programming the microcontroller via USB. A. Download and Install Codewarrior   Before completing this example project, download-and-install-codewarrior-10-1 or the latest version compatible with the twr-k40x256-kit.   B. Download and Install Drivers   In addition to CodeWarrior, it may(needs verified) be necessary to install one or both of the following tools: RAppID initialization tool- RAppID comes on the DVD provided with your evaluation board. In the main directory of the DVD, click on the "TRK_MPC5604B.html" file to open the DVD interface which provides user manuals, software, schematics and documentation for the evaluation board. P&E Microcomputer Systems, Inc drivers- P&E is a a computer driver for the TRK-MPC5604B and Kinetis Tower system device, enabling evaluation board programming via USB through the CodeWarrior debug OSJTAG interface. This driver can be downloaded here in case this isn't found on the disk.   3. Set up the Hardware: Twr K40x256 Hardware Setup   There are several Twr K40x256 hardware configuration steps. Follow the twr-k40x256-hardware-setup instructions before importing the LED Project. 4. Import the LED Project   After the software is successfully downloaded and installed, the next step is to import an existing project into your Workspace. in this case, the LED_BLINK_96MHZ Project. Follow the instructions on the codewarrior-project-import page to import the LED_BLINK_96MHZ project into CodeWarrior. If errors are encountered, look in the Problems view and resolve them. Ignore any warnings. 5. 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. By default, the application is set to link to RAM. If you want your program in FLASH, make sure that you have that build configuration enabled:     Make sure you do a "Clean" operation (under the project menu) after you make the configuration change. If you encounter errors, look in the problems view and resolve them. You can ignore any warnings. 6. Download/Debug/Run   If the project builds correctly, it is time to download to the board and watch it work. Ensure that the USB cable that came with the board connects the board to the host computer’s USB port. There are multiple ways to issue the Debug command. Right click the project in the projects view and choose Debug As->CodeWarrior Download. Alternatively, y go to the Run menu and choose Debug (F11). Click the Resume button and your should see the LED blinking! Click the Pause button to stop execution. Click the Terminate button to end debugging. 7. Learning Step: LED Code Description Read/Write   If the LED was on Port C, Bit 7 we might have code like: #define LED_E1_Location(1<<7)   For example, to toggle a pin the following code might be used: GPIOC_PSOR=LED_E1_LOC     "Sets" the LED located at "E1" high.   the syntax means the following GPIOC refers to Port C   "Set" is one of three commonly utilized commands for GPIO control. There are also commands for "Clear" and "Toggle."   Command: "GPIOC_PSOR" literally means PORT SET OUTPUT REGISTER which SETS a pin high Command: "GPIOC_PCOR" clears a pin, PORT CLEAR OUTPUT REGISTER which CLEARS a pin to the "low" state Command: "GPIOC_PTOR" toggles a pin opposite of the current state   the « is a "shift" command which is discussed in the c-programming-for-embedded-systems. You can alter the raw register as well using a MASK but the dedicated set/clear/toggle registers are more straightforward.   **NEEDS UPDATED ** Hardware Chip Port/Pin Comment SW3 PT cell-content SW4 cell-content cell-content Functions   The following functions can access the LED; //Where n is the LED number LED_En_TOGGLE;  //will toggle a LED to a different state LED_En_ON; // turns the LED ON LED_En_OFF // turns the LED OFF Variables   Locations of the LED's LED_E1_LOC LED_E2_LOC LED_E3_LOC LED_E4_LOC Header File Definitions   from k40_TOWER_BOARD_SUPPORT.h //The E1 LED is on Port C, Bit 7 #define LED_E1_LOC (1<<7) #define LED_E2_LOC (1<<8) #define LED_E3_LOC (1<<9) #define LED_E4_LOC (1<<11)    //There are dedicated set and clear registers.    //Write a one to PSOR Sets the Bits, Writing to PCOR clears bits.    //Toggling a bit can be done with the PTOR register    //You can access the raw register as well -> PDOR |= My Bit    //but the dedicated bit set/clear/toggle registers are easier!    //Also, The cathode of the LEDs are towards the port pin! This means    //you have to turn the port off to get the LED to turn the pin on. #define LED_E1_OFF   GPIOC_PSOR=LED_E1_LOC #define LED_E1_ON   GPIOC_PCOR=LED_E1_LOC #define LED_E1_TOGGLE   GPIOC_PTOR=LED_E1_LOC #define LED_E2_OFF   GPIOC_PSOR=LED_E2_LOC #define LED_E2_ON   GPIOC_PCOR=LED_E2_LOC #define LED_E2_TOGGLE   GPIOC_PTOR=LED_E2_LOC #define LED_E3_OFF   GPIOC_PSOR=LED_E3_LOC #define LED_E3_ON   GPIOC_PCOR=LED_E3_LOC #define LED_E3_TOGGLE   GPIOC_PTOR=LED_E3_LOC #define LED_E4_OFF   GPIOB_PSOR=LED_E4_LOC #define LED_E4_ON   GPIOB_PCOR=LED_E4_LOC #define LED_E4_TOGGLE   GPIOB_PTOR=LED_E4_LOC Initialize the GPIO   From K40_TOWER_BOARD_SUPPORT.c void InitK40GPIO() {    SIM_SCGC5 = SIM_SCGC5_PORTA_MASK | SIM_SCGC5_PORTB_MASK | SIM_SCGC5_PORTC_MASK | SIM_SCGC5_PORTD_MASK | SIM_SCGC5_PORTE_MASK;    //To use a Port, its Clock must be enabled!!    //Lets just enable the clocks for ALL of the ports    //Important! Each IO pin has a dedicated 32-bit Register to set it up (Selection GPIO vs peripheral, IRQ, Etc.)    //Setup port C7,C8,C9 and B11 as GPIO and enable High Drive Strength    PORTC_PCR7 = PORT_PCR_MUX(1) | PORT_PCR_DSE_MASK;  //Enable GPIO on on the pin    PORTC_PCR8 = PORT_PCR_MUX(1) | PORT_PCR_DSE_MASK;  //Enable GPIO on on the pin    PORTC_PCR9 = PORT_PCR_MUX(1) | PORT_PCR_DSE_MASK;  //Enable GPIO on on the pin    PORTB_PCR11 = PORT_PCR_MUX(1) | PORT_PCR_DSE_MASK;  //Enable GPIO on on the pin    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;    GPIOB_PDDR |= LED_E4_LOC;    LED_E1_OFF;    LED_E2_OFF;    LED_E3_OFF;    LED_E4_OFF; } Blink the LED:   Within Main.c or any other C file created, Blink the LED's using the following functions: LED_E1_TOGGLE; LED_E1_ON; LED_E2_OFF; Other K40 Tutorials:   K40 Related Pages   K40: Turning A Servo Tutorial   K40: Drive DC Motor Tutorial Kinetis K40 TWR-K40X256 K40: Blinking LED Credits / References   Some of the content from this tutorial originated from:   Shawn Moffit: Electrical Engineering, Penn State University for - K40 Code   Processor Expert Hands-On Lab Rev. 1.0, 05/2011 by Jim Trudeau, Freescale Semiconductor, Inc. for - some text descriptions of steps Original Attachment has been moved to: LED_BLINK_96MHZ.zip

For details on how to use the Motors, visit theDC Motor Tutorial Images Boards before 2013 Current Board Rev. 0 Rev. 1 Technical Details Revision 1 (Schematics, design files, sample code, instructional videos) Revision 0 (Schematics) H-Bridge Specifications Freescale MC33931 Datasheet Pro Tips: #1 - Electro-Magnetic Interfence (EMI) This has been mitigated in the rev. 1 board. In many cases the dc drive motors give off much EM interference causing poor data from the camera, and decreasing the servo motor performance substantially. In most cases around a PWM value of 20-25 duty cycle at the drive motors, caused detrimental problems. This problem was remedied in two ways, (1) connecting capacitors between the motor leads, the closer to the drive motor the better; (2) There is a way to connect the camera directly to the kwikstik and bypass the motor board. #2 - Rev. 0 Board workaround to Enable Braking This has been fixed in the rev. 1 board. In order to go forward AND backwards, you have to have control over IN1 and IN2 (see table below). If you look at the schematic, you can see that IN1 is directly connected to GND. In order to enable breaking you need to lift pin 43, solder a wire to it and control it properly. Tutorials General Tutorial on the DC Motor Control Qorivva: DC Motor Tutorial Kinetis Tower: DC Motor Tutorial Design evolution of motor board prior to 2010 - Freescale Cup Cars utilized the MC33932EVB 2010~2012 - Freescale Cup teams migrated to the current Interface/Motor board featuring Dual H-Bridges [Not manufactured] Tower and Trak Compatible Interface/Motor Control Board (Design files if you want to make one!) 2013+ - FRDM-KL25Z shield

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 Vehicle Lighting Control demo on FRDM-A-S32K344 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 Brake Status Monitoring demo on FRDM-A-S32K344 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 PWM-Based Steering Control demo on FRDM-A-S32K344 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 Vehicle Comfort Control demo on FRDM-A-S32K344 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 Transmission Control demo on FRDM-A-S32K344 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.  

One option for mounting the FRDM-KL25Z Freescale Freedom board to the car chassis. [no audio] Important Note:  Secure the wires coming from your motors!!  (I used a zip tie in the video)  If they are allowed to flex at the joint where the wire connects to the motor, it will eventually fail.

prueba con una linea recta y una ligera curva a maxima velocidad

Review the design and operation of the Freescale linescan camera included with the TFC-KIT. A high level overview of the sensor IC interface will be shown to the audience. View Video Link : 1471 and Video Link : 1472

Entrenamiento acerca del MCG de la herramienta de desarrollo Freedom, para los microcontroladores Kinetis L series. Para acceder al material completo visita: https://community.freescale.com/docs/DOC-95205

En este video puedes consultar paso a paso la descarga e instalación del CodeWarrior 10.4 para microcontroladores. Accede a la liga www.freescale.com/cwmcu10

Find the complete material at: https://community.freescale.com/docs/DOC-95205

Freescale Cup shield introduction for use with the FRDM-KL25Z or similar development board. Steps through the schematic of the FRDM-TFC shield and explain it's interfaces, logic, and use.

Continue showing how to start a project from scratch.  In this second part,  we will see how to import new files into a CodeWarrior project to build a project. View Video Link : 1458

The Freescale Cup East China 2013 challenge video 2 After formal competition finished in East China, we gave a challenge and asked teams to try a hill with >30 angle, some cars successes

In this video we will discuss clock distribution in the KL25Z device. An example of initializing the PLL with the on-board crystal will be demonstrated.

Find the complete material at: https://community.freescale.com/docs/DOC-95205

Find the complete material at: https://community.freescale.com/docs/DOC-95205

This video will examine how can design speed sensing into their vehicle platform.   An example of magnet and sensor placement is shown.

After formal competition finished in East China, we gave a challenge and asked teams to try a hill with >30 angle, some cars successes