cr1901 has quit [Read error: Connection reset by peer]
cr1901 has joined #rust-embedded
dne has quit [Remote host closed the connection]
dne has joined #rust-embedded
Guest7221 has joined #rust-embedded
cr1901 has quit [Read error: Connection reset by peer]
cr1901 has joined #rust-embedded
cr1901_ has joined #rust-embedded
cr1901 has quit [Ping timeout: 272 seconds]
<thejpster[m]>
I came across https://github.com/kusstas/sdmmc-spi today (which is also on crates.io). As it appears some of it is lifted from my crate, I kindly asked the author if they could include my copyright notice as per the requirements of the MIT and Apache-2.0 licences. AITA?
<dngrsspookyvisio>
<thejpster[m]> "I came across https://github.com..." <- on that note, what *is* the right way to include licensing info if you, say, copy paste a few functions into an existing source file?
aerasto[m] has quit [Quit: Idle timeout reached: 172800s]
<thejpster[m]>
I am not a laywer, and this is not legal advice - but do what the license says you should do.
<thejpster[m]>
s/laywer/lawyer/
<thejpster[m]>
> The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
<thejpster[m]>
So ... I would just add their copyright notice next to your copyright notice in your MIT license file, and I guess in your Cargo.toml.
ryan-summers[m] has quit [Quit: Idle timeout reached: 172800s]
<thejpster[m]>
The license doesn't require you to specify who holds copyright over which parts.
<thejpster[m]>
It is perhaps open for debate as to whether a binary constitutes a "substantial portion of the software" or if the license is only talking about forms of source code. But I would say it is fairly clear that the copyright of the thing that comes out of a transformation (e.g. binaries) is the same as the copyright of the thing that goes into a transformation (e.g. source code). So you should probably list all the copyright notices
<thejpster[m]>
when you ship a binary that includes any MIT licensed code. But I suspect basically no one does.
<adamgreig[m]>
the rust copyright is so so confused
<adamgreig[m]>
it really seems like every rust program needs to ship with an awful lot of copyright notices
<adamgreig[m]>
since a bunch of rust and llvm ends up inside your program, and it doesn't have a special license exemption for those parts
<adamgreig[m]>
(obviously to say nothing of the crates you pull from crates.io and whatever their licences are)
<adamgreig[m]>
this occasionally comes up on the issue tracker and it's so monumentally hard to work out that last time I saw anything it sort of quietly fizzled out
<thejpster[m]>
I use cargo license and assume the authors field is an adequate proxy for the copyright notice
<fu5ha[m]>
<thejpster[m]> "Also, I pushed out 0.6.0 of..." <- I haven't used the crate in anger yet but fwiw the new api looks pretty nice reading the new examples, so I'd say shipit if you think it works better
<thejpster[m]>
I think it works better for most people; but not for me. Because I persist file handles in a static structure, I have to use the raw handles.
notgull has quit [Ping timeout: 245 seconds]
notgull has joined #rust-embedded
<dngrsspookyvisio>
<thejpster[m]> "The license doesn't require..." <- strictly speaking I'd need to add line number ranges then… I've never seen this done anywhere
<dngrsspookyvisio>
(to be clear I don't wanna dodge a license, but it's so confusing to me how to properly attribute parts cobbled together)
<dngrsspookyvisio>
oh wait, I misread
<dngrsspookyvisio>
doesn't
<thejpster[m]>
I read into this some more than there's a difference between a joint authorship, and a work combined from multiple authors.
<dngrsspookyvisio>
that's ... better :D
<dngrsspookyvisio>
(what I've done in my case is make it a module and put the original LICENSE file in the module directory, but that's not so easy when you add stuff to an existing source file)
<thejpster[m]>
And US and UK copyright law considers these differently. So it's basically a mess.
Guest7221 has left #rust-embedded [Error from remote client]
mameluc[m] has quit [Quit: Idle timeout reached: 172800s]
sourcebox[m] has joined #rust-embedded
<sourcebox[m]>
The serial traits have been removed from e-h, instead embedded-io is recommended. So far, so good, but what about the ErrorKind definitions? I don't see any error variants for parity, framing, overrun there, so what to use as replacement?
<dirbaio[m]>
io is for general byte streams, so there's no uart-specific errorkinds
<dirbaio[m]>
recommended implementation is:
<dirbaio[m]>
- define your own Error enum, with the uart errors
<dirbaio[m]>
- implement embedded-io Error on it, to translate to ErrorKind.
<dirbaio[m]>
the Uart-specific errors should probably be translated to ErrorKind::Other
<sourcebox[m]>
That's a solution, but I thought the idea behind all that is to have a set of standard error types that every HAL and it's users can rely on.
<dirbaio[m]>
well, ErrorKind is not intended to be used as an error itself, it's just an "error kind"
<dirbaio[m]>
since introducing it, the idea is HALs have their own error enums for the exact errors the hardware can do, and they impl Error
<dirbaio[m]>
so generic (hal-independent) code can ues Error::kind() to "inspect" the HAL-specific error in a limited way
<dirbaio[m]>
only down to a standardized list of kinds
<dirbaio[m]>
many HALs have taken the shortcut of setting type Error = ErrorKind to avoid having to make their own enum
<sourcebox[m]>
But e.g. for I2C and SPI it's still kept from previous versions and the error variants match reality quite good.
<dirbaio[m]>
but that's not the ideal way
<dirbaio[m]>
i2c/spi error kinds are kept because they're i2c/spi specific
<dirbaio[m]>
for uart, we've completely dropped the uart traits
<dirbaio[m]>
in favor of embedded-io
<sourcebox[m]>
Arent UART-specific errors in the same boat?
<dirbaio[m]>
but embedded-io is not intended to be just for uart, it's an "std::io for embedded" in general
<dirbaio[m]>
it can be used for uart, a TCP socket, a unix pipe, a file...
<dirbaio[m]>
so it doesn't make sense to add uart-specific errorkinds there
<sourcebox[m]>
Ok, I have to accept that, although I don't really get the motivation behind it.
<dirbaio[m]>
motivation for having io traits for all kinds of io, not just uart?
<sourcebox[m]>
Motivation to make UART special compared to SPI and I2C at the cost of losing easy-to-understand interoperability.
<dirbaio[m]>
on the contrary, we're making uart not special
<dirbaio[m]>
on an uart all you can do is read bytes, write bytes, which is exactly the same as a tcp connection, a pipe
<dirbaio[m]>
so they're all merged in a single trait
<dirbaio[m]>
fwiw linux and other OSs merge them like that too. if you open a serial port on linux, you get a file descriptor where you do plain old posix read(), write() on it
<dirbaio[m]>
vs spi/i2c are different, you don't just "read bytes, write bytes", you do transactions and other special stuff
<dirbaio[m]>
on linux spi/i2c are not regular file descriptors you do read/write on them, you have to use magic ioctls to do spi/i2c transactions
<dirbaio[m]>
that's the reason we're treating uart different, it does fit the embedded-io model, while spi/i2c doesn't
<dirbaio[m]>
and merging is good
<dirbaio[m]>
because it allows things like running a CLI shell over either a hardware serial port or a TCP/telnet connection, for example
<sourcebox[m]>
I get that, but the errors need to be more specific, otherwise they're not easy to handle.
<sourcebox[m]>
ErrorKind::Other is quiet pointless.
<dirbaio[m]>
you can handle them in hal-specific code by inspecting the hal-specific enum
<sourcebox[m]>
s/quiet/quite/
<dirbaio[m]>
in hal-independent/generic code you can't, yes
<sourcebox[m]>
That's what I wanted to say.
<dirbaio[m]>
yes, that's the tradeoff
<dirbaio[m]>
are you writing a hal-independent driver that needs to distinguish between e.g. framing and parity?
<dirbaio[m]>
what is the use case for that?
<dirbaio[m]>
the theory was that needing this would be rare
<sourcebox[m]>
My driver e.g. passed the error to the caller, which is maybe interested in what happend exactly.
<sourcebox[m]>
s/passed/passes/
<dirbaio[m]>
you can do that by passing the struct as-is
<dirbaio[m]>
* passing the error struct, * struct` as-is
<dirbaio[m]>
* passing the error struct as-is
Guest7221 has joined #rust-embedded
<sourcebox[m]>
But in this case the error is still unspecific.
<dirbaio[m]>
just use generics. you don't know the error type, but you can still pass it up
<dirbaio[m]>
and the caller, which knows what hal they're using, can inspect it
Guest7221 has left #rust-embedded [Error from remote client]
d3zd3z[m] has joined #rust-embedded
<d3zd3z[m]>
The rp2040-boot2 crate's readme, when wanting to have the boot2 bootloader copy the code into RAM, that one should modify the linker script for the .text section. I haven't been able to figure out where the linker script is coming from. memory.x seems to just be a snippet of it, and I'm not sure where the final one is coming from.
ragarnoy[m] has quit [Quit: Idle timeout reached: 172800s]
<dirbaio[m]>
> To work correctly ThreadSanitizer needs to be "aware" of all synchronization operations in a program. It generally achieves that through [...] and compile time instrumentation (e.g. atomic operations). Using it without instrumenting all the program code can lead to false positive reports.
<dirbaio[m]>
and it uses -Zbuild-std ... of course, std has to be instrumented
<dirbaio[m]>
and indeed adding -Zbuild-std fixes it...
<barafael[m]>
yikes, embassy is cool. Am on RP2040, just got serial USB on one core and normal app on other working nicely...
<barafael[m]>
* working nicely... in a short train ride
<fu5ha[m]>
I'm regretting my decision to put both my SD card and display on the same spi bus on my hardware design because I could in theory do similar if I had used both spi peripherals on the rp2040, but it's too late to change it now (for this revision at least) unfortunately
dsvsdveg[m] has joined #rust-embedded
<dsvsdveg[m]>
Hello everyone ihope all doing good
<dsvsdveg[m]>
I'm in my latest year electronic engineering student
<dsvsdveg[m]>
We will have a latest graduate project in my next semester
<dsvsdveg[m]>
And i'm looking to work with Rust for my graduate project
<dsvsdveg[m]>
Has anyone worked before or are already some open source hardware wallet?
<dsvsdveg[m]>
built in rust ofc
<dsvsdveg[m]>
And of course if anyone can suggest for me a idea project it would be greats
<dsvsdveg[m]>
and STM32F4 is really worth it for hardware wallet?
<dirbaio[m]>
> I personally use a wallet made from leather. Not sure why I would need a microcontroller in my wallet (well, apart from the one built into the debit card and such).
<M9names[m]>
Sorry, you're also making a custom microcontroller?
<M9names[m]>
Or does mcu have some other meaning in the domain you're working in?
<dsvsdveg[m]>
M9names[m]: I'm thinking making a custom micro cpu that generate the random public & private key. Is it bad idea? I know that ledger have their own micro cpu for gen random
<dsvsdveg[m]>
basically this project doesn't require a mcu
<danielb[m]>
it sounds like you want to create an ASIC to generate a key for you. I assume this isn't the case and there's a bit of language barrier instead
<dirbaio[m]>
ledger doesn't use a custom mcu, they use the stm32wb55 which is an off-the-shelf mcu available to anyone to buy
<dirbaio[m]>
perhaps you're confusing the terms
<dirbaio[m]>
"mcu", "microcontroller", "micro cpu" are all the same, it's the physical chip that runs your firmware
<dsvsdveg[m]>
mcu and micro cpu are different thing i means
<dirbaio[m]>
mcu = microcontroller unit
<dsvsdveg[m]>
yeah microcontroller basically have more component compared to micro cpu which only have cpu
<danielb[m]>
but you don't only need a cpu, you need memory, a random source and some interface to communicate 🤔
<dsvsdveg[m]>
microprocessor and microcontroler imo
<dsvsdveg[m]>
danielb[m]: yeah, but i want to go into it step by step
<dsvsdveg[m]>
Where to start exactly? can anyone suggest me something?
<dirbaio[m]>
all modern "cpu chips" are essentially microcontrollers, they contain the CPU and peripherals to talk to the outside world (gpio, uart, spi, i2c, rng...)
<dirbaio[m]>
nobody manufactures "pure" microprocessors anymore ("microprocessor" meaning just the CPU with no RAM or peripherals)
<dirbaio[m]>
since the 90s
<dirbaio[m]>
* CPU and RAM and peripherals to
<dsvsdveg[m]>
dirbaio[m]: isn't a microprocessor that ledger is using for generate random key?
<dirbaio[m]>
which chip, where are you reading that
<dsvsdveg[m]>
dirbaio[m]: oh they use st31h320 , sorry i tought they are using microprocessor for this task
<K900>
People are still making 68000s for retrocomputing
<dirbaio[m]>
st31h320 is a microcontroller :)
<dsvsdveg[m]>
dirbaio[m]: yes, i was thinking they use custom micro processor
<dsvsdveg[m]>
so where i should start please?
<dsvsdveg[m]>
How i should design my hardware and where to start about it ?
<K900>
Figure out what you want it to do
<K900>
Figure out what components you need for that
<dsvsdveg[m]>
basically this is how ledger is built
<dsvsdveg[m]>
ledger nano S
<dsvsdveg[m]>
<dirbaio[m]> "st31h320 is a microcontroller :)" <- you have experience in hardware wallet?
<mameluc[m]>
how does a hardware wallet work?
<mameluc[m]>
I mean what is dsvsdvegs definition of a hardware wallet. what does it need to do
<dirbaio[m]>
it stores the private key. You can't read it out, you can only ask it to sign transactions
<dirbaio[m]>
the idea is you're protected from losing money even if your host computer is completely compromised
<M9names[m]>
<dsvsdveg[m]> "so where i should start please?" <- this is your project right? i don't know why you're leaning so heavily on other people to tell you what to do.
<M9names[m]>
also: don't just blindly copy what other folks/teams/orgs do, understand why they do it and decide whether it makes sense for you. otherwise you're just making more work for yourself.
<M9names[m]>
look at what's involved, pick a direction, and go. if other people do all the thinking for you you're kinda missing the point of doing your own project.
<mameluc[m]>
sounds like an interesting project. maybe something like microchips atecc608a could be used
<mameluc[m]>
as a first project get your lcd working, then usb
<mameluc[m]>
after that start thinking about the more complicated parts
<mameluc[m]>
maybe find a nice devkit with the stuff you need
<dirbaio[m]>
as a 1st version you can also choose to do everything in software inside the MCU, too
<dirbaio[m]>
lol volatile-register 0.2.1 was already released on crates.io but is not in the repo
<dirbaio[m]>
I just bumped the repo 0.2.0 -> 0.2.1 and tried to relese..