Number of ADCs and Channels –> S32K144 contains two 12-bit SAR ADC modules, ADC0 and ADC1. Each ADC supports up to 16 external analog input channels. Note that ADCx_SEy refer to Channel y of ADCx. DMA support for ADC –> Continuous ADC sampling, like 4K samples/sec, can overload the CPU. Using the PDB to trigger the ADC helps reduce this load. For higher performance, the ADC can trigger DMA directly after each conversion, freeing up the CPU. There’s also a flexible option with TRGMUX, allowing DMA to trigger after multiple ADC conversions instead of just one. This gives more control based on what the application needs! ADC Interleaved Channel Functionality –> ADC interleaving allows multiple ADCs to sample the same signal alternately, improving performance by increasing sampling speed without overloading a single ADC. On devices with two ADCs, specific channels support this feature. For example, ADC0_SE4 and ADC1_SE14 can either work independently or interleave to sample a signal from PTB0. This interleaving is enabled by the SIM_CHIPCTL[ADC_INTERLEAVE_EN] bit, and other channels like ADC0_SE5/ADC1_SE15 can interleave on different pins (PTB1, PTB13, PTB14). Internal Supply Monitoring –> ADC peripheral can also be used to monitor the internal supply. This monitoring is done through ADC0 internal channel 0. Referencing Option for ADC –> The ADC offers two reference voltage options: VREFH/VREFL: The primary reference option. VALTH/VREFL: An alternate reference option. –> You can select between these references using the ADCx_SC2[REFSEL] bit. In S32K1xx devices, VALTH is equivalent to VDDA. If a package doesn’t have dedicated VREFH/VREFL pins, VREFH is internally tied to VDDA and VREFL to VSSA. When an external VREFH is available, it should either match VDDA or be within an allowed range below it. VREFH must not exceed VDDA, and VREFL should always connect to VSSA. –> In a nutshell, you can change the reference voltage for ADC conversion as per user requirements.  Trigger Sources Available for ADC -> In ADC systems, triggers are signals that start the conversion process, while pre-triggers are used to select or control specific ADC channels before conversion begins. They allow flexible control over when and how ADC conversions are initiated. -> ADC triggers and pre-triggers control when conversions start and which ADC channels are used. The Programmable Delay Block (PDB) or Trigger Multiplexer (TRGMUX) provides flexible trigger options: PDB Triggering: Automatically triggers ADC conversions and controls channels via up to 8 pre-triggers, reducing CPU involvement. Each PDB pairs with an ADC (PDB0-ADC0, PDB1-ADC1). TRGMUX Triggering: Offers flexible ADC triggers using external/internal signals. Modules like CMP, LPIT, RTC, and LPTMR can trigger the ADC. TRGMUX enables different peripherals to start ADC conversions without the PDB. -> The trigger source is controlled by SIM_ADCOPT[ADCxTRGSEL], allowing the selection of PDB or TRGMUX based on application needs. -> Hardware Triggering Schemes: Default Scheme (PDB): The most common method is using the PDB to trigger the ADC. This approach is suggested for general use because of its simplicity and automatic trigger mechanism. Alternative Scheme (TRGMUX): TRGMUX provides another option for hardware triggering, offering more flexibility in selecting which peripherals or pins will initiate ADC conversions. -> The SIM_ADCOPT[ADCxTRGSEL] field is used to control and configure the source of ADC triggers, allowing the system to choose between PDB or TRGMUX based on the application needs. To completely understand this Block Diagram, follow our course on AUTOSAR ADC. Trigger Selection for ADC –> You can select any combination of trigger enable and trigger for the ADC, but once selected, they cannot be changed on-the-fly. There are specific steps for switching the trigger or pre-trigger sources: –> To Change the Trigger Source: Stop the current trigger generation. Wait for 2.5 cycles of the ADC operating clock and 1.5 cycles of the ADC host interface clock, allowing the last trigger to latch. Check the ADC_SC2[TRGSTLAT] status until it becomes 0, indicating all queued conversions are completed. Update the trigger source as needed. Restart the trigger generation unit. –> For Immediate Trigger Change: Stop the current trigger generation. Flush the queued triggers by setting ADC_CFG1[CLRLTRG], except the one currently in progress. Wait for 2.5 cycles of the ADC operating clock. Check ADC_SC2[TRGSTLAT] until it becomes 0. Update the trigger source. Restart the trigger generation unit. –> Note: If these steps aren’t followed, some triggers might be missed without being reported. Trigger Handling and Capturing –> The four lower triggers can be latched, meaning trigger requests from any selected source are captured and processed one at a time. The ADC handles each latched trigger request sequentially, starting the next only after the current one is complete. This ensures that only one request is processed at a time while others wait in the queue. –> If a trigger request is repeated for the same trigger (0–3) while it’s being processed or already latched, the new request is ignored, and an error is flagged in the ADC_SC2[TRGSTERR] register. –> Trigger requests can arrive in two ways: (a) one at a time or (b) simultaneously. However, they are processed in a round-robin order. After completing the Pth request, the system looks for the next available request, starting from P+1 and cycling through until all latched triggers are processed, rolling back to 0 after reaching the last trigger (N-1). ADC Trigger and Pre-Trigger Configuration –> The ADC supports two main triggering schemes, as previously explained, through these two paths (using the ADC0_PDB0 triggering example): Direct Triggering Path: Used through the PDB starting from channel 4 onward. Multiplexed Triggering Path: Utilizes PDB/TRGMUX for channels 0 to 3 via a trigger latching mechanism. –> When configuring the ADC, you can either: Use the direct triggering path with PDB for channels 4 and above, while using PDB for channels 0 to 3, or Use only the TRGMUX path for channels 0 to 3. –> For the PDB direct triggering scheme, ensure that pre-triggers are spaced at least 4 bus clock cycles apart. The table below outlines the ADC triggering configurations and their behavior based on these paths. –> Note: The PDB only signals

