<re_irc>
< (@almindor:matrix.org)> Hey, sorry for the delay im abroad. St7789 has been superseded by mipidsi but i have not used mipidsi with pinewatch as my connector to it broke before i did the new driver. It should work as well though.
starblue has quit [Ping timeout: 260 seconds]
starblue has joined #rust-embedded
DepthDeluxe has quit [Ping timeout: 260 seconds]
dfgweb has quit [Quit: Leaving]
cr1901_ has joined #rust-embedded
cr1901 has quit [Ping timeout: 252 seconds]
IlPalazzo-ojiisa has joined #rust-embedded
starblue has quit [Ping timeout: 272 seconds]
starblue has joined #rust-embedded
IlPalazzo-ojiisa has quit [Quit: Leaving.]
<re_irc>
<Robert Jördens> Anyone suggestions for a crate that helps me implement a simple, small, no_std, text based configuration interface/CLI, typically over UART or TCP?
<re_irc>
<Robert Jördens> * Any
<re_irc>
< (@jamesmunns:beeper.com)> What kinda interface are you looking for? I know JP has a crate I've used before, lemme go find it...
<re_irc>
< (@jamesmunns:beeper.com)> If you are looking for something (MUCH) more experimental, I'm currently writing both a nostd terminal emulator (e.g. it handles history and line buffering), as well as an embedded forth you could use as a repl :p
<re_irc>
< (@jamesmunns:beeper.com)> (the terminal emulator part is probably not needed if your tcp/uart client provides line buffering, the forth part is not needed if you don't want an actual scripting language :p)
<re_irc>
<Robert Jördens> Ah menu looks good. Thanks!
<re_irc>
<Robert Jördens> Sounds a bit atypical to have the terminal emulator do history. Usually job of the shell/whatever runs inside TE. Or do you mean scroll buffer?
<re_irc>
< (@jamesmunns:beeper.com)> TE might not be totally accurate, but I want a standalone shell/TE for basically "a forth graphing calculator", so this is sort of an all-in-one solution.
<re_irc>
<Robert Jördens> I see. May indeed make sense to drop the split between terminal and shell. In the same sense that notebook (jupyter, mathematica) interfaces do.
<re_irc>
< (@jamesmunns:beeper.com)> Yeah, I'm going for sort of a "text chat bubble" style, where user input and program output are (visibly) separated
<re_irc>
< (@jamesmunns:beeper.com)> Technically there are three regions:
<re_irc>
- Output editing area (dark green, not shown in this demo, shows 'in progress' output)
<re_irc>
- Input editing area (dark blue, shows 'in-progress' input)
<re_irc>
- History (input + output, but each line is "tagged" with its source), light green/blue here
<re_irc>
< (@jamesmunns:beeper.com)> I don't support "input reply", e.g. "press up to copy one of your last N inputs to the current input buffer" yet, but probably will eventually.
<re_irc>
< (@jamesmunns:beeper.com)> But yeah, if you have "screen" or "minicom" or "telnet", you probably don't need any of this :p
<re_irc>
< (@jamesmunns:beeper.com)> I don't support "input repeat", e.g. "press up to copy one of your last N inputs to the current input buffer" yet, but probably will eventually.
<re_irc>
(edit: 'input repeat', not 'input reply')
cr1901_ is now known as cr1901
<re_irc>
< (@badrb:matrix.org)> I'm working on something similar Robert Jördens, I'm using menu + rtt-target.
<re_irc>
< (@firefrommoonlight:matrix.org)> This just confused the hell out of me today
<re_irc>
< (@firefrommoonlight:matrix.org)> But that article, found on a Google search fixed it
<re_irc>
< (@firefrommoonlight:matrix.org)> Bottom line: There was a breaking update to a sub-dep of demt that triggered long/confusing linker errors until you update something in Cargo.toml
<re_irc>
<Félix | Totem> Hello there! I want to write a firmware for my Moonlander keyboard (with keyberon, I guess?) but I'm a total noob when it comes to embedded. How hard is it to write such a thing, and where do I start?
<re_irc>
<Félix | Totem> Also, I've been told that I cannot brick my keyboard if I write a bogus firmware. Is that 100% true?
<re_irc>
< (@k900:0upti.me)> What SoC does the keyboard use?
<re_irc>
< (@k900:0upti.me)> It all depends on the hardware
<re_irc>
< (@mvirkkunen:matrix.org)> There's also many levels of "bricking", an end-user might consider a product bricked if you need to open it and connect a debugger to resurrect it, even though that's totally doable
<re_irc>
<Félix | Totem> : They say it's a Cortex-M4
<re_irc>
< (@k900:0upti.me)> That's a core, not a specific SoC
<re_irc>
< (@k900:0upti.me)> It is probably STM32something or nRF5somethingsomething
<re_irc>
< (@jamesmunns:beeper.com)> STM32F303 looks like
<re_irc>
< (@k900:0upti.me)> That may be mentioned on the spec sheet somewhere
<re_irc>
<Félix | Totem> : No, I'm talking about “bricking” as I cannot resurrect it at all.
<re_irc>
< (@jamesmunns:beeper.com)> Chances of bricking it would fall under "nearly impossible", IMO.
<re_irc>
< (@k900:0upti.me)> Complete brick is near impossible
<re_irc>
<Félix | Totem> : Where did you find this? Their website is full of marketing stuff, I cannot find the spec
<re_irc>
< (@k900:0upti.me)> But it may be possible to get into a state where you'll need external hardware to recover
<re_irc>
< (@jamesmunns:beeper.com)> the stm32f303 has a hardware (ROM based) USB bootloader that you can use DFU on, which you'd have to try pretty hard to lock yourself out of, looking for a schematic to see if they give you debugging pins which would save you even in the case you managed to lock yourself out of DFU
<re_irc>
< (@datdenkikniet:matrix.org)> (and assuming that this Moonlander is the same as your Moonlander)
<re_irc>
< (@jamesmunns:beeper.com)> Yeah, it seems to have a reset button, which you can hold down when plugging in, which probably keeps it in bootloader mode
<re_irc>
<Félix | Totem> : There is only 1 afaik
<re_irc>
< (@datdenkikniet:matrix.org)> * Moonlander, I have no idea if they have multiple models etc)
<re_irc>
<Félix | Totem> : Yes, that's how the flashing process is. I add the program in their software, then I press the reset button
<re_irc>
< (@k900:0upti.me)> Also, just something to keep in mind: if you flash your keyboard and your firmware doesn't work right, you will not have a keyboard, so maybe have another keyboard handy
<re_irc>
< (@k900:0upti.me)> Because it may be tricky to reflash your keyboard without a keyboard
<re_irc>
<Félix | Totem> : That's true 😅 Fortunately, I work on a laptop
<re_irc>
<Félix | Totem> : Ok, so I have the chip model + the pin definitions. I guess I have to read those files now.
<re_irc>
<Félix | Totem> Maybe it's a dumb question, but is that normal that I cannot get the OS when I plug the keyboard? It would be cool to enable some features depending on where you plug the keyboard in.
<re_irc>
<Félix | Totem> +information
<re_irc>
< (@jamesmunns:beeper.com)> Whatcha mean by "get the OS"?
<re_irc>
< (@k900:0upti.me)> No
<re_irc>
< (@k900:0upti.me)> The keyboard has no idea what it's connected to
<re_irc>
<Félix | Totem> I suppose it's due to security issue
<re_irc>
< (@jamesmunns:beeper.com)> (the USB spec doesn't really have anything for "tell the device what you are connected to")
<re_irc>
< (@k900:0upti.me)> You can theoretically figure out what OS you're talking to by the minor details in USB stack implementations
<re_irc>
< (@k900:0upti.me)> But I wouldn't recommend trying that
<re_irc>
< (@datdenkikniet:matrix.org)> +(It's not very easy and even less useful in the case of this article)
<re_irc>
<Félix | Totem> : I most definitely won't go that path :)
<re_irc>
<Félix | Totem> I'll do like everyone: a key to cycle through OSes
<re_irc>
< (@k900:0upti.me)> The least bad thing you can probably do here is have a script send a command to the keyboard to switch it to a specific profile on startup
<re_irc>
<Félix | Totem> Now that I have the pin definitions:
<re_irc>
< (@jamesmunns:beeper.com)> The moonlander seems to use an external I2C expander for (some of?) the pins. So for those, you'll need to talk to the MCP.
<re_irc>
<Félix | Totem> Uh…
<re_irc>
< (@jamesmunns:beeper.com)> the qmk repo mentions mcp23018
DepthDeluxe has joined #rust-embedded
<re_irc>
< (@jamesmunns:beeper.com)> https://crates.io/crates/port-expander doesn't seem to support that chip specifically, but you'll probably need to do something similar
<re_irc>
< (@texitoi:matrix.org)> This repo is a bit out of date with keyberon.
<re_irc>
<Félix | Totem> : Do you have any example that I can use as a teaching method?
<re_irc>
<besselfn> I just finished a minimum working example of a crate for the MCP9600 thermocouple amplifier, and published it. One of the things I'm worried about is the fact that the maximum measurement rate is dependent on the device configuration (which is set by the user).
<re_irc>
There's a status bit in one of the registers that can let the user know if the measurement isn't finished. Would it be unexpected for me to read that registry in a method that is only supposed to be polling the hot junction register?
<re_irc>
< (@jamesmunns:beeper.com)> Datasheet is there, it'll have the I2C protocol you'll need for writing/updating the I2C port expander driver (if/when you need it)
<re_irc>
< (@texitoi:matrix.org)> First make the MCU side working
<re_irc>
< (@texitoi:matrix.org)> you don't need to touch to the IO-expander for that
<re_irc>
< (@jamesmunns:beeper.com)> Solve one problem at a time/eat the elephant one bite at a time :D
<re_irc>
<Félix | Totem> : How do I know that the program is running, tho?
<re_irc>
< (@jamesmunns:beeper.com)> oh - wait - you're using the DFU bootloader not a debugger
<re_irc>
< (@jamesmunns:beeper.com)> that makes the app-template suggestion not as good
<re_irc>
< (@jamesmunns:beeper.com)> (it expects you are using a JTAG/SWD debugger, it's hard to tell if that's exposed for the moonlander)
<re_irc>
< (@jamesmunns:beeper.com)> In that case, step one would be try to get an LED blinking
<re_irc>
< (@jamesmunns:beeper.com)> (gotta run for a bit, sorry)
<re_irc>
<Félix | Totem> Gotcha
<re_irc>
< (@texitoi:matrix.org)> I suppose you can play with the led of the keyboard
<re_irc>
<Félix | Totem> : Am I supposed to do that with keyberon?
<re_irc>
<Félix | Totem> Or using the STM32F303 hal crate?
<re_irc>
< (@texitoi:matrix.org)> no, you should have some leds for capslocks and friends, and they should be directly connected to a pin, you can easily on and off them
<re_irc>
<Félix | Totem> : I understand that, but what crate am I supposed to use for that?
<re_irc>
< (@texitoi:matrix.org)> for the first step "I make my keyboard leds blink!" ;-)
<re_irc>
< (@texitoi:matrix.org)> the embedded hello world
<re_irc>
< (@texitoi:matrix.org)> the hal should be enough
<re_irc>
< (@jamesmunns:beeper.com)> oh, it does use the panic semihosting crate, you might want to switch that to "panic_halt" instead. I think panic_semihosting gets upset when you don't have a debugger attached
<re_irc>
<Félix | Totem> Yeah, I could make the example compile. Let's see if it works now :)
<re_irc>
<FredrikLL> I have a precompiled bootloader that I would like to include in my project. What would be the best way to go about it? It looks like I should be able to do it in build.rs by invoking the linker, but I don't see how I can specify the location. Anyone know of an example I could steal from?
<re_irc>
< (@adamgreig:matrix.org)> often you'd just flash the bootloader separately to the main project
<re_irc>
< (@adamgreig:matrix.org)> you could also do something like having a static [u8; _] that you use "#[link_section]" to put in the right place, and use "include_bytes!()" to read the bootloader binary blob
<re_irc>
< (@adamgreig:matrix.org)> but in general I think people would just flash the bootloader to the mcu first, and then after that only flash the application firmware to later on in the flash, leaving the bootloader in place
<re_irc>
< (@adamgreig:matrix.org)> (or even using the bootloader to flash the application)
<re_irc>
<Félix | Totem> The binary built is more than 10 times larger than the usual binary 😅 That's not normal, I guess
<re_irc>
<Félix | Totem> Not sure if if it's due to that, but the flashing tool doesn't like it: "Error while sending firmware bytes: libusb: pipe error [code -9]"
<re_irc>
<FredrikLL> : That's perfect, thanks! Is there a usual place to put this?
<re_irc>
< (@adamgreig:matrix.org)> Félix | Totem: are you looking at an elf file in "target/release/blabla"? that's probably not the right format for the flashing tool, it's an ELF file
<re_irc>
< (@adamgreig:matrix.org)> (though you should also check you're using "--release" when you build, to enable optimisations, as the default debug builds are often quite bloated for embedded)
<re_irc>
<Félix | Totem> : Hmm, then what should I try and flash the keyboard with?
<re_irc>
< (@adamgreig:matrix.org)> what flashing tool are you using?
<re_irc>
<Félix | Totem> : Yes, I do use the release build, but it's not size-optimized
<re_irc>
< (@adamgreig:matrix.org)> FredrikLL: I don't think it's a "usual" thing to do so not really, wherever? I'd just stick it at the top of main.rs. you'll want to add a new section to "memory.x" to tell the linker where to put it, too.
<re_irc>
< (@adamgreig:matrix.org)> what's the name of the homemade tool?
<re_irc>
< (@adamgreig:matrix.org)> just need to know what file format it expects - maybe raw binary, maybe hex, maybe elf...
<re_irc>
<Félix | Totem> Sorry, I've such a hard time using my laptop keyboard now :'(
<re_irc>
<Félix | Totem> A *.bin file
<re_irc>
< (@adamgreig:matrix.org)> hah, no worries, I have such a hard time when I have to use a bad keyboard too
<re_irc>
< (@adamgreig:matrix.org)> cool, that shouldn't be too bad
<re_irc>
< (@adamgreig:matrix.org)> if you run "rustup component add llvm-tools-preview" and "cargo install cargo-binutils"
<re_irc>
< (@adamgreig:matrix.org)> you can then use "cargo objcopy --release -- -O binary app.bin" and it will generate "app.bin" (this builds it too, so you don't need to "cargo build" first)
<re_irc>
< (@adamgreig:matrix.org)> and then try flashing "app.bin", which should be a sensible size
<re_irc>
<Félix | Totem> Alright, thans. That ffels
<re_irc>
<Félix | Totem> Alright, thanks. That feels a bit like magic, but I'll do that.
<re_irc>
< (@adamgreig:matrix.org)> I can explain a bit if you're interested: rust produces an executable format called "elf" by default when building for cortex-m, which contains the firmware code and also a bunch of debug information and memory addresses and such, which some tools can use (that's why it's quite large)
<re_irc>
< (@adamgreig:matrix.org)> the flashing tool could be written to understand that, but it doesn't really need to, it just wants to know the raw binary data that needs to be written to the chip's memory, which is a small part of the elf
<re_irc>
< (@adamgreig:matrix.org)> the compiler contains a tool called "objcopy" that can extract just this data from an elf, and the normal makefile for the stock C firmware almost certainly produces an elf and then calls objcopy to create the .bin that the flasher uses
<re_irc>
< (@adamgreig:matrix.org)> so, you'll have to do that yourself somehow - "cargo-binutils" installs a wrapper that lets you call "cargo objcopy" to use rust's built-in objcopy
<re_irc>
< (@adamgreig:matrix.org)> (you could hide this behind your own makefile, or other tool, but I end up just typing it out usually, and my shell autocompletes...)
<re_irc>
<Félix | Totem> Oh, I understand, that's very clear, thanks. I'll be afk for a while, I'll try that later.
cr1901 has quit [Remote host closed the connection]
<re_irc>
<Félix | Totem> : Thanks, it works. The program doesn't do what I want, tho
cr1901 has joined #rust-embedded
<re_irc>
<Félix | Totem> I have no idea about how I can know what happens in the keyboard. I guess I have to use a debugger somehow
cr1901 has quit [Remote host closed the connection]
<re_irc>
< (@adamgreig:matrix.org)> the flashing tool probably collaborates with the stock firmware for the keyboard; since your firmware isn't doing USB, you'll probably need to reset the keyboard manually into a bootloader, maybe by holding down reset as you power it up or something like that
<re_irc>
<Félix | Totem> : You're right, it worked. I have once again a working kb
richardeoin has quit [Ping timeout: 260 seconds]
<re_irc>
<Félix | Totem> This simple program is supposed to turn a led on, but it doesn't work. Any idea why?
<re_irc>
let dp = pac::Peripherals::take().unwrap();
<re_irc>
< (@datdenkikniet:matrix.org)> Are you sure there's an LED connected to any pins on port E?
<re_irc>
<Félix | Totem> Oh, so pe means Port E
<re_irc>
<Félix | Totem> No, I'm not sure
<re_irc>
< (@datdenkikniet:matrix.org)> The ones on the moonlander should be on B5/B3/B3, as TeXitoi noted
<re_irc>
<Félix | Totem> Uh, I missed this piece of information
<re_irc>
< (@datdenkikniet:matrix.org)> if you change "dp.GPIOE" to "dp.GPIOB" and "pe13" into "pb<3|4|5>" it might work
<re_irc>
< (@datdenkikniet:matrix.org)> but I'm not sure if those LEDs want push/pull pins
<re_irc>
< (@datdenkikniet:matrix.org)> * can tolerate/are activated by
<re_irc>
<Félix | Totem> : It doe, thanks!
<re_irc>
<Félix | Totem> * does,
<re_irc>
< (@datdenkikniet:matrix.org)> Félix | Totem: and: yes, usually you'll have one peripheral struct called "GPIO<N>" per GPIO bank, and then that peripheral will contain one "p<NXX>" per numbered pin in the port
<re_irc>
< (@datdenkikniet:matrix.org)> * port,
<re_irc>
< (@datdenkikniet:matrix.org)> * the HAL will
<re_irc>
< (@datdenkikniet:matrix.org)> The LED stuff was in another file, "moonlander.h"
<re_irc>
< (@datdenkikniet:matrix.org)> I think "config.h" only contains "generic keyboard stuff" while the "keyboardname.h" and "keyboardname.c" contain things that are specific to the keyboard itself
<re_irc>
< (@datdenkikniet:matrix.org)> : ^^ it was also linked here
<re_irc>
< (@datdenkikniet:matrix.org)> I think "config.h" mostly contains "generic keyboard stuff" while the "keyboardname.h" and "keyboardname.c" contain things that are specific to the keyboard itself
<re_irc>
< (@datdenkikniet:matrix.org)> I think "config.h" mostly contains "generic keyboard stuff" while the "keyboardname.h" and "keyboardname.c" contain things that are specific to the keyboard itself? Worth browsing the other files in the "keyboards/moonlander" directory at least, together they give the whole picture.
<re_irc>
< (@datdenkikniet:matrix.org)> I think "config.h" mostly contains "generic keyboard stuff" while the "keyboardname.h" and "keyboardname.c" contain things that are specific to the keyboard itself? Worth browsing the other files in the "keyboards/moonlander" directory, together they give the whole picture.
<re_irc>
< (@adamgreig:matrix.org)> you should also double check your keyboard actually has an 8MHz external crystal connected, it probably has _a_ crystal for USB, but it might be a different frequency
<re_irc>
<Félix | Totem> : I've no idea about what that mean, but I don't need that right now
<re_irc>
< (@adamgreig:matrix.org)> it's a shame there doesn't seem to be a schematic for the moonlander, it would make this much easier!
<re_irc>
<Félix | Totem> Can I figure out that by myself? Like I try to call the clock functions with numbers and see if it panics
<re_irc>
< (@adamgreig:matrix.org)> annoyingly it probably won't panic, just either not work or not work at the speed you expect. it might be possible to work out what qmk is doing but I couldn't see anything obvious
<re_irc>
<Félix | Totem> Isn't the clock a part of the chip? I mean all the stm32f303 have the same clock, haven't they?
<re_irc>
< (@adamgreig:matrix.org)> they all have an internal clock, which is not very accurate, so you often put an external clock component on the circuit board that's more accurate, especially if you're doing USB which needs an accurate clock
<re_irc>
< (@adamgreig:matrix.org)> some chips are able to calibrate the internal clock using the USB signal itself, but the stm32f303 can't, so it would need an external clock (a "crystal")
<re_irc>
< (@adamgreig:matrix.org)> cool, good find
<re_irc>
< (@adamgreig:matrix.org)> 8mhz is a super common and standard value so it sure seems like a good bet anyway
<re_irc>
< (@k900:0upti.me)> QMK source code is impossible to follow tbh
<re_irc>
< (@k900:0upti.me)> It's mostly "declarative" C by header abuse
<re_irc>
< (@k900:0upti.me)> Most of the design sketches I had for my own keyboard firmware were induced by looking at QMK and noting down things not to do
<re_irc>
<Félix | Totem> : Reading your example, I'm not sure that "keyberon::layout::Layers" fits my need. I want to have a bunch of hold keys which depend on a boolean, that I can enable or disable. I'm not sure that I can do that with your current design. Also, I want to rely heavily on unicode insertion. That could be easily added, though, it's only a macro mechanism.
DepthDeluxe has quit [Ping timeout: 252 seconds]
<re_irc>
< (@texitoi:matrix.org)> Félix | Totem: keyberon is modular, if you want to use the matrix bit not the layer, sure you can. You can also use another USB his implementation of you want, there is a PR to propose this.
<re_irc>
<Félix | Totem> : I'm not sure to understand the implication of the USB implementation part.
<re_irc>
< (@texitoi:matrix.org)> I can't tell if you can do what you want as I didn't understand the specs 😉
<re_irc>
<Félix | Totem> Has it something to do with the serial USB thing
<re_irc>
<Félix | Totem> : I use a long press to output a maj, but in gaming mode, I want to disable this behavior. So there must be a boolean somewhere telling if that feature is active or not.
<re_irc>
< (@texitoi:matrix.org)> The hid manage the keys that can be send. The one included in keyberon is basic, if you want advances feature as Unicode send, it might be too limited.
<re_irc>
< (@texitoi:matrix.org)> You can just change the default layer
<re_irc>
<Félix | Totem> : I could do that. That's what I do with my current configuration.
<re_irc>
< (@texitoi:matrix.org)> One normal layer, and a gaming layer, and a key to chose the default