<i509vcb[m]>
if cargo had enum-like feature values then it would probably be something like chip
<Ralph[m]>
(note the multi_select: i imagine that there'll be use-cases where one might want to give the option to select multiple values, though i'm hard pressed to come up with an example right now)
<therealprof[m]>
Not sure specifically about that idea but there have been a lot of ideas and discussions in the Rust project which would have gone in that direction but they've been all deemed either impossible to implement (due to the way how features work under the hood) or too complex to be worth it due to lack of demand outside of niche embedded uses.
ello- has joined #rust-embedded
jistr_ has joined #rust-embedded
zagura_ has joined #rust-embedded
zagura has quit [Ping timeout: 260 seconds]
ello has quit [Ping timeout: 260 seconds]
jistr has quit [Ping timeout: 260 seconds]
<JamesMunns[m]>
IMO https://github.com/jamesmunns/toml-cfg could be made official, one of the bigger issues with any non-binary/non-globally-unioned set of features is "what to do when two crates disagree", e.g. both set some config to different values.
<JamesMunns[m]>
toml-cfg just takes the opinion of "you can't", because only the "root" project (e.g. the app/static lib) can set configuration at all.
zagura_ is now known as zagura
pcs38 has joined #rust-embedded
<JamesMunns[m]>
"could be made official" -> "I think it has a path to being usable/acceptable", it is nowhere NEAR that today, but I think it COULD be viable :D
sourcebox[m] has joined #rust-embedded
<sourcebox[m]>
James Munns: I haven't followed the whole discussion but some time ago we talked about the issue that optimization settings currently can only be applied at the crate level. So you can't just build a single module or function with opt-level 0 to debug it. At the time we talked about it, someone said that it's basically a thing with LLVM that prevents it. Not sure if this topic is something that should be on your list.
<ckrenslehner[m]>
<JamesMunns[m]> "IMO https://github.com/jamesmunn..."; <- I really like the idea of your toml-based configuration.
<ckrenslehner[m]>
From the awesome embedded rust repo, [rmk](https://github.com/HaoboGu/rmk) also uses a similar approach with `keyboard.toml`.
<sourcebox[m]>
<JamesMunns[m]> "Feel free to add it!" <- Done.
<sourcebox[m]>
The impact of this is of course related to other issues that blow up the code size.
rainingmessages has quit [Quit: bye]
rainingmessages has joined #rust-embedded
dngrs[m] has quit [Quit: Idle timeout reached: 172800s]
emielvs[m] has joined #rust-embedded
<emielvs[m]>
Hi, I'm trying to connect to an em9190 (sierra wireless modem). Works fine using socat, but with serialport crate I get 'not a typewriter' errors. Does that mean the device doesn't support terminal io?
<emielvs[m]>
* (sierra wireless cellular modem, * modem to send at commands to). Works
<emielvs[m]>
* (sierra wireless cellular modem, * modem to send at commands to). Works, * terminal io? is there an alternative to serialport then?
<boru>
You could strace the process it to see how it's opening the port. Are you just sending it AT commands?
<boru>
And what socat arguments are you using?
<emielvs[m]>
boru: socat - /dev/wwan0at0,crnl (adding ,b115200 returns an error)
<boru>
What is the error for trying to set the baud rate?
<emielvs[m]>
boru: E tcgetattr(5, 0x562d03aad820): Inappropriate ioctl for device
<boru>
What file descriptor do you get from the corresponding open call? Is it 5?
<boru>
Are there any other syscalls between them?
<boru>
strace ought to give you the full picture here.
<boru>
What system is this on? BSD or Linux or something? What sort of device node is it?
<emielvs[m]>
<boru> "strace ought to give you the..." <- don't have strace device installed on that device atm, will need to add it and create a new build..
<emielvs[m]>
its on linux, but custom, yocto poky based.
<emielvs[m]>
what do you mean by device node?
<emielvs[m]>
shows up as char device
<boru>
As it, is it really a serial port?
<boru>
Not being able to alter the baud rate is a bit suspicious.
<emielvs[m]>
I'm also a bit suspicious about that. what else can it be?
<emielvs[m]>
just a plain char device or?
<emielvs[m]>
* device or? what else?
<dirbaio[m]>
your modem is using one of the newer usb protocols like QMI or MBIM
<dirbaio[m]>
vs the older usb protocol which is the modem simply presenting itself to the computer as a usb-to-serial adapter (CDC ACM)
<emielvs[m]>
MBIM
<boru>
Ah
<dirbaio[m]>
this means that device is a character device but it's not a serial port
<dirbaio[m]>
so it's expected using the serialport-rs crate fails
<boru>
Yeah, exactly that
<dirbaio[m]>
you talk to it by doing open() on the device and then write()/read().
<dirbaio[m]>
like, a plain old file
<dirbaio[m]>
using std::fs::File
<boru>
ENOTTY was absolutely correct in this instance.
<hjeldin__[m]>
this is the clocks configuration on stm32 ide
<dirbaio[m]>
What chip and board is it?
<hjeldin__[m]>
stm32l476rg with a custom board
<dirbaio[m]>
Oh yeah we talked yesterday
<dirbaio[m]>
I'm afraid I don't have more ideas
<dirbaio[m]>
Dmesg doesn't say "low speed" now though! Did you fix stuff?
<dirbaio[m]>
s/stuff/something/
<dirbaio[m]>
Rcc config looks okay..
<hjeldin__[m]>
yeah, i was being a moron and used untwisted wires between my pogo pin connector and the headers on the board 🤣 i soldered the vacant usb-c connector on the board, i'll fix the cable later
<hjeldin__[m]>
dirbaio[m]: thanks! time to dig deeper in the embassy-usb library then
<dirbaio[m]>
my only guess is you've swapped dp/dm
<dirbaio[m]>
* is you might've swapped
<JamesMunns[m]>
If it works in stm32xxx-hal, that would be surprising
<JamesMunns[m]>
You could try setting the PLL to output 96mhz, and set the core frequency to 48mhz, and use PLLQ to source the usb48 clock instead of SAI1, to see if it's an issue with the sai1 rcc code?
<dirbaio[m]>
yeah i'm playing with it and it still fails with slower AHBs
<dirbaio[m]>
not sure why, TRDT is supposed to take care of that
<hjeldin__[m]>
thank you very much!
<dirbaio[m]>
I have no idea what's wrong. We're doing the same as ST's C HAL
<dirbaio[m]>
setting TRDT to the max of 0xF doesn't work either
<dirbaio[m]>
🤷
<dirbaio[m]>
with fast ahb clock it works flawlessly tho
<dirbaio[m]>
so i'm just giving up
<dirbaio[m]>
I think this took a long time to get noticed because nobody runs their clocks slower than the max :P
chrysn[m] has quit [Quit: Idle timeout reached: 172800s]
pcs38 has joined #rust-embedded
sroemer has quit [Quit: WeeChat 4.4.3]
r[m] has quit [Quit: Idle timeout reached: 172800s]
Noah[m] has quit [Quit: Idle timeout reached: 172800s]
<hjeldin__[m]>
<dirbaio[m]> "I think this took a long time to..." <- i still need to buy a power profiler, but i was under the impression that running things at a lower clock should be beneficial for battery duration, right?
<JamesMunns[m]>
<dirbaio[m]> "I think this took a long time to..." <- I thought we all decided "race to sleep" was the better strategy anyway :D
<dirbaio[m]>
given a fixed amount of work it's usually best to do it as fast as possible yes
<JamesMunns[m]>
Yeah, usually it's "run as fast as your chip will allow you to get back to low power sleep"
diondokter[m] has joined #rust-embedded
<diondokter[m]>
Little point in minimizing power when hooked up to a USB bus I'd say
<hjeldin__[m]>
AHB runs a whole lot of peripherals, but your point makes sense
<dirbaio[m]>
but in the more advanced chips where you can configure regulators, lower clock allows you to use lower voltage in which case it saves power
<JamesMunns[m]>
Maybe if you spend a lot of time busy polling instead of sleeping and waiting for interrupts I guess?
<JamesMunns[m]>
Would be a good blog post to see measurements, I don't think I have a recent thing to cite.
<JamesMunns[m]>
Embassy pushes you to drop periphs to remove their demand on clock trees, and to go to WFE sleep at least
<JamesMunns[m]>
Youd probably want to just customize the executor loop for your project to do all that tho usually, right?
<JamesMunns[m]>
(if you wanted to do it dynamically for deeper sleep)
<hjeldin__[m]>
deep sleep is my next task on the agenda, i'm sure i'll be back with many questions 🤣
rafael[m] has quit [Quit: Idle timeout reached: 172800s]
pcs38 has quit [Quit: leaving]
reitermarkus[m] has quit [Quit: Idle timeout reached: 172800s]