Make invalid states unrepresentable.

Lol... concur. You should never get to that part of the code, but agree that maybe the error message isn't great XD

It would totally be possible to enter that code path since the function accepts a u32 and not like an enum or something, but yeah I totally hear what you're saying. But you know what they say...one good error message is worth 1000 GitHub Issues 😅

In my opinion this error shouldn't even exist. The function type signature indicates it takes in a `u32`, but it really doesn't. It takes in a `Pin`. In most languages you'd blindly take in a u32 and throw an exception when it's out of range (which is conceptually what we have with that `panic!`). That's terrible practice. In any language that has a decent type system, there is no reason not to use total functions everywhere. It was incredibly frustrating to watch this video because the code that was written isn't Rust; at its core, it's a C program with Rust syntax slapped on.

@@emilien.breton all these languages but you choose to speak with the truth lmaoo

@@emilien.breton I agree, I’d probably pass in a enum variant of Pin.

Agree, embedded processors have dedicated instructions and registers so you can toggle or set specific bits in one go, using read modify write slows it down significantly.

I came here to say this - as you say it's right there in the data sheet shown in the video - you don't need to mask the bits that you're _not_ setting, specifically to avoid a RMW operation.

I also came here to say this, I see I’m a year too late though 😂

"bug" this is so funny, i dont use rust but it looks like you're creating problems that don't exist, it falls onto the developer to put a existent pin number and the way i see it would be a constant anyway that can then be used in some kind of assertion test, its not like it will use pin numbers given by the end-user or something.

In the STM32 crates I've seen, they do exactly that one type for an uninitialized pin, one for an input pin, one for each kind of output pin..... "make invalid states unrepresentable".

It takes time! You'll get there.

@@LowLevelLearning Thanks for the encouragement :))

In the works!

@@LowLevelLearning I'd love that! Great follow up video, but I am also very happy you made these "mistakes" in the first one! Great way to build up and show what is the idea behind Rust, to abstract these unsafe interactions into a safe(r) interface. Can't wait to grab my little RaspberryPi once I finished moving and follow these videos again hands on :)

@@LowLevelLearning ETA? I am a rust beginner and I want to get into embedded. This would be awesome.

In the current case probably none, but note that some chips have multiple GPIO peripherals at different addresses and you'll probably want something like the struct to help model that.

Later on, the functions shown in the video could be moved to a trait, which the zero sized struct could implement.

@@BambeH this makes sense with what @Peter Hansen said

Crap I totally missed that. Thank you!

Thanks, I was thinking "Why did Rust make that change from C?"

In rust '!' *is* the bitwise not when used with integers. It's only logical not when used with booleans.

I do wonder if Rust will ever use ~ as bitwise not as I believe the original reason it wasn't is that in the early days of rust ~ was to box objects.

@@JeffHanke what?? why would rust do this? i guess it isnt C but still..

No problem!

It's optimized by LLVM which probably has inlining conditions documented somewhere

In my experience rust almost always inlines small functions, especially if they are used only once. This would be controlled generally by the optimization level (O3 for fastest code, more inlines, Oz for smallest code, less inlines) and by #inline[always/never] attribute on a per-function basis.

That is the idiomatic way to do it.

I'm not him but I feel like those videos are specifically to do stuff "from scratch". He even says at the beginning that he's going to build a PAC in the video which would be the basis for a HAL.

So you would have to worry about concurrency if there was any actual multithreading code in this. There is not

This is kernel code, so it is in full control of what runs when. Threads are not a concern until you write the threads into existence!)

Based on how I understand it, the refactoring *Low Level Learning* has done here is meant to the reduce the amount of code inside of an unsafe block, because, when you put code in the unsafe block, you are telling the Rust compiler that you know what you are doing and thus it *doesn't need to check for violations of the **_memory management rules_* typically imposed on Rust code. Because Rust's memory management rules that the compiler forces you to follow are there for a reason (and is a selling point for Rust in comparison to other Low-Level programming languages like C or C++), you typically don't want to use unsafe blocks unless if you _really_ have to (like reading or writing volatile data, which is typically a memory violation under the memory management rules but is crucial in Embedded Systems Programming). If there is too much code inside the unsafe block, especially if it is doing more than just simply reading or writing data to a volatile memory location, then there is a chance that there might be problems regarding memory that Rust will simply ignore - *defeating the entire purpose of using Rust of all languages.* Thus, it is important to only use unsafe blocks _just_ for reading or writing volatile data and nothing else. Otherwise, you are creating problems you could easily have avoided. (Not to say that the refactoring could've been improved to make the code more readable or easier to debug). (If I am wrong (_and I might be, since I am new to Rust_) about something I said, let me know so I can correct it.)

