---
title: "Michael Kefeder (@mkfed) | Hashnode"
description: "Michael Kefeder (@mkfed) writes on Hashnode. Read their latest articles and follow their work."
url: "https://hashnode.com/@mkfed"
---

@mkfed

# Michael Kefeder

@mkfed · Joined October 2022

## Comments

[Omar Hiari you're welcome! No alternative is needed, simply change your Cargo.toml to not use the default features for this crate, it is no\_std compatible, see their documentation. Two options: you either use the amazing cargo-edit and run cargo add num\_enum --no-default-features or add this into your Cargo.toml num\_enum = { version = "0.5.7", default-features = false }](https://hashnode.com/posts/platform-agnostic-drivers-in-rust-max7219-naive-code-refactoring/633b3cc61ba470157763c6ee/comment/63400db7e1c45ecede08843e#reply-6353b425ee1517c87af60c2b)

Reply · Article · Oct 22, 2022 · [Platform Agnostic Drivers in Rust: MAX7219 Naive Code Refactoring](https://hashnode.com/posts/platform-agnostic-drivers-in-rust-max7219-naive-code-refactoring/633b3cc61ba470157763c6ee)

[Omar Hiari You might want to look into num\_enum:: TryFromPrimitive derive macro too, this takes away the manual implementation of the TryFrom trait for going from integer to enum. I am looking forward to the published MAX7219 crate :-)](https://hashnode.com/posts/platform-agnostic-drivers-in-rust-max7219-naive-code-refactoring/633b3cc61ba470157763c6ee/comment/63400db7e1c45ecede08843e#reply-634136ee250857e669efbbeb)

Reply · Article · Oct 8, 2022 · [Platform Agnostic Drivers in Rust: MAX7219 Naive Code Refactoring](https://hashnode.com/posts/platform-agnostic-drivers-in-rust-max7219-naive-code-refactoring/633b3cc61ba470157763c6ee)

[Hi Omar, great write-up! Just a hint for your enum to integer value conversion you can do this with simply type-casting using the repr attribute. This would shorten your code where you pass an enum variant to the MAX7219, because there is no need to match against all the enum variants. Illustrative example: // C style represenation of enum in memory, here u8 #\[repr(u8)\] enum DigitRowAddress { Digit0 = 0x01, Digit1 = 0x02, Digit2 = 0x03, Digit3 = 0x04, Digit4 = 0x05, Digit5 = 0x06, Digit6 = 0x07, Digit7 = 0x08, } fn draw\_row\_or\_digit( per: MaxSpi, cs: &mut Pin<'A', 6\_u8, Output>, digit\_addr: DigitRowAddress, led\_data: u8, ) -> Result<(), AddressError> { let send\_array: \[u8; 2\] = \[digit\_addr as u8, led\_data\]; transmit\_raw\_data(&send\_array, per, cs).unwrap(); Ok(()) } Another thing I'd improve, is in your matches against enumerations that are exhaustive, e.g. DigitRowAddress, most of the time it's better to not match against \_ for any variant, as first of all it cannot happen because you covered all cases already (and the chip wont add new pins during its lifetime) - and second: if somebody added Digit8 to the DigitRowAddress enum, your code keeps happily compiling even though your match block is now broken. At runtime it will error out, but it could already error at compile time which is preferred, especially on embedded systems without visual feedback. The type system of Rust allows many of those compile time sanity verifications and makes embedded programming a joy. Aiming to only allow valid states at compile time basically made me stop using debuggers :)](https://hashnode.com/posts/platform-agnostic-drivers-in-rust-max7219-naive-code-refactoring/633b3cc61ba470157763c6ee/comment/63400db7e1c45ecede08843e)

Comment · Article · Oct 7, 2022 · [Platform Agnostic Drivers in Rust: MAX7219 Naive Code Refactoring](https://hashnode.com/posts/platform-agnostic-drivers-in-rust-max7219-naive-code-refactoring/633b3cc61ba470157763c6ee)