 Hello, hello. We'll wait a little while here to get things going. Oh, I should point out we have two cats. Two cats in Catcam today. It's a bonus. Bonus day. I'll say hello to folks as we get things going. Restream says, set your bitrate between 4,000 and 4,000. But my bitrate is higher than that. I'm not sure why. It just wants bitrate exactly 4,000. I'll have to remember that. That was an interesting hello. Hello, PT. I remember to set the titles. And what was I going to do? I was going to take a picture of, to remind myself to change my OBS settings if it doesn't like this variable bitrate thing. Dude, a big old state of the fruit. Have a good one. All right, let me say hi to folks. Jack was first said, all right, let's see what's up. David's in the chat. UnexpectedMaker's in the chat. Beata's in the chat, along with PT. In the Discord, we have G3Holiday, BruceS. Dexter, hello. HamsLabs, how are things? Things are good. TigerBright, doublecatcam until one gets annoyed you're talking. And Andrew says hello from Cornwall. Hello, everyone. It's cleaner day, so that's why Vin is in here. Hi, Steve from the UK. Two Davids, David Smith, David Buchanan. Mototimo, Mark, hello, Mark. Ah, remotecon's going on. Pretty chill, don't you think? Hello, Simon. This Raspberry Pi stuff is just, I wish it was reliable. I wish it was. Hello, Xmicron. I'm actually surprised Vin hasn't gotten up. She must be sound asleep. Vin is the cat in the bed. Spook for some reason is sleeping with his head in the cardboard thing, which is hilarious. Hello, retired wizard. Mark says I'm trying to motivate myself to look at the IS-31 stuff. If you ever need to hand it off, because it's been too long, let us know. Pierre says it's the Circuit Cat Show. All right, well, let me do housekeeping and I'll switch away from cats here. So hello, everyone. My name is Scott. I go by Tan Newt online. I'm a smidge stuffed up because I was just walking outside and it's a little chilly. I'm sponsored by Adafruit to work on Circuit Python. Adafruit is an open source hardware and software company based out of New York City. And I work remotely for them. So I'm in Seattle here, which is why you'll see times in Pacific, because that's the time zone I am in. Circuit Python is a version of Python that's designed for microcontrollers, meaning there's no operating system. It's meant to fit in a small space. However, I've been spending the last month or two, I should look back when I started on it, working on the Circuit Python on the Raspberry Pi, meaning there would be no operating system underneath it. So I think that's pretty neat. And so I'll be working on that some more today. If folks have questions, feel free to ask them. If you wanna support me, just support Adafruit by going to adafruit.com, purchasing stuff there. They pay me to do these streams and do all this work on Circuit Python. So if you wanna support me, they support me, so support them. So that's adafruit.com. Did I actually say hello to Bruce S? Nice, Hamslabs wants some money. Congrats, hey Johnny. Yeah, so if you wanna chat with me, this middle box here is the Discord server, which is available all week long, all year round. And you can do that by going to the URL, adafru.it slash discord, that's how you join. We'd love to see you there. And I post a lot of stuff there too as well. Deep Dives happen every week. Normally on Fridays at 2 p.m. Pacific, they'd go for about two hours. So questions are welcome. We've got more than enough time to modify them, or more than enough time to answer them, modify them. My brain is kind of fried already, which is great. And thanks to whomever put a note in the doc that I will not be streaming next week, I was gonna add it there and I was noticing that somebody had already added it. So that's really cool. So yeah, no stream next week. It's a holiday week in the U.S. here. So I'm gonna work two or three days. Yeah, so that's the plan. We'll do it again two weeks. I think it'll be on Friday. Feel free to ask me on the Discord. I haven't double checked for the week after that, but. Okay, so Bruce is gonna be skiing. Dexter says, circuit Python on the Raspberry Pi Zero 2W up time, 6.4 days. How did you do that? I don't feel like mine is reliable as reliable as that yet. Hello, Minnesota Mentat. Okay, so I guess we'll dive right in. Get your snorkel on. Simon's breaking out the ESP32 S2 Coluga. Yeah, so I actually picked up some S3s. So I'm gonna have to, we're gonna have to get those going at some point soon. But I don't wanna talk about that today. I thought I'd talk more Raspberry Pi stuff. So I've been kind of doing these dual threads. I think this is the second week I've been doing this. One is I've been trying to get the reliability of the Raspberry Pi circuit Python better. In particular, the Zero 2W was having some problems with hangs or crashes. And I would like to check that today. So we'll see about that. But I also added support for, you're welcome, Minnesota Mentat says, thanks for bringing in the weekend with the deep dive. You're welcome. This is pretty much all I, pretty much all I do anyway, before my weekend. So I've been trying to hunt some reliability stuff and it's been really tough. And I kind of think I have an idea of what it is, but I can't put my finger on it. Basically in the, let me find it before I switch to my desktop. So in the datasheet for the BCM2711, there's a section called, I'll leave that. The section is called peripheral access precautions for correct memory ordering. And this is not something I've been paying super close attention to. But it says the BCM2711 system uses an AMBA-AXI compatible interface structure in order to keep the system complexity low and data throughput high, the BCM2711 ACSI system does not always return red data in order. The GPU has special logic to cope with data arriving out of order. However, the ARM core does not contain such logic. Therefore, some precautions must be taken when using the ARM to access peripherals, which is most of what we're doing. Accesses to the same peripheral will always arrive and return in order. It is only when switching from one peripheral to another peripheral, to another that data can arrive out of order. The simplest way to make sure that data is processed in order is to place a memory barrier instruction at critical positions in your code. So, and then it goes on that has this example in the second one. As interrupts can appear anywhere in the code, you should also safeguard those. If an interrupt routine reads from a peripheral, a routine should start with a memory read barrier. If an interrupt routine writes to a peripheral, the routine should end with a memory write barrier. This is kind of blowing my mind. So, they have this note here that says, kind of two reads from different peripherals, A status and B status. And it says, without precautions, the values ending up in the variables A status and B status can be swapped around. Like, no wonder it's so hard to program on a device like this. Like, if you have to get memory barriers in the right places in order to have this happen. Like, so I suspect that this could be a problem to say the least. So, let's show what I've got and kind of just start where I left off. I'll take this off because it's getting warm. It's already 78 in here. Does anyone know if the Feather interface handles I2S? It does not specify I2S, I don't think. DCD asks, what are the recommended barriers? Well, they say, up here they say a memory write barrier before the first write and a memory read barrier. They don't specify exactly what instruction to do it. I've been using a DSB data system barrier. I forget what it's called. But I'm trying to use the most aggressive, the broadest, the slowest synchronization primitive to just like have a baseline because that should work the best, ideally, if you put it in the right place. Yeah, so I think this could be causing some of my problems. Let's just get my windows set up again. I just restarted, so I've gotta kind of get everything going again. So this top right will be the UART output. And then this is the pane that I usually make. So we'll just do a make here. I think Christian was calling it, trying it earlier, earlier this week. And we did notice there were some issues between, from switching between debug and not debug. So yeah, David has a question. When you hit a problem on this project, do you ever jump over to the PIOS source code to see how they implement what it is you're struggling with to get clues on how to proceed? Yeah, so PIOS is based on Linux. So I have looked at the Linux kernel for some stuff. In fact, I was just trying to debug. You'll see that I added ways to get the current frequency and the current temperature of the chip. And it uses the video core mailbox. And something's happening with it where I'm not always getting a response. I write to the register that it's supposed to respond to me at and I just never get one in. So that's one of the things I was working on today was trying to figure out how to do a timeout from that. So I was looking at the Linux source code for doing that and they do also have a timeout mechanic. So I thought maybe that would be needed, but I'm not sure why it's as unreliable as it seems to be now. Cause it seemed to be before it was more reliable. So the way that I have it, and I guess I should have done my overhead, but I basically have the same setup, but I'm doing a network boot. So I'm gonna, I have a modified copy of the Facebook TFT, TFTP server. So I can run this in this tab. And this, what this does is when the pie boots up, it queries my desktop for the files it needs to boot up, which is pretty handy. And I think I mentioned last week that I was having a lot of trouble with it, but this week I haven't been having any trouble. So I'm not sure what it was. But let me switch to here. So I'm no longer on the screen. The bars is the converter for the HDMI output from the IO board that I'm testing on. So what we're seeing in the top right is the UR output. So this is it booting up. Was that Facebook TFTP? Yes, it was FBTFTP. It's a Python implementation of a TFTP server, which is quite handy. So what we have here is, I don't know where was I at last week. So I got SD cards working, basically. And so it's running a code.py I have on here. But you can see that it successfully did the VC mailbox stuff to get the screen going. You can see in the bottom right here that we are getting output. But it has this broke firmware debug print that I have in there. So it's trying to get the frequency and the temperature. And for some reason, it's no longer working. Like it works unreliably. So if I do it again, it looks like it times out and it still doesn't work, which is good because I was hanging before. So at least it's like, it's not like, yeah, like it's timing out. But I don't know how to get it. I haven't seen it kind of recover from this, which is weird. Let me try something else. So what I did, so if we do import board now, we can do board.display for access to the display. And we can also import display IO and do display IO. And do display IO. Oh, should I turn it off and back on again? It seems like Twitch might have. Ah, so that didn't work either. I'm gonna turn Twitch off and back on, so sit tight. Oh, interesting. It's interesting because I'm getting a, I'm getting a bitrate warning, but the bitrate warning goes away if I have Twitch off. So I wonder if it's Twitch that's particular with my bitrate. I should have, I should just set it. It's telling me to just set it to an even 4,000, which I totally could do. Right now it's variable, but I don't wanna mess with it during the stream. Thank you, foamy guy. Thanks for, let me know if it has trouble again on having trouble. It went from online to sending data on ReStream here. I don't think I can change my bitrate setting while streaming. And I'm not gonna worry about that. See, what does, YouTube says excellent, so it's okay with my bitrate. I don't know why Twitch is being picky. Yeah, so somehow, somehow my mailbox code is no longer, it's like breaking, which is very weird. And I'm not sure why, and it's really bothering me. So the other thing that I was working on, and maybe I should check in with us first, before I spend another TRR is not succeeding to fix this, is I talked about the build system that I had set up and so I do have, so here's my branch. Let's see what, yeah. So I've been working on getting these builds fixed and looks like it didn't quite pass. So let's take a look. Yeah, so it's still going. Let's slow, I don't know why it says this. So you can see here in the CIA, now I'm building Raspberry Pi artifacts, which are, which is awesome. We would need to do that to do releases and stuff. So this is pretty big. The dependency on the firmware directory so that we can make the full image is pretty large. So I had, I did this Python script that we call in this get CP depth step, which is new. And it flushes out all of the sub modules needed for a specific build rather than all the sub modules every time because before I limited it to all, it was taking like 10 minutes to just get the sub modules for some stuff. So I've optimized that and it should actually be shorter. It should be faster now. So here it's a minute 16, which is pretty slow, but if we look at a different build here, this is only 33 seconds. So it depends on what the build needs, but it should be. Hello Emma, I don't know any Swedish. I have sung some choir music in Swedish. I don't know. So this one, the operation was canceled. That's weird. So I'm letting this run, testing changes to the CI takes a while, especially it looks like it's limiting me to 10 at a time. So it's going kind of slow. So we'll let this run. It's doing a lot better than it was a couple of days ago though. If folks do want to try this stuff, let me know. I'm happy to post more builds in the live broadcast chat. Just let me know whether you need a zero 2W build or whether you need a build for the CM4. And as David pointed out, I think earlier this week, he was asking whether we match the pin names in Blanco. So I thought I would do that. Karaoke, you look kind of brain confused anyway. Yeah, this Raspberry Pi stuff is brain confusing. I think that's fair. So really close. So like I was saying, the two things that I've been kind of working on is this reliability stuff that seems really weird. And then just doing all of the easy stuff that I know that I need to do before we get things going. So I also now have a call to get the clock rate. Yeah, sorry, I know that if you're watching only on YouTube, realize that YouTube is gonna lag because it has the closed captions down there, the auto closed captions, which are worth it, but they do cause it to be more delayed. So I think Twitch is back up if you wanna switch over to twitch.tv, twitch.tv slash Adafruit if you want it to be less laggy and don't need the closed captions. Okay, yeah, so I did a lot of like kind of get everything going. So I got the CI going. I should be able to release the files now. Yeah, would I need a debug hat or a soldered up SWD to help test? And no, you should be able to just load an image. I do recommend having the UART connected, the debug UART, but you don't need the SWD unless you wanna get all the way down in the weeds. But yeah. Yeah, I can post builds. So I can make images now, which are cool. So you can use Raspberry Pi imager or Dan used to Bolina. But maybe I should just try it on the zero two and just see if this firmware problem happens on the zero two as well. I'd be kind of curious to see that. So maybe I'll give that a shot here because I was like working a lot on this stuff earlier today. That's part of the reason why I'm kind of frazzled is that it just stopped responding to me and I don't know why. I don't think I was doing anything untowards anything bad about it. I guess I could show that code that I'm running. Oh yeah, sorry for the twitch ads. So here's the mailbox code that I've kind of not been changing too much. But you can see I was getting some hangs occasionally. And so I added this count where it just increments and then if it's too large, then it says the firmware is broken and it returns a false. So, hey, JF. So I don't really know. So this is the memory barrier that I've been using to try to keep things to prevent any problems. Is it unhappy and miss the eclipse last night? There was clouds all the way through down here. Yeah, I didn't actually go look. I could kind of just assume I can't see stuff because of clouds. It's a pretty safe bet in Seattle. It's possible. Well, actually, you know what we should do first? Let's just do a clean and see if it works in debug mode. And maybe we should compare. Sorry, there is the DMB instruction. My understanding is that DSB does more than DMB. Okay, so here it is with debug build. And let's just see. We could just compare the two. If it works with the debug build, we can disassemble, oh, sorry. I kicked the side of my computer off. It's loading. So see there, it worked. So we got 600 megahertz and 49 degrees C broke again. So it doesn't work in debug mode either. So it worked once and then it didn't work. And I'm not sure, I don't know why. I don't know why it goes from working to not working. So this has been really frustrating. Does it always work in the release builds? No, it doesn't. The release builds were what I was testing with the first time. No power issues. It shouldn't be a power issue because it's plugged completely into, it's plugged into the wall. Yeah, why don't I switch to the zero two? Let's see how the zero two is fairing. I don't have my zero two set up to network boot. But I do kind of just want to see if it works. Like I was having a separate issue last time and I looked at the zero two. Let's switch over to that. Oh, you know, maybe I should make a second debug header and unplug everything. Well, I have this, one thing that was throwing me off is this is the IO board because I was using it for the SD card debugger. So I'm using the IO board where the SD card slot doesn't hold the SD card. So I had this piece of tape, but the piece of tape is not perfectly, it doesn't work perfectly either. So I was like, oh, suddenly I like somehow I have SD card problems and it's like, oh wait, that's because the piece of tape came up. It's just been so fun. It's just, it's so hard because I'm so close. Like when I get like this, when I know I'm so close to finishing something or being able to send out the code, then I really want to do like I want to finish it. And, but with this stuff, it's been so flaky in weird ways that it's been really hard to do that. So I'm just swapping my HDMI cables here so that I can HDMI to the zero two. Oh, I think I did mention that I was going to swap my, I was using a proximity sensor to switch my right hand to my mouse buttons and stuff. But I ended up, what I ended up doing is switching to a touch sensor. So I have a QT Pi SAMD 21 that's now running that code, which has been working pretty well, better than the proximity sensor. So that's been good. Spook, you're so silly, HDMI in. And should I show the image or process? Network boot. Yes, David, network boot is where you can tell the pie to get all of the files that needs to boot from another server on your network, which is, it was unreliable for me for a while, but today it's been a lot better, or this week's been a lot better. So it's been really nice, where I just type make and then restart the pie and it hits my server that's serving the copy that I just made. Ethernet network boot, correct. Yeah, so I have it plugged in. So here, this is the folder, the RPi common files is the folder that I have like the config.txt and stuff in. And I think I will just RPi image or it as we get started here. So choose OS, use custom image. And then I'm in the build directory for the zero to W and I select disk image. And then I choose that drive and I want to obliterate it. I don't know if this works, otherwise I would send it to people. If you want to try it without knowing whether it works, let me know. And I'll drop it in the Discord. My branch on GitHub is really up to date though too. So if you can build it and want to follow along, you're welcome to do that too. There's just a few debug prints that I haven't done. Moto Tima says Belina Etcher is also good imaging flashing up. Yep, and Dan used that. So it should work too. Hello, Paul. So we're right in everything out. Don't want to move it. Plug it in. Ugh, do my cable. Not spectacular. I have a lot of different things wired up. Okay, it is in. Oh, you know what? I did get a switch for this. That looks like bootout.txt, which is interesting. And it's not responding. The text on the Twitch feed is more readable. Huh, do you have ethernet plus power for the Py02? No, I do not. Interesting. Okay, so something's going on here. Let's debugger it. So we want the Py3 config and here we want zero. Oh, that's kind of good. It's been a few days since I used this, I think. Huh, high speed and net. I don't know if this new code's been used on it. I might have to kick this back over to tech. I don't know if it has a zero too. Oh, well DWC2 is null. That's probably the issue. I assume that we don't want that. Oh, you know that? That may be because, I don't know where that number's coming from. But that would certainly cause a problem. Yeah, you can do it directly. I was just gonna do it once and then after I did it the first time, I'll just copy the kernel image over. Did I try USB boot on any of my boards? I have not. Okay, so let's figure this out. I actually did just switch this over. So it's source device USB D, USB source device. Oh no, I wanna look at the particular source portable. I was using this Broadcom one, but I wanna switch it to this generic synopsis one. So let's see what it does. It takes that regs thing. Here's the init. How does this work? It's probably from here, BCM. I think if I remember right, this is 3, 3F. Let's just do it. This is 7E, but I think that's not right. Yeah, 3F. So let's just hack that for now and we'll have to figure out how to change that properly. I wanna just see if it works. I'm not convinced that doing this SD card dance is that much slower, at least maybe I'm involved, but the network boot is not instantaneous. It takes some time to download the files and stuff. All right. It seems identical, but it built again. It's weird that the boot info went. Oh, we got further. That's good. So we can do stuff here. And now let's try our luck with other USB or with actually talking over USB. We got a drive and it did load. I don't know why it's so slow. Maybe because it's gigantic. Microcontroller, print, microcontroller. Actually, let me see if HDMI is going. Looks like it is. Microcontroller.cpu.frequency. So now we wanna see if we have the same problem with the mailbox. So we saved it and it didn't work. A colleague swears by Air Flash Wi-Fi cards and just uses SD to microSD adapters. I haven't bought one yet. Are you sure you don't have too many files on the boot partition? I believe the Pi Foundation put image for all their boards or all the ARM version they use. Might be possible it would be selective and remove some of the blobs. Yeah, that's true. I would believe that, but I, it's a 255 megabyte partition and it's like not super full. Okay, so the good news is the USB seems to be happy, which is the issue that I was having before. So I can do, it's like, makes me feel like we're all the closer. It's just that these video core writes are not working. And I don't know. I'm so surprised by that. Like, I don't know what it is that's breaking my talking to it. It has to be something that I did recently. Like when these break, it makes sense that I'm potentially not recovering well from it. So we can still do, let me eject this. Restream does not like my encoder settings. I don't know what the deal is with it. I'll have to check it after the stream. Okay, so I ejected, so I'm going to unplug that. But then I'm going to do open OCD again so I can see three in an SVD load, peripherals, SVD, JAN, VCN 28, reconnect. Does anyone else have hiccups on the Twitch stream? Twitch is crashy. Yeah, sorry about that. I don't know. I must like have a different setting or like OBS shows that I'm doing a variable bit rate out. So the kilobits per second is changing, which is basically matching what I'm seeing on Restream. And then Restream has a yellow warning that says it needs to be 4,000 exactly, which is new, I haven't seen that before. And the warning goes away if I turn Twitch off. So I don't know, I don't know what the deal is. But now that I know it needs to be 4,000, I'll take a look at it. It might just be set to be variable. I think this is me trying to read something. But this status one makes me think, what exactly am I doing here? Status zero full, we wait. I don't think this is correct. The player is crashing. I'm throwing it off, I guess. So I think that I actually need to check like the different, the statuses might be different. I'm checking the same bits to see if they're full and empty. But I think it's actually two different, I thought it was two different status registers. Be an example. I had the, here's writing to the mailbox. It's only got like the first part. It's all about, oh, well, here's read. No, it's reading, reading and writing mail zero status. Sorry about the Twitch troubles folks. I don't think I had a fixed bit rate before. I thought it was variable before as well. What's funny is I can read it sometimes, but not other times. Can't read it directly, but I can, if I just do this, then it seems to work. Write messages to the video core. What do you think that? Yeah, so for some reason, I wonder if there's an interrupt site on the video core side that's not working. Like somehow we can break that maybe. Why is it the mailbox peripheral? So the mailbox peripheral is the way that you communicate with the GPU firmware that is a black box that is a black box that like Broadcom provides. So it does like clock management and stuff like that. And it's certainly mostly working. Because at the start, which I guess we're not printing out, we were printing out a bunch of stuff at the start about it. Yeah, they like the term mailbox. Mailboxes also have doorbells usually, which is like the interrupt that tells you there's something in the mailbox. It's kind of funny. They love their mailboxes. So I wonder if there's a way for me to fix this. It's broken across. I did see in circle, they do a flush too many tabs. Surprise, surprise. Like this is looking pretty good still. I requested USB PIDs for all this stuff too. I'm excited that we're not having USB problems. That's a start though in circle. It's live. Is our screen updating? Oh, we're in, the debugger's going. That's why something's happening. So let's see how circle does it. Circle has this BCM mailbox. They have a rate read, which is a peripheral entry, which I don't think does anything on the 27.11. There's no such thing as too many tabs. I beg to disagree. So what's interesting here is they have this flush mailbox way back when the boot CPU was in 8051. I don't miss it much. Mew detects the pie as a CPU board very well. Awesome. Yeah, it should just work. So there's this flush write read, which is we're trying to do kind of this write read. So what does flush do? It says if at the start it's not empty, then we read it, we wait a while, and then we see if it's been set to not empty. So let's try that. That would mean that, so maybe like if the timeout was too fast, it's, I really don't like, I never remember what this means. Like there's no boolean here, but I guess it would be the same as, right. If it's not empty, so meaning there's something in it, then we do a mailbox read and throw it away. And in fact, if we get in here, let's do a print and we can even capture it. Because it's probably the, probably the thing we didn't wait long enough for. Doot, doot, doot, SD card dance. I could set it up to do network, but I ordered some extras, but I still haven't gotten my extras. So it's just this one. Miroslav says, hi, Scott, I need to circuit Python, but if I understand it right, you're using just one core of the Raspberry Pi. Is there plan to use more than just one core in the future? Correct, we're just using one core. This is not the first multi-core board that we've done circuit Python on. We also have the RP2040 dual core. Our plan is probably to try to offload the background stuff that circuit Python does on the separate cores. So we probably won't let you create Python to run on multiple cores, but potentially things like MicroLab that have like parallel work could farm it out to multiple cores. But we probably won't do multi-core stuff from Python. I think it's kind of our plan. It's not immediate by any means. Not gonna happen immediately, but if we did add it, that's what we're thinking or when we do. Let's see if we hit this case. I am quite excited that we haven't hit the mystery stuff that I was having issues with before. That is good. Oh, so it works there. So we got a 39 and then nothing here. And it isn't doing the flush. It isn't recovering from the flush. So it works just fine until it didn't work. I like, this is where I feel like I need somebody that's done a lot of work with circuit, not with circuit Python with a Raspberry Pi. This is not kind of fatal, right? Like we can still do a lot of things if this is the case. So it's not blocking, which is awesome. So I'm wondering if anybody's, let me post this build and let me, or maybe we try a non-debug build and see if that works. Maybe that's the thing I was having the problem with. So let's try that just because I'm a masochist. Smaller by eight bytes. Restream's not very happy with me. Maybe these Radeon drivers are not as good. Well, that certainly popped up quickly and it did work again, but then it doesn't work the second time. It makes no sense. And the problem is that now the, the display re-init stuff won't work if we break the firmware. I wonder if it's this clock stuff specifically. So I wonder if we, oh, I don't have the, or the USB going. So it wasn't USB that did it. Oh no. Yeah, okay. Well, it's frozen up with USB plugged in, which is what I was just thinking I wasn't a problem. Yeah. This is exactly the problem I was having before on the zero two. I'm surprised it was working the first time. It must be, this must be a USB problem. Like clearly the stack. Oh, you know what I added? I added dump, dump stack. So I added this thing dump stack to my Cortex-A GDB thing. And what it does is it just goes through all the values on the stack and figures out if there's like a code line for that address. So in the case where the, where the actual stack is not useful at all, meaning it's wrong, like we can still look over all of the values and kind of like try to get an idea of what it actually is. It looks like this is just, I think it's gotta be, it's gotta be something, something bad in the USB interrupt handler. The fact that the USB interrupt handler is causing, like it's coming out of the interrupt that's not working anymore. I wonder if I was thinking about this. It's, it looks like it's corrupting the stack. So what if we in, oh, you can't see that if I do it over there. So in supervisor at the super, no, we want the port supervisor. So we intercept the USB and it, I wonder if we could just put a value on the stack and then see if it stays the same. I guess we need to make sure that it gets put on the stack. Oh, I guess we could do that with C.Elec. Oh, brain, come back brain. In USB here, we have this init hardware. So this is kind of interesting in that these GPIO sets that I have here are technically, I mean, they're writes, they're writes. So it shouldn't be as big of a deal. But what if we just do UN32 equals C.Elec. I think that's what it is. Fort five. And then if the, let's do a while. So if somehow this value changes, oh, and I guess we need to do, because C.Elec is gonna, so C.Elec, I think it's C.Elec, it's C.Elec or A.Elec. It's, we have an example. I do this in the BC mailbox. A.Elec A is what I'm taking up. Yeah, thank you, DCDLK. Yeah, that's what I wanted. So these are your barriers for unsequenced writes. No, so what I'm thinking of here is that I'll, I'll just add a, I wanna add a value to the stack and just see if it gets clobbered. Because if it's clobbered, then the things that are higher up the stack are probably clobbered as well. These set values shouldn't cause reads though. I don't think, let's just try it. It's certainly, it's certainly an interrupt issue that is at some point destroying the stack. Like that's bad news when you just read the stack. So USB, was he, do we try USB with the debug though? I don't know if we did. Is it working debug going? So I don't think it matters where the code is. I think that's a red herring. I think it's, I think it's coming out of the interrupt so that's the problem. Except there it worked. Oh, it worked. Oh no, it loaded. I got the file. Stop doing this temperature one. Oh, and it's still running. Let's try our luck. So import display IO. Display IO to release displays. Import. That fresh zero to W I'm clutching mine with wudishness. I ended up, I have like three more coming because I'm so worried that I'm gonna like brick it or do something to it. So I ended up getting more from DigiKey because I'm not myself. Frame buffer IO. So, oh, and we need video core as well. So we can make a new video core frame buffer with this. And let's go, let's do 1920 divided by two. 1080 divided by two. And then for the display, we do frame buffer IO. Frame buffer display. And that should switch our resolution. What did it do? Oh, well, so it didn't work. Module object has no attribute frame buffer. So let's do video core. So with that, oh no, it's capitalized differently. Not implemented error opcode scene. Oh, that's because we're not throwing an exception, which we should be doing. The problem is that if you plug it in and do this, how do I know whether I can allocate if we can allocate, we can raise an exception, otherwise print it out. And our USB is working. So go figure with that. Although it makes me wonder, I should just try it a couple of times just to see. Let's give this a shot. That would make a lot of sense. It is kind of nice having the video up put in the bottom right so that you can see when it's on and off. That's so different. So funny to me that it says like, oh, they see my tentacle when we know that they're not. It's like, what heuristic are you using and why do you think that's helpful? Oh, look at that. We booted and now we're in widescreen. I don't know why. Oh, interesting. We still got this not implemented error opcode, which is very weird. Heck, does that mean? So what fixed the USB? Well, we are doing some random check. I have no idea. The answer is I don't know what fixed USB. Actually, we don't know USB is fixed because right now I don't have USB going. This is USB UART here. It is interesting that this is saying, this is raising an exception. It could indicate that there's something else corrupting. Like frame buffer display is working, but then printing the CPU temperature is failing. But something is doing not implemented error opcode, which is very weird. It's very weird. So this time it managed to successfully restart. You can see that the display is being restarted. I just wonder if it will keep working. It isn't printing. It isn't printing. Let's plug the USB in and see what happens. Because we were thinking that USB, oh, we got a drive and it opened. Okay, so we're not printing temperature that worked. It worked and yet it didn't work. So that was pulling the frequency. Let's see what happens if we do. So yeah, so now it's not happy again. So that was the frequency call that gave us a problem. And now it's like permanently broken. But I wonder if we restart it, whether the temperature will keep working or not. Like it could be some bug in like their CPU frequency code. We're not doing debug builds. I am printing stuff out. I'm seeing LED's blink. It's a mystery. So with temperature, we're getting this not implemented error opcode thing. Very, oh, it worked there. So if it doesn't work, we get this not implemented error opcode, which maybe it's because we're returning a zero peripherals.com vcmailbox get temperature request. Okay, so we should say if the request doesn't work, aha see, see what? That we don't know why it works and doesn't work. I don't know why it's so picky about bit stream today or bit rate. Hey, Timon. I think at this point it's to the point where we need to just get more people trying it. Like, I forget who it was in the Discord chat that said it would been running for six days. Like, what? Don't feel like it runs six days for me. Not implemented error opcode. I was like, why is it so slow? It's like, oh, it's doing all this display stuff. Just not too bad. If I plug in USB. Oh, do you need testing? It's all weird. So what do we think? Do we, I added that check in this USB thing and it seems to have fixed it. So what do we think? Do we think if I take it back out it'll stop working again? Wouldn't that be swell? Could have it running on a lot of C and fours. I'm so close. I'm so close to being ready to test. That will be my goal next week. So I'm only, it's a short week. So my goal to get the pull request out next week. I think I'm close enough. I just need to go over and make sure I'm not like changing stuff that I didn't mean to. So it looks like USB is working now, which is kind of bizarre. So Patrick says, take it out. So let's take it out and see if it breaks. So what we had here is this Alec A with this check. It was meant to see if we, a timing issue. Yeah. Then put in a sleep. We could also do like a memory barrier. It's possible it's a memory barrier thing. And like this GPIO thing is totally like a people are excited to see. Once I have another spare zero to W, I think I'll set it up to, dude, did you just get it working? I like to think so, but like the last two weeks it's been kind of like this of like, oh yeah, it's ready. Oh wait, no, oh wait. Now I try it and it doesn't work at all. So I'm a little wary, which is also why I'm like, next week, next week I'll get it out and that'll be that. And other people can help me fix things after that. I did actually, when I was testing all the CI stuff the last couple of days, because it's like a lot of downtime, I did so weird, it's like a memory thing. It shouldn't matter though. Yeah, that's so strange. Okay, let me do it one more time and it works. Let's plug it in. It's so close. It's been so close for so long. So it looks like USB popped up. So I don't know what I did. It seems to work now. Is what's on Git supposed to be working right now? Yes, maybe. Does that opcode refer to the VM opcodes? I believe so, yeah. I believe that's a VM opcode that it's complaining about. If it was like a, have you ever blown out a pie? I haven't, I haven't been working with them that long. It's also a matter of which ones I wanna like mess with. So it seems to work. Let's see what our Git status is. So like we have timeout stuff in the SD card stuff, which I definitely think I should do. This port get raw ticks. It does do a read to the system timer. And after reading that warning about mixing peripheral access, makes me want to guard against that in the system. Import here. So where we do get raw ticks? So I think around here we will want a memory barrier. So I'm just gonna do these, the DSB data synchronization barrier. And I'm gonna do it in the SYS system level. It's kind of like the most aggressive tick disabled. Enable IRQ, disable IRQ. Those also need to be guarded. This is so ugly. I think we need one on the entry here. Cause like say you were working in a peripheral and you get an interrupt coming in. This is a read. So you want to make sure that all reads are completed before you issue this, the next read. But then we also have, we actually want a barrier here as well, in case our GPIO. Well like that's just debugging. Ship it and let's open the champagne. Yeah, Christian, if it doesn't work, let me know and I'll try to get everything. I'll issue the service back on Monday. Oh yeah. Okay, so here in enabling and disabling a given IRQ. All this stuff changes with the other CPU versions. This is why I'm targeting just pi three and pi four right now, but let's just do barriers there. Enable, that's a read. See, these are writes and it says not to worry too much about writes, but it's just so... I just can't believe that it's okay to have a CPU that relies on software for memory ordering. Taking it to the limit. Well, I actually tried to, I tried to raise the clock speed and it didn't work. So I'm not sure why it is, so it's not working for you. I can double check that I've got everything pushed. What commit version are you on? Fallow just says, I'm sitting here as a JS developer being like, what is a memory? This is why I like this. So the mind blowing thing here is like, all of this code that we're working in is like under a megabytes worth of code. Whereas like, there are lots of web pages that are larger than that. All right, I'm gonna drop this build if it, yeah, I'll drop this build in the chat and other people can tell me whether it works or not. So this is a zero two W build. Here's the kernel fix stins presence. I think that's it. I do have local changes though. So these are zero two builds. I definitely made the mistake of plugging the... No, you don't need to copy both of those. If you already have a kernel, then you can just do the kernel eight. The kernel eights, if you wanna do the drag and drop thing that I've been doing. It's interesting that we're getting this not implemented error opcode consistently. Like if we do a, it should be in VM. Yeah, see there's this like pi VM, not implemented error opcode. So it is in VM that it's coming from. Yeah, sorry. The, yeah, you'll want depth one on that Broadcom firmware sub module. Sorry. That's the thing that I had to like redo how we get sub modules for our CI to do. Cause it took 10 minutes to download otherwise. It's ridiculous. So yeah, it is coming from the VM. This opcode thing. Why? I don't know. I wonder if our memory is reliable. Like it's possible it's actually like a memory thing. I mean, it works the second time. I don't know. I don't know why that wouldn't work. All right, let's try USB. And let's see. I'll just, if this works, let's go through my changes and now it doesn't work. That build doesn't work. What did I change? 32 gig netbook. Yeah, so this is gonna be like, yeah, it doesn't connect. It doesn't connect until I unplug USB, which is very weird. And then if I had to guess, then once I do, it's here. This is what my stack check was supposed to protect against. Let me take a look at all my changes and see if there's anything I think you actually do need. So one reason I think this could be a problem is that if there's like a USB, a USB interrupt that's not getting cleared, we're basically in the interrupt forever. And for some reason that would hang debug. The UART stuff's been pretty reliable. It's like when you mix in USB that it's been less so. It's like very weird. All right, let's clean this up. USB works including mass storage. Right on that build, but then on this build it won't, for some reason, like should I? So this is interesting, this system core clock. I don't think it really matters. It's not right. So let's just start. This is all timeout stuff. Ooh, this we do want. Let's do that. I'll do this, guard this, guard this, it's all just debugging stuff. And then if we look at what we've done in peripherals. Yeah, like it works sometimes. It makes no sense. All right, so some of this stuff we do want. Let's clean up this interrupt stuff and get it checked in. And this VC mail lock stuff. I guess you can't. Should the thousands in the core clock actually be 1024s? No, I think clock speeds tend to not be base two. Like that. They tend to be even, I think. Yeah, I looked at where that was used and it was just like an if statement for one setting. So I don't think it's necessary. Let's clean up peripherals. Check out dot com gen, SVD gen, get status. Interrupts. I did add the registers for spy and ice grid C because I thought maybe we would want to do that today. But we're actually cruising through our time so we're not gonna get to that. So in interrupts here, let's do, let's get rid of this GPIO stuff because it's not helping me. I was seeing previous interrupts where previous interrupt was 1023 and that was like, it made zero sense. It should never be able to be that value. Let's look better. I just wanna get basically what I have pushed. And before I do that, we should also check the CI. Right, so I put these out of this. Let's remove that print serial REPL. That's a good start. It's good for debugging. BC mailbox, BC mailbox. This is the reason I should get this code in is that if it's not perfect, people can help me figure it out because I have the trying and trying and trying and trying little success. Like I should have a void in front of that. Let's see. All these memory barriers are my version of sleeps basically. Okay, this looks right. So let's do one more build before we commit and push it. And I also need to check the CI. Thank you for testing folks. It's really helpful to have other people confirming or denying that what I'm seeing. Are the docs for this Broadcom stuff publicly available? And if so, where would one find them? 560 says way easier to get going than I thought it'd be USB storage shows up too. Yeah, that's the reason I think this is so interesting is that it's just circuit Python is so much easier than Linux is. This opcode thing is, yeah, so the mailbox, somebody just linked to the mailbox thing. And then you can also find this PDF here that I have this ARM peripherals one. So it doesn't cover everything, but it does cover a lot of the peripherals you're gonna use. So there's that. And the best place I've found for that is here. There's this Raspberry Pi processors page and it has links to these manuals. So I'll post that in the chat as well. That's a really good reference. And I did also get going. Did I try this? It's working. Let's try USB. What do you think? Oh, I'll switch back to, I do not like these USB plugs. Hi, Michael. Am I saying that right? Okay, so I think it stopped. Well, so this build does not work. Yeah, see, so it's hung. And now when I unplug it, then I can connect to the J-Lank. There is actually a video core on the bare metal forums with a pretty good post that links to a lot of resources, including, yeah, let me just show that. So I should find it. It's another really good link. forums.rasberrypi. On here, there's this bare metal assembly language and then there's this bare metal resources. And it's got lots of, it's a bunch of posts and they have good resources. So I recommend that too. So this is so weird. It's so weird to me that I can't connect a debug until I pull it and then when I do. So this is, I think, Christian, I think this is the problem that you had. Dexter says, still no random in the core? Random in this build? No, I haven't added it yet. I think the random peripheral is mentioned. I mean, if you want pseudo random, I could turn it on for you. But the random number generator, are the SW debug pins on the header or configurable to the header? It's J-Link or it's JTAG and they are available on the header. And if you look in the config.txt, it's got the pin numbers on it. This is why I made the hat to make it easier to connect it. We have a pseudo random number generator. Are you, Dexter, are you talking about on the pie build specifically or just in general? Ideally we seed it with a true random number. It certainly has one. I just don't know how to get it. All right, well this build doesn't work on the pie build. I'm printing random characters to the screen. I don't know if I have it on. I can just restart this and see if we can import it. I'll turn it on for you. It should be released right forward. I'm surprised it's not on by default, actually. That import opcode thing. Okay, so there's no random. I'll show you how to turn it on. It's a great thing to do with 10 minutes left. So in this folder, this is the ports, Brog Conf folder. There's mpconfigport.mk and it's got a kind of high level on and offs for things. I'm actually surprised that random is not on here. Oh, wait, here it is. Requires OS. Well, we have OS. Yeah, it's right there. We have digital IO as well. So we can turn that on. Okay, so let me watch. The USB will work with us now. Oh, I should clean. So this is super common. This is the queue string stuff doesn't work correctly after you random online 36, thank you. All right, so we have this will be maybe the last one. I should check the CI as well, actually. Cause if I could fix the CI, I'd be closer to being able to do the thing. Closer to making a PR next week. Any help on these issues would be awesome cause I don't have many ideas. Smaller by eight bytes doesn't seem right. Like I just turned on stuff. There we go. Dexter, do you need this build? And do you want it as an image or a disk image? Kernel image or a disk image? Okay, let's check the CI. Still going? Summary. Status canceled. I don't know. Did I cancel it? I don't think I did. Oh, look at that artifacts. We have artifacts. That's good. I wonder if my older builds. Yeah, so one of these just got stopped. Okay, so our CI is working. Which is amazing. It's still a red X. 99 successful one canceled. If it's functional, it'll catch it up to an image and the last minute touches, there's always those. How do we drop a fresh kernel on there? You just need to copy it to your boot partition. There you go. And let's see. Okay, so let's get this all. Oh, putting USB doesn't work. That's why. How does, that's so annoying. We just need more of the designators to make a PR. It's so close, but it hard-coded that value. It hard-coded the address. How could we change that? It seems wrong. It seems wrong that tiny USB hard-codes an address like that. I'll have to ask Tak about that. I'll just file it. I'm gonna file an issue that has Tak about it. So yeah, sorry, these builds won't work on zero twos. The CI builds won't work on zero twos because the memory address is wrong. I could use the memory map unit to switch it, but I don't take a lot of time. 12 minutes, all these forms. W, USB, and it hangs. 2W, huh. There's no like, what's the problem? PCN 2837. I think it's true. It's that address, 836 as well. I think it might move in the 2035. Look at that. All right, so let's get rid of this. We'll leave it. We'll leave it so my local builds are okay. Change to ports, broadcom, get status, peripherals, double check our diff, memory barriers, memory barriers galore, and tweaks to the mailbox, tweaks to the bits on the UART. I managed to hang it by sending too much over the UART at once, so now we need to fetch origin. Search domain, well, to make sure we're update which we are, get add everything, commit memory barriers, data races, push. This is a little weird dance because we have the broadcom, I have the broadcom peripherals repo set to auto build all of the SVD generated files and stuff. So I actually push here, but the commit I wanna reference in CircuitPython is actually to the build branch. So what it's doing right now is if we go to data fruit broadcom peripherals we should see that there is a push and it's already done, it's super quick. So now what we do is we do a get fetch origin and we check out origin build, main build. And then when we pop out of the sub module we add that new commit and let's just double check. We're gonna ignore the fact that tiny USB is different and trailing white space is never fun. Although we should be able, I think we have a test that we'll just check it. The opcode thing is very strange. It's gotta be like a memory thing. Yeah, see it's a trend of the trailing white space. I don't know why we picked up. Oh yeah, we added an error message. So we need to add locale. Opcode is usually our always malloc memory error. Yeah, so it's like the VM is reading the, so the VM is, the file was read in, it generated bytecode that was stored in memory and then when it was reading that memory back somehow it got corrupted, like it was the wrong value. Oh, and if anybody speaks Russian, we now have Russian support. I'm sorry, I thought it was just pretty neat. So thanks to the person that added to Russian language support. What did I call it? Push to a new rpy. I will continue rebasing this. So heads up for that. It's time for lava lamp simulator. Yeah, so the display IO stuff seems to be working pretty well and you should be able to switch the display size. So let me know how that goes too. All right, so I've pushed that. See what, the CI will run again but the other stuff won't, the zero two builds won't work because of the USB address issue. So that's going, you all should be able to pull it. We're over time, so let me wrap up and we'll call it weekend. So thank you all for hanging in for another deep dive with Scott. It's been another deep dive into the world of Raspberry Pi and CPUs that don't return data in the same order that you requested it, which is mind boggling that that's what they would do. If you wanna support me, you can go to Adafruit.com and purchase some hardware there. Adafruit pays me to do these streams and all this stuff. So thanks to them for supporting CircuitPython for all these many years. If you wanna chat with me and a lot of others you can go to join our Discord server which is the middle box here at the URL adafru.it slash discord. Check that out. Next week is off. So two weeks from now we'll have another stream. I think it's Friday. If you wanna get notified if it does switch from Friday in two weeks time you can ask me on Discord to add you to the deep diver's role. So that just means that I can mention you. So thanks again to Patrick and David for taking notes and organizing those notes into the deep dive repo under Adafruit. And thank you all for trying these builds. I know it's early, I'm excited but I'm also super frustrated at this point because you saw the like it works but it doesn't work and those are the hardest bugs. So you saw me going through that. So it's not uncommon to be in that point and at some point you figure it out and like suddenly everything works a lot more reliably. So hopefully we'll get there. I'm sure we will. But there's other work we can do too. Like I'm thinking about doing I squared C but I wanna polish everything up and get it merged into Circuit Python. And then we can go from there. And I think that's it. Thank you all for hanging out. Have a great weekend and I'll switch to cats and pet both cuties. And if you are trying to follow along and trying to get stuff building, ping me on Discord, I'm happy to help get everything going because you're gonna help me. So I'm happy to get you going. Okay, cuties, have a great weekend everybody.