Before Autosar and challenges Before the development of AUTOSAR (AUTomotive Open System ARchitecture) in 2003, the automotive industry lacked a standardized approach to software architecture, hardware platforms, and development standards. AUTOSAR was created to address these challenges by providing a standardized software development infrastructure. It’s a global partnership between automotive industry participants, including OEMs, suppliers, semiconductor manufacturers, and software suppliers. Birth of Autosar/Timelines of Autosar // which companies united for autosar, with what motive it was invented and mention its timeline //organisation that are established because of autosar With respect to this background, the leading automobile companies and their first- tier suppliers formed a consortium in 2003, This partnership was established as an industry wide standard for the automobile electronics: AUTOSAR( Automotive Open System Architecture), which is headed by the following 10 “core partners”: BMW Group, Bosch, Continental, Daimler Chrysler, Ford Motor Company, General Motors, PSA Peugeot Citroen, Siemens, VDO, Toyota Motor Corporation and Volkswagen. Autosar Consortium has different members, mebers in the form of companies that contribute to it. The roles are varied in terms of their contribution and exploitation. These members are divided in 4 categories: Premium Members Associate Members Development Members Attendees Subscribers // give small brief about autosar members Timeline of Autosar: The first phase of Autosar started in 2003 and ended in 2006, during this phase 52 premium members, companies of the suppliers and software and semiconductor industries joined the development of this standard and made major contributions in the consortium.   Main Objective of Autosar Autosar was set up as a partenership to define an industry wide Themost important consequence of the stringent component-based approach of AUTOSAR, concerning the development process ,is as paration of application devel opment from the lower levels of the integration development (basics of software[BSW]). The separator between these two parts is the AUTOSAR run time environment (RTE), which concretely realizes the concept of a virtual functional bus( VFB) as an abstract ing communication principle. The idea of this concept is that an application does not need to know the concrete paths from data and signals below RTE when two applications communicate together. The main concept or object of the AUTOSAR architecture is to separate the application software from the basic software and make it independent of the hardware (standardized infrastructure). Autosar software architecture provides the scalability of ECU software for serveral car lines and variants. Meaning a customer can spend one time developmenr cost to develope and application like a parking assist system and reuse this application on different hardwares for all his car variants. What is Autosar Autosar was set up as a partenrship to define an industry wide standard for software programing of automotive electronics. Or in more technical way one can say a industry/global level standard for embedded system programing of electronics involved in building automotive systems. To overcome the challenges, Autosar defined a new development methodology for automotive software and software architecture. The Development methodology is focussed on a model-driven development style. The software architecture is defined without considertaion of the hardware on which the software components will run on later. This means that 2 software components might run on the same ECU or on different ECU’s. The communication between the components is then either an intra-ECU communication or an inter-ECU communication. To abstract from this The lightweight Classic AUTOSAR enables companies to perform thorough security testing on systems like electronic stability control (ESC), steering, electric parking brakes, park distance control, infotainment, anti-theft systems, remote keyless entry, and more. By using it, manufacturers can find security vulnerabilities accessible via external channels, such as Bluetooth or other public-facing interfaces. Analogy of Autosar Autosar Software Stack has 3 layers: BSW Layer RTE Layer Application Layer Let’s dwell into BSW Layer. BSW layer stands for Base Software. Which further is divided into 3 layers: MCAL Layer ECU Abstraction Layer Complex Drivers Service Layer Now we will understand these layers, with respect to software’s that are involved in an ECU of a Car. So let’s just dwell into simple building blocks of a ECU. ECU is made up of Microcontroller and with that microcontroller some external sensor/modules are connected to make it a complete functional product of the vehicle. Now to use Microcontroller from software side, Microcontroller driver is needed which is termed as MCU Real Time Drivers. And to use sensor/module from software side, their driver is needed which is termed as external driver. This external driver is developed using MCU RTD and Sensor Specific requirements. These Sensor and Modules are communicating with microcontroller using MCU drivers like UART, I2C, SPI and etc. and then according to sensor/module their driver is further developed above MCU driver. Further in an ECU, different software frameworks like: Operating System, Diagnostic, Logging, Memory analyzes is also used for fulfilling requirements that has to be provided by ECU. Now let’s relate the software requirements of ECU with Different layers of BSW layer. MCU Real Time Driver is MCAL layer in Automotive World. So MCAL layer has standardized the API’s that should be used to use MCU. For each peripheral of MCU, there are MCAL standard API’s. Any Microcontroller that has to be used in Automotive world, should have its MCU RTD designed according to MCAL standard. To use the sensors and modules software stack which is used is ECU Abstraction Layer. As to use a sensor with MCU, the peripheral through which sensor is connected that RTD stack would be needed to communicate with sensor. This RTD stack comes via MCAL layer and then sensor specific driver would be made using that MCAL layer module and specific driver that is developed lies in ECU Abstraction Layer. Also in an MCU peripheral there are number of features/ways to use. So to standardized those features and ways of accessing peripheral a software layer is made that also lies in ECU Abstraction Layer. After this comes other framework stacks of: OS, diagnostics and etc. Which comes in Service Layer. Layers in Autosar Application Layer: Different

