<adamgreig[m]>
You can usually bypass the lxo/visa hateplex and just open a raw TCP socket to port 5025 or so and send scpi from the programming manual. But it's not exactly high level.
<ian_rees[m]>
adamgreig[m]: Love "hateplex" - my feelings exactly
<adamgreig[m]>
I can't believe NI somehow ended up in charge of all this. Very grateful that somehow everyone still keeps a raw TCP socket exposed. For now anyway
<adamgreig[m]>
I look forward to one day having to pay an extra thousand bucks to unlock raw TCP or something
<ian_rees[m]>
I've started a little crate for some gear that I own, might tidy that up and put it on GitHub
<ian_rees[m]>
where "some gear" is "a small fragment of Siglent SDG2042X functionality", but it's a start!
yandrik[m] has quit [Quit: Idle timeout reached: 172800s]
emerent has quit [Ping timeout: 258 seconds]
emerent_ has joined #rust-embedded
emerent_ is now known as emerent
<JamesMunns[m]>
<adamgreig[m]> "I look forward to one day having..." <- Or short two pads or do a firmware flash (as long as you don't care about your cal sticker :p )
bpye has joined #rust-embedded
starblue has quit [Ping timeout: 240 seconds]
starblue has joined #rust-embedded
crabbedhaloablut has joined #rust-embedded
GrantM11235[m] has quit [Quit: Idle timeout reached: 172800s]
IlPalazzo-ojiisa has joined #rust-embedded
<ian_rees[m]>
<ian_rees[m]> "I've started a little crate..." <- Is there a trick for figuring out an email address or otherwise contacting an owner of a crate on crates.io? `corten` seems like a perfect name for this, comment says "Willing to transfer ownership if requested." but I have no idea how to actually make such a request...
<sknebel>
oof, user has 12 crates, all empty placeholders?!
<sknebel>
ian_rees[m]: see e.g. - https://crates.io/policies it sounds like you can ask crates.io people to contact them if needed?
<ian_rees[m]>
ah awesome, thanks! I'll do that now
starblue has quit [Ping timeout: 250 seconds]
starblue has joined #rust-embedded
eldruin[m] has joined #rust-embedded
<eldruin[m]>
ian_rees: if that does not work, you could open an issue in one of the author's repositories in github. The crate does not have an email in the cargo.toml either
<eldruin[m]>
* ian\_rees: if that does not work, you could open an issue in one of the author's repositories in github. The crate does not have an email in the [cargo.toml](https://docs.rs/crate/corten/0.0.0/source/Cargo.toml) either
nex8192 has left #rust-embedded [Error from remote client]
nex8192 has joined #rust-embedded
yoyofreeman has joined #rust-embedded
dhylands[m] has quit [Quit: Idle timeout reached: 172800s]
thejpster[m] has quit [Quit: Idle timeout reached: 172800s]
<sourcebox[m]>
dirbaio: Sorry for the late response. Regarding sharing peripherals between cores, you suggested to start with having them taken by core0 and then passing some to core1. Since both cores don't really have a connection point in code (they run out of the startup code individually), I think the only way to do this is by using some static "containers" for this. And yes, we are talking about STM32MP1, the A7 cores. The M4 one runs a
<sourcebox[m]>
different code base, no way to make this safe by some language feature.
emerent has quit [Ping timeout: 246 seconds]
emerent has joined #rust-embedded
corecode[m] has quit [Quit: Idle timeout reached: 172800s]
huegene[m] has quit [Quit: Idle timeout reached: 172800s]
<dirbaio[m]>
> sourcebox they run out of the startup code individually
<dirbaio[m]>
ahh interesitng. It's different than in rp2040 then. in rp2040 core0 starts from the reset vector, core1 gets trapped in ROM and doesn't jump to user code until you explicitly pass it its inicial PC/SP. perhaps you can make the HAL do a similar thing in software, so from the user's PoV you boot core1 by passing it a closure, where you can move singletons.
<dirbaio[m]>
ofc that helps with the two A7s only, not with the M4
<sourcebox[m]>
Yes, that way it would be easy, but the way the second core of the MP1 is started is quite funky, not even well documented.
<dirbaio[m]>
:S
<dirbaio[m]>
how's the experience with bare-metal MP1 overall?
<dirbaio[m]>
last I looked at it, it seemed they wanted you to use their Linux fork and that's it
<sourcebox[m]>
Yes, there's no support from ST for bare-metal.
<sourcebox[m]>
I'm using the chip for a project where the connectivity is required. Otherwise, you're probably better of with a RPi CM4.
<sourcebox[m]>
The peripherals are quite similar to the F7/H7 series, so some code could be used from these chips.
<dirbaio[m]>
hah. you're also "forced" to use linux on the RPi CM4 tho
<sourcebox[m]>
He even wrote an own bootloader so the chip starts up quickly with <1s. Otherwise with u-boot and Linux, it's slow as hell.
<sourcebox[m]>
For Linux based systems, I would not use A7 anymore these days, but for bare-metal, when your code largely fits into L1/L2 cache, the performance is quite ok for a lot of applications. Also, you could keep the A7s free of interrupts, because the M4 can handle these tasks much better.
<sourcebox[m]>
And the project will make use of NEON SIMD.
<sourcebox[m]>
Initially, a RPi CM4 was taken into account, but we need way more pins and also multi-channel audio in/out, nothing an RPi is really good at (unless you do it externally via USB).
yoyofreeman has quit [Remote host closed the connection]
yoyofreeman has joined #rust-embedded
<sourcebox[m]>
Btw. I tried to get RTT working in this setup, but for some reason OpenOCD only sometimes found the control block. So I gave up at some point and used an USART for logging and panic messages. Not that great, but since the bootloader writes out it's messages there anyway...
duderonomy has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
duderonomy has joined #rust-embedded
jamwaffles[m] has quit [Quit: Idle timeout reached: 172800s]
phaseonx11[m] has quit [Quit: Idle timeout reached: 172800s]
<dirbaio[m]>
very cool 👀
GenTooMan has quit [Ping timeout: 246 seconds]
likewise[m] has joined #rust-embedded
<likewise[m]>
> For Linux based systems, I would not use A7 anymore these days, but for bare-metal, when your code largely fits into L1/L2 cache, the performance is quite ok for a lot of applications.
<likewise[m]>
Note that you can run Linux in task isolation mode, having the benefits of bare-metal (nanosecond) latencies in your processing section, but full Linux in the setup and teardown.
<likewise[m]>
I used that for audio processing 512 channel @48 kHz @20 bits.
<likewise[m]>
s/channel/channels/
<likewise[m]>
(Yes, startup time is higher, depending on how much effort you put into it. So depends on what you require.)
alianunnaki[m] has joined #rust-embedded
<alianunnaki[m]>
New to element
<alianunnaki[m]>
I found this room in reddit
<alianunnaki[m]>
Hope it will help me as embedded and control theory engineer
IlPalazzo-ojiisa has quit [Remote host closed the connection]
GenTooMan has joined #rust-embedded
GenTooMan has quit [Ping timeout: 246 seconds]
GenTooMan has joined #rust-embedded
<ian_rees[m]>
<eldruin[m]> "ian_rees: if that does not work,..." <- Ah, good idea! I went so far as cloning both of them to see if an email address was in the repo but didn't think of that :). crates.io support person responded that they'll reach out anyway. To a small extent, I think crates.io could use a little pressure to do something about the namesquatting so I don't mind asking them
<JamesMunns[m]>
> To a small extent, I think crates-io could use a little pressure to do something about the namesquatting so I don't mind asking them
<JamesMunns[m]>
To be fair, this is probably one of *the* most repetitive discussions that happens on any forum all of the time. the crates io team has made their position very clear, and there is an open RFC to discuss this atm, but it is full of edge cases that often don't have more satisfying answers than "make all the decisions *I* think are fair".
<JamesMunns[m]>
like, you can probably find dozens of reddit posts and urlo/irlo posts this year alone discussing it, "could use a little pressure" seems... insensitive, to say the least.
<ian_rees[m]>
I didn't mean to imply that my opinion deserves any special status - they've made a design decision and that's well within their right
<ian_rees[m]>
but that decision does incur a cost, and to me it doesn't seem totally right to put that entirely on the community - hence I'm fine with a polite email when appropriate to ask them to contact the squatter
<ian_rees[m]>
I think there's a difference between "complain about the decision in a forum" and "hi I'm having trouble with namesquatting, could you help?" - what I'm trying to do is the second not the firs
<JamesMunns[m]>
afaik, crates-io admins will only take a crate down in response to a legal order or clear abuse in the form of malware, etc.
<ian_rees[m]>
sure, but that's not what is happening here. The crate owner has advertised that they're willing to give up the squatted crate name, but they've left no obvious way to get in touch
<dirbaio[m]>
the amount of toxicity in #3463 is extremely sad
<dirbaio[m]>
IMO squatting sucks and needs to be fixed
<JamesMunns[m]>
These discussions get... fairly toxic, fairly often. That's part of why I pushed back on the "they could use a little pressure" topics.
<sourcebox[m]>
I'm convinced that namespaces have to be introduced sooner or later, but it would have been much easier if they were there right from the start.
<JamesMunns[m]>
I mean, that suggestion got discussed a lot, the two counterpoints are "doesn't that mean I could just squat namespaces now?" and/or "do you tie it to some other auth like GH orga or domain ownership? and if so what happens when THAT changes hands?"
<JamesMunns[m]>
but, I probably have nothing valuable and novel to add here other than parroting old discussion points, I'm sure this has all been discussed more extensively on those two issues.
<sourcebox[m]>
At least it would reduce the motivation for squatters. The current situation is basically an invitation to abuse it.
<ian_rees[m]>
<JamesMunns[m]> "These discussions get... fairly..." <- Maybe "pressure" wasn't the right word, or wasn't qualified enough. I have just about 0 interest in being involved with the "how do we fix this?" conversation, but there is a problem there. To me, it seems reasonable to expect very different outcomes between A) suggesting/arguing about how to fix the issue, vs B) a reasonable request for help, which happens to highlight the
<ian_rees[m]>
issue. In the first, there's clearly no obvious right answer. In the second, there are ways that crates.io could change things to reduce the pressure of the requests for help. Since the request for help came about because of the namesquatting issue, I think those changes would also help the underlying problem
<ian_rees[m]>
> <@jamesmunns:beeper.com> These discussions get... fairly toxic, fairly often. That's part of why I pushed back on the "they could use a little pressure" comment.
<ian_rees[m]>
* Maybe "pressure" wasn't the right word, or wasn't qualified enough. I have just about 0 interest in being involved with the "how do we fix this?" conversation, but there is a problem there. To me, it seems reasonable to expect very different outcomes between A) suggesting/arguing about how to fix the issue, vs B) a reasonable request for help, which is needed because of the issue. In the first, there's clearly no obvious
<ian_rees[m]>
right answer. In the second, there are ways that crates.io could change things to reduce the pressure of the requests for help. Since the request for help came about because of the namesquatting issue, I think those changes would also help the underlying problem
<sourcebox[m]>
It's not only the squatting, but things like uploading crates with similar names to popular ones that can do harm or just for spamming.
<ian_rees[m]>
<sourcebox[m]> "I'm convinced that namespaces..." <- Agree that something like namespaces could be good, but I don't think it's helpful to critique decisions made in the past. I'm very grateful for what Rust has become overall, and there's no guarantee that the outcome would have been so good, if those past decisions were made differently
<sourcebox[m]>
I think, the initial intention was to set the barrier for publishing crates quite low. And that's a valid reason, of course.