 I'n ysgol yw'n gofyn i'r hynny'r dod o'r gwaith ym M4, a'r gwaith co-processor. Ym M4 yn gwneud o'r gwaith co-processor ac mae'r A7 yn ei wneud i'n gwybod i'r cyfnod o'r cyfnod ac yn ni'n dod o'r cyfnod i'r cyfrannu. Cyn ddim yn cofyn i'r gwaith yw byddwn gwneud i'r wyf, yw ymddych chi'n gofyn i'r gwaith, a'r gwaith bod sydd wedi'u gwaith i'r gwaith ym M1. Felly, ymdeg ymdeg yw'r môl ymdeg M4 yw'r co-proses ymdeg yw'r llunion. Felly, mae'n ddod o'r ffordd ymdeg. Felly, mae'n ddod o'r ffordd ymdeg ymdeg ymdeg M4. A beth o'r ffordd ymdeg ymdeg ymdeg A7 a'r dddr i'r ddryf yn ysgrifetig a ddod o'r ddod o'r ddryf yn ymdeg. Yn ymdeg, mae'n ddod o'r ddryf yn ein ams Margaret llawn ymdeg Ymdeg, i'ch ei wneud rhan fy teith Carrr depth o effeic yma. Ymdeg mae ewa gweithio yn L-format ac mae den hyn fairfioή yma'i wneud ymddeg Llinx. Diไf am nieuweith a iddi'rowski i'i Gaelol Skor pa y θαr yn wir ei wneud a bwdych chi na fydd yn ei filledboa Byrhe. Felly, mae'n ran cael y rôl i fyd doLAns Gaelol ff Status Mae yma hanes â officials ymdeg findydd i'r Om. ac mae'r Cortex M4 yn ei gael i adeiladnau cael ei cloc o'r cyffredigol ar y cell rhaid i'r RCC. Cyngor dechrau'r Cortex M4 yn ei gael i'r cyffredigol, ac mae'r Cortex M4 yn ei gael i'r Cortex M4 yn ei gael i'r cyffredigol. Mae'r rheswm ymgyrch. Mae'r M4 yn ystod o'r co-proces yw'r A7. Mae'r rheswm ymgyrch. Mae'n gwneud o'r perifrwys i'r A7 oedd o'r M4 gyda chi'n mynd i chi'n gwneud o'r adeiladau. Llinux yn ymgyrchu'r clotri ac ymgyrchu. Mae'r M4 yn ymgyrchu'r llunio'r llunio'r llunio'r llunio. Mae'r M4 yn ymgyrchu'r llunio'r perifrwys i'r llunio'r llunio'r llunio. If the timer has a pre-scaler, mwyr gallwn baen nhw'n achesol gwybaint arwyd. A mae'n teimd Allun Ewagol am Seneddio'r Llinux. Mae'r M4 can ni clywed o'n ddechrau. Mae'n gwneud y peryfforydd oByno haill Geril Cymru. Mae'n goch gan Ymgyrchu A7 ac yn gwneud i grynorthol BUT Cymru의 allun o'un gyda'i Llinux. Mae'r M4 gan희,11 wallet ac sydd yn frebyn, fellyLOB neu mater i'r lluniau. Mae'r M4 yn oed llawn i gyda fyf American gearbox. i chi yn ystafell Cylunox syrcaeth G-PIO ynghylch o'r ddod yn teulu dadlw'r Ohs 140. Byddwn diddair o'r hyffordd gyda'r Open ST Linux sy'n gyfer rydym yn gyffredig at y cyffredig o'r Cylunox a llunox sy'n gyffredig o'r Cylunox sydd gennym yn llefod llunox. Yn mynd i'n rhai, iechyd unrhyw prif하u yn y cwymol Byddwn cyffredig o'r Maeron M4 a fyddaeth ein prifhau ar yr A-7 drog yma yna'r llunoxau a bod cyfanyddob dros a can potentially be used by the Cortex-M4. The main device tree, so the main assignment of peripherals, is all done in the TFA section, which is the first stage boot loader. So all the Cubamex tool generates the correct device trees for the correct sections, so TFA, U-boot and the kernel. And for the main assignment of the peripherals, this one is done through the TFA side. So when it comes to using a peripheral, there are some features that are shared. The GPIOs are shared between the A7 and the M4, because port A might be split across timers, analog pins, things like that. Some might be assigned to the A7, some of those pins might be assigned to the M4. So the whole of the GPIO part is technically shared. As the GPIOs are shared, the external interrupts, which are linked to the physical GPIO pins, they are also shared between the A7 and the A4. To manage the sharing, we have a set of hardware semaphores, a HSEM. This means that you don't have the two cores trying to access the same physical bit of hardware at the same time. So you grab hold of the semaphore, do what you need to do on that GPIO port, release the semaphore. The reset and clock control, that is controlled by the A7 side. So it has dedicated registers, so you don't actually have specific semaphores for doing the changing of that. So the MCU has a set of dedicated registers and the NPU has a set of dedicated registers. There's a few other peripherals as well that are shared. So system config, DMA mux and IPCC, and again, they all require the HSEM as well. So they can be activated as and when needed by each of the two cores based on what you're doing in your application. So if we look at these shared resources, so we have the system resource manager on the left-hand side, which is in the kernel space, and this is using the remote proc community driver. And the system resource manager will reserve the interrupts, the GPIO clocks and the regulators for the Cortex-M peripherals based on what is in the device tree. So if you are using, if we look at the block down here, the external interrupts, the GPIOs, the clock, the power, all of that gets reserved on the A7 side. The external interrupts using the hardware semaphores can be configured and changed from the M4 side. So you have direct access to that. The GPIOs can be configured and the drive output can be changed using the M4 side. But the reset and clock control all you can do is enable and disable the peripheral clocks. So you can't change any of the main system clock trees for that inside there. Any other peripherals, the M4 has 100% control of no problems at all. If you notice down at the bottom, power, there's no actual attempts to control the power. Power changes have to be requested. So you have to ask the system to change the power modes from M4 to the A7. So the M4 has to go and ask a standard question or send a standard message to the A7 if it wants to change the power modes. So here's how we do that. If you've got your application on the Cortex-M4 running, doing what it needs to do with its normal peripherals, all of a sudden it goes, I need to change my power structure for whatever reason. So it goes to the resource manager, asks for the reconfiguration. It then goes through the standard messaging procedure that we have between the two cores. So open amp and the IPCC and a section of memory for the parameters it wants to transfer across. Then on the A side, the IPCC will receive the request. It'll activate its remote proc procedure to receive what the request is based on the message that's been sent. Then the system resource manager will then go and activate the changes and eventually reconfigure the clocks and the regulators for the Cortex-M device. So there is a defined procedure for what you need to do if you want to change the power. So you're not fixed. It just has a specific procedure so that you can change the power settings. For the communications, when you want to send large amounts of data across, you'll have your applications running on both sides. So your Cortex-A application and your Cortex-M application. This slide set is showing using the virtual UART. We have a version that's a virtual I2C as well. Virtual UART uses the open amp protocol which will put all the information into some RAM and buffering. Once that's been done, the HAL IPCC will trigger all the interrupts to trigger the opposing core to react to the information that's sent across. Then on the other side, you've got RP Message, which is the community driver that will receive the information from the buffer and pass that message through what is the equivalent of a UART back into the opposite application on the Cortex-A7 side. It can work in the opposite direction as well. So it's not just fixed in one way that is. It's a bidirectional channel. We've already seen this before, the engineering boot mode. When you want to develop the core of your M4 part application, you can do it without the need of the A7 so you can segment it across a team. Someone can be working on the Linux side, somebody else can be working on the Cortex-M side, which is the real-time application side. As we've said, there's no Linux boot image needed. You can play around directly with the M4. It's loaded via your JTAG Siri with a debug. You've just got to remember to address your clocks and alternate functions set up so that your application will run correctly because normally your Linux side would be managing that part of the application. Finally, you've got the debug screen. So when you want to debug your M4, this is a standard eclipse environment that we've been using today. So you've got your step-by-step commands or play and resume. You can have a look at the stack to see how many levels of stack you're in. You can view the registers of specific ports and IOs, and then you've got your main code down there. Right at the bottom, you have a console window to see what's going on in the system so you can actually view the outputs to the Linux host side via a UART. So we're going to have a play with this now in the lab, so we'll actually send messages now between the Cortex-A7 and the M4, and then we'll send a message from the M4 back to the A7.