Brief history of Microcontroller Microcontroller is an innovative technology that has revolutionize the world and made the electronic items so much feasible for us. Though microcontrollers have been in world since 1960’s. Its been around 60 years since the invention of Microcontroller technology and their are more then x amount of microcontroller being deployed right now in world. Lets explore and go back to history of microcontroller’s: What are Microcontrollers is an electronic chip which is designed in a way to do general tasks till eternity The life cycle of Microcontroller’s Microcontroller is designed from transistors, millions and millions and even billions of transistors are miniaturized into small size, to form building blocks of MCU, and these building blocks give them ability to control anything. The building blocks of MCU are: CPU, Memory and Peripherals. We will dive into these blocks after couple of minutes. The designing of these transistors is an art and science behind the chip designing. This art of technology is called as VLSI( Very Large Scale Integration). And Once the designing is done then these Chips are fabricated/manufactured to give us a final by product that is physical MCU chip. And This part is done by fabrication companies like TSMC. And after that fabrication, the packaging/assemble of integrated chip happens so that these millions and millions of transistors which are minitiasuered are enabled for practical usage in electronic devices. And after that programming on these MCU and extra circuitry around these MCU’s is developed to make the MCU do any specific task till eternity. These part are referred as Embedded Systems, in which software and hardware around the microcontroller is developed to make it use in final end product. Part of Software development for Microcontroller is called Embedded Software Development and part of Hardware development for MCU is called Embedded Hardware Development. In this video and chapter we will just get ourselves stick to microcontroller technology, and focus on what things are involved for learning and using microcontroller. Though their are many topics and technologies which can be deep dive, which we will do in separate videos.   Building blocks of Microcontroller chip are Microcontroller chips have 3 building block, first is CPU, second is Memory and third is peripherals. For better understanding take the analogy of microcontroller with human body. Just like their is human body, same way their is microcontroller. In human body we have brain which does all the processing, calculations and thinking. In the case of microcontroller, CPU does all that. Then in human body we have body parts to interact with outside world, same way microcontroller have different peripherals to interact with outside world. We humans have memory/yadash based on which we do the work and do the tasks. How to sit, how to walk, how to use legs, how to use different body parents, and all these things are feed in our memory, same way microcontrollers have memory, into which instructions are written on how to use its different peripherals and how to control those peripherals and what to do when some data comes from those peripherals. Now lets just deep dive into these functional blocks in more technical understanding and learning. CPU CPU stands for Central Processing Unit, it is an integral part of microcontroller which does all the hardcore computing work. computing work in terms of electronic chip means: addition, subtraction, multiplication, division of electronic data. How fast this can be done and level of complex calculations it can do. CPU does the computing work, by a set of basic rules on how a CPU should work. These set of rules are called as Instruction Set Architecture(ISA). Their are 2 most popular types of ISA: RISC( Reduced Instruction Set Computer) CISC(Complex Instruction Set Computer) In Current modern world, RISC architecture based CPUs and microcontroller are what is widely used and adapted. Examples of RISC is ARM CPU that we see in Apple MAC book the M1 chip. another example is RISC-5 CPU, that we can see in Vega processor, which is India’s first indigenous CPU designed by xyz organization Examples of CISC is Intel 4004, which is world’s first commercially available CPU launched in 1971. Another is x86 CPU, most desktops and laptops sold are based on x86 CPU. Their terminology which we hear intel I5 processor and all they all are part of these CPU’s. Often CPU word/terminology is used interchangeable with processor or core. So wherever we mention, processor/core or CPU words they mean same thing. Another important factor on which CPU computing work matters is bit size of CPU. Meaning how much size of data CPU can execute at a time. We measure this thing in bits unit. So their are 8 bits, 16 bits and 32 bits CPU’s. In which 8 bit CPU means it can at a time can execute data of 8 bit length. 16 and 32 bit CPU means they can execute data of 16 bit and 32 bit length. Now as the bit size of CPU increases, it means more powerful and fast they are. For now we are not going too much in detail about CPU types, history and its world as that will deviate us from current topic of microcontroller. We will explore in detail about these terminologies in what is microprocessor technology. Peripherals: Peripherals are body parts of Microcontroller, it is peripherals through which microcontroller interacts with outside world. There can be more then 20 peripherals in some MCU’s and in some MCU’s their can be just 5 peripherals. There are some general purpose peripheral which are their in all or most of the MCU’s: which are GPIO, ADC, TIMERS, I2C, SPI, UART. Using these peripherals one can process and control any sensor/module connected to MCU. I2C, SPI and UART are communication protocol via which we can connect almost any sensor/module to MCU. Be it LCD screen, ethernet module, audio devices, Wi-Fi modules or any other sensor. And via GPIO, TIMER and ADC peripherals we can