You bet

Haha shit fixing my typo removed the heart from the comment 😂 But whatever now it says correctly struct instead of strict

uhhhh maybe look into rust enums??

@@finnmonstar Sure. If I wanted to learn about Rust. However, I only wanted to point out a possible direction based on the language I know, in case there is something equivalent in Rust.

@@sledgex9 I do not know that much C++. Maybe I can help you with C features, but I know nothing about the former. The language is too bloated and complicated for my taste. Anyway, tell me the features "enum classes" have in C++. Maybe I can help you with feature parity across Rust and that language you mentioned.

@@finnmonstar In C++ "enum" doesn't create a strong type (for a lack of a better word). Enum values are implicitly converted to/from ints when passed around. You can even accidentally pass the value of the wrong enum type into a function that expects another enum type and the compiler will happily accept it. However "enum class" (or strongly typed enums) don't allow for implicit int conversion nor do they allow you to pass the wrong enum type to the function. The compiler catches those errors. Since Rust is more new I assume that its "enum" will behave more like "enum class". It wouldn't make sense for Rust to adopt the old C/C++ style of enums.

@@sledgex9 You are right about that. In Rust you need to convert everything to the right type, even 32-bit integers to 64-bit ones.

Processors don't allow you to write just one bit. If want to ensure that you're only changing the one but you care about then you need to read in the whole word; make just the specific change you want to that value and then write that "surgically" modified word back.

@@adrianbool4568 The GPIO_SET and GPIO_CLEAR registers are special write-only hardware registers, this is not actually a memory address that would persist. By writing a full u32 value with just one bit set, you are effectively just setting or clearing that one pin without interfering with other pins.

@@animowany111 Oh, OK, thanks for letting me know! Sure makes the code easier & safer like that!

Start with C in my opinion. Rust is awesome but you need to know a decent amount about programming for it to make sense. C has far less abstractions

@@LowLevelLearning Cool, thanks mate.

You could have two wrapper functions and then call a private function with your enum variant passed in.

@@tagged5life yes thats possible but I don't really see the point. It's basically like a setter method for an enum field. Why would you make an extra function for each variant? You could also use a bool.

Good idea!

no_std :(

​@@LowLevelLearning Ah of course 😄Maybe the core::arch intrinsics used to implement it for your specific platform? I'm not familiar enough with Arm to tell if it's supported though

@@LowLevelLearning core::hint::spin_loop exists

Correct target name is aarch64-unknown-none

@@paulsimon1494 yup. thanks

Yea

@@LowLevelLearning Noice

more smaller blocks with limited scope > one big one that could be doing anything also after the cleanup it's clearer what the code is doing

49999, because 1..50000 it includes neither 0, nor 50000

You concentrate the unsafe code in a few, marked locations. The rest of the program can then enjoy the benefits of rust, and you know where to look if you encounter weird behavior.

Rust is Ada for the 21st century. ;)

I think that's mainly down to the added support for any pin number rather than original's operation only on PIN 21. The arithmetic does get a little messy. I guess that is what encapsulation is for.. :-/

I have, and I helped write the code from the stream where we work shopped the example code. Zig is fine, but the DX is trash and the documentation is balls. Rust wins over zig for me but I'll still give it a chance in the near future as an exercise in futility hahahah.

zigma balls lmaoo

No, but it is like putting a roll cage on one. Useful, but only an incremental change.

Yes Jesus 🙏

LLG 5Life

which then makes it easier to debug individually rather than as one whole swathe of danger

Isn't that the definition of abstraction?

*Chefs kiss*

:O Mark THANK YOU AGAIN my guy holy crap. Seriously this is so generous

@@LowLevelLearning This directly helps me. I'm working on a Time Clock for one of my customers. I've done it with a Raspberry Pi (In C) with Raspberry Pi OS and an RFID reader. Having to buy RFID keys has been come a pain so I'm going to do it with a PICO and a finger print reader next. At this point I might as well write it in Rust and I'd love to write it from the ground up. Plan is to have the code MIT licensed once I'm done with it as it's not a competitive advantage for me to keep the code a secret.

