ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to #rust-embedded:matrix.org and logged at https://libera.irclog.whitequark.org/rust-embedded, code of conduct at https://www.rust-lang.org/conduct.html
<rmsyn[m]> well, thanks for the pointers, I'll keep debugging. Maybe trying machine mode, and switching the linker script to point to the start of SRAM will help
<rmsyn[m]> tried this before, loaded the binary into FLASH, but didn't use the SRAM offset
<dngrsspookyvisio> rmsyn: probably Daniel aka CyReVolt 🐢 can help you, he's the resident oreboot expert
<rmsyn[m]> definitely, he's also the author of the support code for the board I'm working on. If he's in here, I would appreciate hearing from his experience working with the board
<dngrsspookyvisio> he's not often around but might react to being @-ed
<rmsyn[m]> true, I've had some interaction via GitHub issues, too. Maybe opening a support issue about build problems would also be a good idea
<rmsyn[m]> removed the disassembly from the repo, moved it to a gist: <https://gist.github.com/rmsyn/b0c49ec84425a750357e2382f07ab058#file-blinky-disasm-s>
Guest7282 has joined #rust-embedded
<rmsyn[m]> ok, awesome got oreboot to flash, and run on the device
IlPalazzo-ojiisa has quit [Quit: Leaving.]
DanielakaCyReVol has joined #rust-embedded
<DanielakaCyReVol> <dngrsspookyvisio> "he's not often around but..." <- I might... or am I?
<DanielakaCyReVol> Uh-oh, looks like work. xD Lemme read up, thank you for poking me! :)
<DanielakaCyReVol> rmsyn[m]: ah congrats - yea the setup so far is a bit wonky, sorry...
<DanielakaCyReVol> I did a writeup in a WIP PR, hang on...
<DanielakaCyReVol> here, in the mainboard directory's README
<DanielakaCyReVol> on that note, I always run oreboot from SRAM for development
<rmsyn[m]> ok, the loader works, but I had to install `vf2-loader` manually. Also, the UART loader doesn't allow for also connecting with another tty program
<rmsyn[m]> so, I ended up copying the `starfive-visionfive2-board.fdtbin` file to a SD card, and use u-boot to write it to FLASH
<DanielakaCyReVol> yea that is currently the easiest way until we have a better tool
<DanielakaCyReVol> I also mention that in said README, for writing a kernel to flash
<DanielakaCyReVol> I had put the VF2 stuff aside for the time being, doing UEFI exploitation at the moment because I really needed a break
<rmsyn[m]> heh, I know the feeling of needing a break
<DanielakaCyReVol> feel free to @ or DM me anytime here or in Slack :)
<DanielakaCyReVol> (Matrix being a bit wonky, sorry if I don't reply sometimes... don't always get notified -_-)
<rmsyn[m]> so, I'm probably going to start working on using the `jh71xx-pac` in `oreboot` to replace the direct register access for the peripherals
<rmsyn[m]> would a PR for that be welcome? Also working on a `jh71xx-hal`, but that crate is much earlier in development
<DanielakaCyReVol> Wait what? Where did that PAC come from? Cool stuff!
<DanielakaCyReVol> Oh you're making it? Yea, I would love to get PRs!
<rmsyn[m]> awesome :)
<rmsyn[m]> yeah, it's been a bit of work, and still going through correcting errors from manually translating offsets from the PDF
<rmsyn[m]> now that I have a running oreboot, testing on the board will be much easier :)
<DanielakaCyReVol> I also have a branch to improve that setup, on that note...
sajattack[m]1 has joined #rust-embedded
<sajattack[m]1> Maybe it should be under riscv-rust?
<rmsyn[m]> @sajattack I'm open to that, but I want to wait until the next patch release at least
<rmsyn[m]> there have been multiple breaking changes since the last release I pushed
<rmsyn[m]> :q
<DanielakaCyReVol> this ain't Vim :D
<rmsyn[m]> lol, or is it...
<DanielakaCyReVol> now I look stupid, thanks
<DanielakaCyReVol> not that that'd be special
<sajattack[m]1> now I look stupid, thanks
<sajattack[m]1> Ah sorry fumbled the buttons
<sajattack[m]1> it's really hard to ping people on fluffychat it turns out. It pulls up a name when you try to at someone and it's impossible to click on it. Anyways I think kvark was asking about bare metal on milk-v mars a month or two ago
<DanielakaCyReVol> ah yea that's the same SoC
<DanielakaCyReVol> if Arace were so kind and after 3 months finally sent me the Mars, Mars CM etc I ordered, I could check if oreboot runs fine (and how to select the boot source etc)
<sajattack[m]1> <kvark> "Hi All!..." <- > <@kvark:matrix.org> Hi All!... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/xsTsqtfKYeLSflhMLkCqtUkZ>)
<DanielakaCyReVol> <sajattack[m]1> "risc-v rust-embedded seems a bit..." <- A little note on that:
<DanielakaCyReVol> When it comes to ISAs used by many chip vendors - such as RISC-V and Arm -, the ISA often plays a minor role. The complexity is really in all the peripheral init etc as you described. And yea, that can get horribly complex. 😅
<sajattack[m]1> yeah it just seems like arm has more critical mass at the moment
<sajattack[m]1> in terms of projects around it
<sajattack[m]1> and chip availability etc.
<DanielakaCyReVol> <jonathan> "Even the C community is struggli..." <- Well, Milk-V offers 3 platforms at least, including the StarFive JH7110 which is actually nicely documented in many ways already and they are doing great with upstreaming, then some CVITek (e.g. the Milk-V Duo) and Sophon (Milk-V Pioneer).
<sajattack[m]1> but yeah the gd32vf103 is a testament to your point
<DanielakaCyReVol> Also the WCH MCUs, CH32xxx, really cool stuff!
<sajattack[m]1> yeah I just got my wch-link but have zero time to play with it
<DanielakaCyReVol> and my favourite application SoC the D1 is such a cool thing
<sajattack[m]1> the reason I mentioned the gd32vf103 is it's a clone of stm32 peripherals with a risc-v isa
<DanielakaCyReVol> sajattack[m]1: oh some WCHs MCUs can even be flashed without an extra board, which MCUs do you have?
<sajattack[m]1> v305 iirc
<DanielakaCyReVol> Ah yea that one needs the WCH Link, I think
<DanielakaCyReVol> I did a demo "OS" for the CH32V307
<DanielakaCyReVol> alright, shleepy time 👋😴
Guest7282 has left #rust-embedded [Error from remote client]
starblue has quit [Ping timeout: 255 seconds]
starblue has joined #rust-embedded
jbeaurivage[m] has quit [Quit: Idle timeout reached: 172800s]
emerent_ has joined #rust-embedded
emerent is now known as Guest5345
Guest5345 has quit [Killed (iridium.libera.chat (Nickname regained by services))]
emerent_ is now known as emerent
crabbedhaloablut has joined #rust-embedded
maxtech[m] has quit [Quit: Idle timeout reached: 172800s]
Noah[m]1 has quit [Quit: Idle timeout reached: 172800s]
Henk[m] has quit [Quit: Idle timeout reached: 172800s]
Guest7282 has joined #rust-embedded
Guest7282 has left #rust-embedded [Error from remote client]
IlPalazzo-ojiisa has joined #rust-embedded
Guest7282 has joined #rust-embedded
Farooq has quit [Quit: Idle timeout reached: 172800s]
FreeKill[m] has quit [Quit: Idle timeout reached: 172800s]
therealprof[m] has quit [Quit: Idle timeout reached: 172800s]
ithinuel[m] has quit [Quit: Idle timeout reached: 172800s]
<firefrommoonligh> Whatup, coding ARMy?! I recall some discussion a few weeks ago regarding changing the interrupt handler fn name API from the `cortex-m` library. The current API for creating an interrupt handler is this:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/JcTiYQmdgUdUJEGseoIinfvP>)
<firefrommoonligh> This is a minor syntax thing, and doesn't affect code architecture, so perhaps it is not worth adding it. But, I think it makes more sense semantically.
Jonathan[m]1 has quit [Quit: Idle timeout reached: 172800s]
<firefrommoonligh> Also, ChatGPT is crushing it in writing macros for me, or modifying them so they accept trailing commas etc
<firefrommoonligh> I think what I don't like about the current syntax is it feels too... magic. As in, the program is extracting which peripheral to use from function name, which is surprising.
<firefrommoonligh> s/./:/, s/As/The/, s/in, the//
<firefrommoonligh> * I think what I don't like about the current syntax is it feels too... magic: The program is extracting which peripheral to use from function name, which normally can be arbitrary.
<dngrsspookyvisio> <firefrommoonligh> "I think what I don't like..." <- Yeah, I've not been a huge fan of the current syntax either. I like your proposal.
<dngrsspookyvisio> I suppose the current state of things has the benefit of a compiler error on naming collision...
bzdula[m] has joined #rust-embedded
<bzdula[m]> Hi, does anyone have any idea what this error means: Frame 0: "No active exception." @ 0x08000188 while using probe-rs with this stm32-hal2 quickstart project https://github.com/David-OConnor/stm32-hal-quickstart
<vollbrecht[m]> dirbaio: if i see it correctly the github releases only include the embedded-hal v1.0.0-rc.3 release and not the once from embedded-hal-async v3 and othere crates ?
<vollbrecht[m]> * github releases of embedded-hal only include
<vollbrecht[m]> * dirbaio eldruin : if, * github releases of embedded-hal only include
<vollbrecht[m]> is that intentional or just an oversight?
Lumpio[m] has quit [Quit: Idle timeout reached: 172800s]
dicklessgreat[m] has quit [Quit: Idle timeout reached: 172800s]
<firefrommoonligh> <bzdula[m]> "Hi, does anyone have any idea..." <- I would double check .cargo/config toml, and memory x
<bzdula[m]> <firefrommoonligh> "I would double check .cargo/..." <- yeah, im working with nucleo-l432kc devkit, so with STM32L432KC mcu, so i changed runner to ``` runner = "probe-rs run --chip STM32L432KCUx " # to list chips, run `probe-rs chip list.``` , rest seems to be okay, thumbv7em-none-eabihf target. Memory.x values seems okay as well...
<bzdula[m]> > <@firefrommoonlight:matrix.org> I would double check .cargo/config toml, and memory x
<bzdula[m]> * yeah, im working with nucleo-l432kc devkit, so with STM32L432KC mcu, so i changed runner to `` runner = "probe-rs run --chip STM32L432KCUx " # to list chips, run `probe-rs chip list.`` , rest seems to be okay, thumbv7em-none-eabihf target and whatnot. Memory.x values seems okay as well...
<bzdula[m]> * yeah, im working with nucleo-l432kc devkit, so with STM32L432KC mcu, so i changed runner to  runner = "probe-rs run --chip STM32L432KCUx " # to list chips, run `probe-rs chip list., rest seems to be okay, thumbv7em-none-eabihf target and whatnot. Memory.x values seems okay as well...
AdamHott[m] has joined #rust-embedded
<AdamHott[m]> Hi All, I'm trying to control the color of a common cathode RGB LED 5 mm on a breadboard connected to a Kitronik Breakout Board, connected to a micro:bit V2. I'm having trouble setting the channels properly and adding a delay. I guess I'm confused on delays in pac vs. hal, and how best to use them. If anyone could tak ea. look I'd greatly appreciate it. Here in my main.rs.
<AdamHott[m]> This is the error I get:
<AdamHott[m]> error[E0599]: no method named `split` found for struct `microbit::nrf52833_pac::TIMER0` in the current scope... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/fHfrUAyxAlDvsIMpQddITHtI>)
<AdamHott[m]> But if I try to change to cc.split() or events_compare.split(), then they don't have channel methods to access the channels of the RGB LED
<thejpster[m]> Can I get a hi-five on https://github.com/rust-embedded-community/embedded-sdmmc-rs/pull/110 from someone please? A PR in which I finally admit there was a bug in embedded-sdmmc and it wasn't just corrupt SD cards - turns out you couldn't create an entry in a root directory that was more than one cluster in length on FAT32.
<AdamHott[m]> hi-five from me!
<thejpster[m]> a high-five in this context, is a code review on the linked pull request :)
<thejpster[m]> I tried to find out where the term comes from, but failed.
<thejpster[m]> I know we have a "Hi Five" channel at work on Zulip, for tagging people when you have a pull request for them. Maybe it's a Mozilla thing.
<dngrsspookyvisio> thejpster[m]: > <@thejpster:matrix.org> a high-five in this context, is a code review on the linked pull request :)... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/BMQqAQOSkakvxXvHvfLQOHDw>)
<dngrsspookyvisio> and/or https://github.com/rust-highfive
<AdamHott[m]> <thejpster[m]> "a high-five in this context..." <- > <@thejpster:matrix.org> a high-five in this context, is a code review on the linked pull request :)... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/pkChDUnKrsEgXhArdRNLgjcP>)
<thejpster[m]> well I'm pretty chuffed I eventually found the bug, so the high-five is nonetheless appreciated :)
<AdamHott[m]> Solving problems in coding if definitely a chuff-ful feeling
<AdamHott[m]> But are you feeling festive?
<AdamHott[m]> I tried to implement the same functionality in a different way. https://github.com/CodingInGreen/microbit_bb_one_led_v2/blob/master/src/main.rs
<AdamHott[m]> I just get this error now
<AdamHott[m]> error[E0599]: no method named `constrain` found for struct `microbit::nrf52833_pac::PWM0` in the current scope... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/WhYlvlpDQLOUTXLQszLdoZKO>)
m3vict[m] has quit [Quit: Idle timeout reached: 172800s]
<thejpster[m]> constrain methods usually come from a trait, and trait methods don't work unless the trait is in scope. Does it suggest a trait you should bring into scope that contains a constrain() method and is implemented on the type of PWM0?
<AdamHott[m]> I think I got it! I didn't initialize pwm correctly!
<AdamHott[m]> I changed it to let pwm_motor = pwm::Pwm::new(board.PWM0);
<AdamHott[m]> and now it builds!
<AdamHott[m]> If this works on the breadboard, then I can write a blog post about it, even though its a very simple example
jr-oss_ has quit [Ping timeout: 246 seconds]
jr-oss has joined #rust-embedded
Guest7282 has left #rust-embedded [Error from remote client]
Guest7282 has joined #rust-embedded
sourcebox[m] has quit [Quit: Idle timeout reached: 172800s]
Mebus[m]1 has quit [Quit: Idle timeout reached: 172800s]
barnabyw[m] has quit [Quit: Idle timeout reached: 172800s]
<thejpster[m]> Now you can make directories. This is one of those places where FAT16 vs FAT32 will catch you out - on FAT16 the ".." dir entry has a cluster value of 0 if its parent is the root directory. Otherwise, and on FAT32 it's the cluster containing the parent directory.
<thejpster[m]> Also, you have to erase the whole cluster containing the new directory, because some FAT code will keep going past entries that start with 0x00. Quite by co-incidence my test code was overwriting an old file that used to contain just 'a' characters, so I had weird directory entries like 'aaaaaaaa.aaa' multiple times.
Guest7282 has left #rust-embedded [Error from remote client]
<dngrsspookyvisio> [AAAAAAA](https://en.uncyclopedia.co/wiki/AAAAAAAAA!)
<danielb[m]> <dngrsspookyvisio> "[AAAAAAA](https://en.uncyclopedi..." <- i wrote code like this recently
jessebraham[m] has joined #rust-embedded
<jessebraham[m]> <dngrsspookyvisio> "[AAAAAAA](https://en.uncyclopedi..." <- Love this
IlPalazzo-ojiisa has quit [Quit: Leaving.]
henrik_ has joined #rust-embedded
crabbedhaloablut has quit []
crabbedhaloablut has joined #rust-embedded
Guest7282 has joined #rust-embedded
crabbedhaloablut has quit [Client Quit]
crabbedhaloablut has joined #rust-embedded
crabbedhaloablut has quit []