Sure but then you’re destroying any state that was already there, which would suck if you want to use multiple pins on the same port

🤔

well atleast the whole logic is not unsafe, and you can find memory bugs easier i think

@@finnmonstar that's fair enough!

Amen, have you tried flashforth for embedded ?

I'll have to give it a try!

C will live forever

@@memcpy yeah, and mecrisp forth for ARM make it easy to turn off and on gpio pins

It’s been ages that I’ve used it. And it was quite hard to learn for a C/assembly programmer. But when you grasp the concept of “everything goes over the stack” it clicks.

C++. The simple stuff compiles just as small, but then it gets cool!

no u ha gottem

Rust's zero size struct semantics are not the same as an abstraction like C/C++ with AVR dude.

@@rallokkcaz but now he has to calculate a bunch of masks instead of pasting at the memory location directly. As this code seems to only target the 21 pin, it ends up wasting more CPU cycles (unless the compiler already precalculates those values before the function call, which I doubt it does).

@@softwarelivre2389 LLVM can easily inline simple calculations when all inputs are literals. It can even compute the result of a function at compile time and inline the result.

@@saadisave yeah, that I know, but as this is not a pure function, and it does memory allocations in its body, I don't know if that will be optimized beforehand or not in this context. If it is, then disregard my comment.

@@rallokkcaz It's not about struct. Is `register = match reg ` zero cost abstraction?

Since hundreds of libraries exist already for C it would've been even easier. Instead he's writing it from scratch in a language which treats him like a baby and loses most of its proclaimed advantages at that level.

@@anon_y_mousse not only that, even if you're in a system where no libraries exist or you cant use any libraries for whatever reason, C gives you no limitations and does not treat you like a baby, so as you said, all advantages that rustaceans claim are lost at that level.

@@AlFredo-sx2yy i'll bite. What advantages are lost at this level? The only difference from C that I can see is needing to actually say "unsafe" when the thing that you're doing is unsafe. Also he doesn't actually use the rust features that would be used by a library author writing a hardware abstraction layer in rust. For example rust can prevent using nonexistent pin numbers or reading output pins/writing input pins at compile time with 0 runtime checks, haven't seen that in C. He also gets a big chunk of libraries if he needs them, and all others if he writes a heap allocator.

@@d3line the "advantages" provided by rust are lost when you try to go this low level lmao..... i thought you had watched the video? You havent seen C detect nonexistent pin numbers because you havent seen proper C code then. That's something that YOU have to program, the fact that Rust provides this out of the box for certain architectures doesnt mean shit, because good luck finding a build target for all of the architectures you can find lol.... Christ the shit i have to read i swear.

@@AlFredo-sx2yy 1) *which* advantages are lost? You keep exasperatedly saying that some nebulous advantages are lost without defining what, in fact, is lost. 2) I haven't seen stuff like compile time const functions in C because they don't exist in C, yes. C has no way to prevent you just using pin number 12345 except runtime "if" check. Rust can do this at compile time (not shown in video). 3) I'm not talking about using some magic from rust's platform support, you can code it yourself by using rust's type system, and provide your users with un-misuse-able API at no runtime cost. That's a rust advantage, and I don't see how it is in any way lost when programming for embedded devices. Also please chill...

you make yourself sound so incredibly uneducated with the last paragraph that your (entirely valid) former paragraphs are out of the window.

@necauqua You posted some really helpful information. I have a lot of experience in Rust and C, have been lucky enough to work on very difficult problems throughout my career and have led a lot of engineering teams. I say this mainly because its given me exposure to engineers with all types of communication styles. Its obvious to me that you were trying to be helpful by posting a rusty approach and a clean interface that takes the reader into account as much as the runtime. Your approach was solid and I think you wrote it in good faith. Because of that I want to post some constructive criticism for you, also in good faith. 1. It appears you don't know how to use "lol". As it stands, your comments come off as extremely self-important and patronizing. If you remove the "lol", then your statements are just blunt but not necessarily malicious. You seemed to use "lol" to punctuate important points but, unless you're trying to alienate your reader, I recommend you abandon "lol" entirely. You can also try replacing them with exclamation points or clarifying questions. 2. Your classification of embedded is limiting and elitist. Also, you're categorically wrong about "proper embedded". Embedded systems are simply units, within larger electrical systems, that have a processor, memory, and Input/Output capabilities for peripheral devices/components. In this video and the last, he replaced the OS with some kernel code and fed it to a bootloader. All he used on the physical board was... the processor, memory, and I/O pins. Maybe you'd rather he use an STM32 or some other MMU-less MCUs and spend half the video walking us through a circuit diagram. But there are already thousands of videos covering that for people who know where to look and what to look for. Maybe a big reason this video focuses on raspberry pi's is because the boards are versatile and ubiquitous. You can have a desktop machine or just a processor, memory, and I/O. An embedded approach to raspberry pi is much more inviting than the same video with an STM32 or something. Engineering, as a practice and discipline, is about trying to accomplish what you want with what you have. That's it. Everything about "proper" and "the right way" is just pedantic and frankly signals that the person has spent a lot of time in a narrow field, academia, or has little experience outside of their chosen discipline. If an engineer insists on a solution without bringing up trade-offs, alternatives, and cost benefit analysis, then 99% of the time they're just reciting dogma they read/heard or used to solve a problem in the past. Like I said, it is obvious to me that you were trying to be helpful. I don't mean to be rude, only clear. You mentioning "Make. Invalid. State. Unrepresentable!!!!" up front made it obvious to me that you have experience in this field; that you care about attention to detail, correctness, and stability. All of these are great qualities that are really hard to find. If I were hiring an engineer, you'd be a desirable candidate. If I were looking to assign a mentor, you'd be on my list. But your tone is very condescending and abrasive. You know so much that you assume the way you know how to do something is THE way to do it; You forget that much of what you've learned is just another engineer's opinion or ideology. An opinion that another engineer taught THEM and is either outdated or will likely become outdated. I could be wrong, but you sound like a student or a junior engineer that's very passionate about the subject but hasn't really been exposed to a variety of systems and problems. Regardless, here's my parting advice: The way you communicate just negates the value of the information you try to communicate. And people will opt for getting that information elsewhere. The hardest thing about engineering is having to collaborate with other humans and navigating the social nuance that emerges when solving difficult problems. Every tool you've mastered, or want to master, was built by a group of people that worked well together. I believe you have a lot to offer as a teacher or collaborator. It seems like you want to help and share or at the very least contribute. If that matters to you at all, consider asking people more questions and making less assumptions before proposing a solution. Technological systems are built in the context of social systems. Communication skills will serve you well in social systems. I think practicing them will go a long way and you'll even enjoy it as you get better. BUT If you're just a troll and like to feel superior to others or self-important then... carry on and ignore my comment; it was meant for somebody else haha

@@minimalhostage Nothing but respect for the respectful way you phrased that; I don't have that in me but I commend it nonetheless Charles💯

@@minimalhostage wow this was very detailed, thanks I mean I'm just used to be kind of rude/patronizing as you've said - because this is the internet and way more commonly you encounter obtuse people than good helpful people like you - and your approach also sounds kind of more 'formal' than I would've liked it to be - this was meant to be kind of a rant and I was annoyed (why? idk really actually, maybe it was elitism indeed, 'oh they learned some rust and sharing their incomplete knowledge') by some things in the video. Also non-native english I will edit some of my comment, everything you said is absolutely valid It is funny how one can hate something in others yet express it themselves to such an extent, thanks for opening my eyes - I really don't like elitism and static unchanging ideologies and when someone thinks some one thing is 'proper', yet I said exactly that huh Still hate that something that runs an OS is called embedded, but looks like my notion of 'embedded' was just invalid :)

@@bartpelle3460 while I removed the paragraph as it was really poorly worded anyway indeed - I did think (oh well maybe this was wrong the entire time) that embedded is when you run something on a 'bare metal', w/o an OS - and raspberry pi's being a full-blown arm computers with linux installed were out of this definition - yet every youtuber seems to do 'embedded' with raspis. Although after the explanation from Charles it seems that if you run some code _in place_ of the OS, as it's done in this video - it is indeed embedded - I was under impression of some other youtubers doing like a blinking gpio led with like a python script running on that arm linux on raspi.