<re_irc>
<adamgreig> and can't do the match trick because it doesn't end up a string literal
<re_irc>
<adamgreig> ugh
<re_irc>
<adamgreig> I'm only changing one template string out of like, a lot, though
<re_irc>
<dirbaio> ugh :D
<re_irc>
<adamgreig> this is for global_asm and it turns out it doesn't guarantee multiple calls will assemble in sequence, otherwise i'd just split it up which would be super gross
<re_irc>
<dirbaio> check this out ☝️
<re_irc>
<adamgreig> good god, is that perl
<re_irc>
<adamgreig> it doesn't look like naked_function will land in 1.60 sadly
<re_irc>
<adamgreig> hmm, macro is upset
<re_irc>
<adamgreig> "485 | ".cfi_sections .debug_frame", | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ no rules expected this token in macro call"
<re_irc>
<adamgreig> should be easy to debug though since it's a pretty simple macro
<re_irc>
<adamgreig> nice, recursion limit hit
<re_irc>
<dirbaio> hehehe
<re_irc>
<dirbaio> also if you have N cfg's in the input, the output is O(2^n)
<re_irc>
<adamgreig> it suggested upping it to 256, then to 512, then to 1024, now my computer is thinking about it at 8192
<re_irc>
<dirbaio> yes, exponential 👌
<re_irc>
<adamgreig> i have two cfgs :(
<re_irc>
<dirbaio> huh
<re_irc>
<adamgreig> suspect I've messed something else up and it's recursing forever instead
<re_irc>
<dirbaio> yeah that shouldn't hit the recursion limit
starblue1 has quit [Ping timeout: 240 seconds]
starblue1 has joined #rust-embedded
<re_irc>
<adamgreig> huh, the rust assembler is annoyingly stricter than gcc
<re_irc>
<adamgreig> needs me to write "movs r0, #4" instead of mov and figuring it out, and won't let me write "ldr r0, =#0xffffffff" to use a literal in a pool it seems
<re_irc>
<adamgreig> ok, "movs r0, #0; mvns r4, r4" works and is overall probably nicer than the literal pool that gcc was doing, i'll take it
<re_irc>
<chmanie> James Munns: Please excuse my ignorance, but could you point me to a resource for the "sealed trait thing" that you were referencing? I can't find much and what I can find seems somehow unrelated :(
<re_irc>
<jan> Is "rust-embedded" a project which strives to find a single Grand Unified Abstraction over as many processors/peripherals/boards as possible, or is it more of an umbrella which tries to coordinate a bunch of different (disjoint) smaller projects? Or, phrased differently: Does does the rust-embedded WG hold some repository with a bunch of traits which are general enough to work in ~all cases?
<re_irc>
<ryan-summers> The working group generally tries to facilitate coordination between multiple disjoint, smaller projects. Specifically, the embedded-hal traits are designed to be as general as possible to provide a common interface that device drivers (e.g. external chip controllers) can be written to use, without relying on any underlying specific control hardware
<re_irc>
<ryan-summers> It also helps maintain some core architectural support projects, e.g. cortex-m and cortex-m-rt, which help for basic bringup on standard platforms
<re_irc>
<ryan-summers> "rust-embedded" is more a community of lots of embedded folk working in Rust though - so you get a lot of different creators developing things as part of an ecosystem
<re_irc>
<omar_u8> As I'm working more with embedded Rust, I'm finding that developing at the PAC level is easier for me than the HAL. Thing is, although I know exactly what I want to do in the hardware, the PAC is giving me a more direct approach to achieving that. At the HAL level though, I'm finding it more confusing to achieve the same goals. I don't know if this is an experience others share.
<re_irc>
For example, Ive been trying to configure a PWM pin for an STM32 chip using the HAL with an example at hand, trying to follow alongside with the documentation. Things don’t seem to be clear and there are inconsistencies a times. At least if anything, knowing that there are certain steps that need to be done at the hardware level, I am trying to figure out where they happened in the HAL and can’t really see where they were...
<re_irc>
... done. In this case it was Alternate functions of pins. As is already known, turning the pin to an alternate function is not sufficient by itself where the alternate function needed has to be chosen. Although even in working examples, where that transformation happened is not always clear.
<re_irc>
Split and constrain are another example, it doesn’t seem to be clear when they need to be used in all cases.
<re_irc>
I guess what I am looking for is a good resource that walks through an example alongside documentation at the HAL level?
<re_irc>
<ryan-summers> It's honestly really hard to write a HAL that's general enough imho :/ I leverage the HALs as much as possible, but I often find myself having to reach to the PAC level as well
<re_irc>
<ryan-summers> It also depends on the HAL in question. Some are much more developed than others. For example, the H7 hal is fantastic and lets you easily leverage complex things like DMA
<re_irc>
<chrysn (@chrysn:matrix.org)> sorry chmanie, for that I lack the full context. Possible, the "where N" clause constrains N to be of some sealed trait, so you retain the flexibility to add or remove traits there as needed, eg. if you want to add a to_epsilon that needs an additional trait method.
m5zs7k has quit [Ping timeout: 272 seconds]
m5zs7k has joined #rust-embedded
<re_irc>
<ryan-summers> And honestly, having the device reference manual open is always exceptionally helpful when working with a HAL. You can never throw the RM out
<re_irc>
<omar_u8> ryan-summers: Thats good to know. Quite honestly, navigating some of the HALs was a nightmare at times. Felt like thing were going in circles at times.
<re_irc>
<ryan-summers> Basic peripherals like a timer are just so incredibly general purpose that it's hard to write good abstractions around them
<re_irc>
<omar_u8> ryan-summers: Thats what I was doing, and I couldnt really see that things were happening 1:1.
<re_irc>
<chrysn (@chrysn:matrix.org)> I think that one important feature of the HALs is to catch the repetitive easy tasks. Like, working with I2C attached sensors, or performing delays as they are sometimes needed for that task.
<re_irc>
<ryan-summers> Yeah, I find them great for bringing up communication interfaces and configuring the clock systems
<re_irc>
<chrysn (@chrysn:matrix.org)> Nothing wrong about leaving the complex parts to direct-to-PAC or special-purpose mechanisms.
<re_irc>
<ryan-summers> I'm super happy I have no need to fully understand the STM32 RCC :)
<re_irc>
<ryan-summers> Also, really great for complex peripherals like the H7 ethernet controller - the HAL provides an impl that can be directly handed to smoltcp for a full-featured network stack, so you don't have to worry about any of the complexity related to that
<re_irc>
<omar_u8> This is great insight. Thank you!
<re_irc>
<ryan-summers> I remember having the same frustrations with HALs when I started out, but don't feel bad about working around them via direct PAC access
<cr1901>
I've just accepted the fact that I may need to write an inline HAL or wrap an existing one depending on my application
<cr1901>
I don't get around using a RefCell to sync access to HALs from multiple threads, since most HAL methods take &mut self :(
starblue1 has quit [Ping timeout: 256 seconds]
starblue1 has joined #rust-embedded
Guest2 has joined #rust-embedded
mmahrous has joined #rust-embedded
mmahrous has quit [Read error: Connection reset by peer]
<re_irc>
<trembel> Hi, short question:
<re_irc>
Is there a way using the stm32l0xx-hal to setup the RTC using the LSI clock?
dne has quit [Remote host closed the connection]
dne has joined #rust-embedded
Guest2 has quit [Quit: Client closed]
jringstad__ has quit [Quit: Leaving]
Amadiro has joined #rust-embedded
<re_irc>
<Mehmet Ali> Is there a way for cargo to build to a hex file?
tokomak has joined #rust-embedded
<re_irc>
<Mehmet Ali> Afaik hex has widespread use in debuggers etc
<re_irc>
<Mehmet Ali> I am trying to send my binary to a colleague who does not have the cargo ecosystem installed.
<re_irc>
<Mehmet Ali> We are trying to find our ways around cargo (emits .elf, I guess) and SEGGER J-Link suite
<re_irc>
<jannic> objcopy can convert from elf to hex.
<re_irc>
<adamgreig> if you "cargo install cargo-binutils" you can also "cargo objcopy --release -- -O binary foo.bin" which will build if needed and then use the right elf
<re_irc>
<Mehmet Ali> henrik_alser: -O ihex works like a charm
<re_irc>
<Mehmet Ali> is .bin also an accepted format?
<re_irc>
<Mehmet Ali> Also, I see that
<re_irc>
:020000022000DC
<re_irc>
<Mehmet Ali> The converted binary does not know baout memory.x of course.
<re_irc>
<Mehmet Ali> * ab out
<re_irc>
<Mehmet Ali> * about
<re_irc>
<ryan-summers> Both hex and bin files are essentially "binary-level". There's no link information or anything and they just encode what bits go at what addresses in the device. Check out https://en.wikipedia.org/wiki/Intel_HEX for information on the format of HEX files. Many editors have automatic highlighting to help if you're manually reading a hex file
<re_irc>
<adamgreig> the binary doesn't know its load address, it's just "whatever would get programmed to flash", while the .hex does know about the address
<re_irc>
<adamgreig> that said, your colleague should ideally be able to deal with elf files - they are a standard, not a cargo-specific thing
<re_irc>
<ryan-summers> Yeah, HEX doesn't have any implied start address - it encodes address info in the hex
<re_irc>
<adamgreig> I don't know about segger's tooling in particular but I'd hope it could handle elf, but perhaps it cannot
<re_irc>
<Mehmet Ali> adamgreig: I did quick google, and it seems that the support is either not there or obscured
<re_irc>
<Mehmet Ali> But let me search more thoroughly
<re_irc>
<Mehmet Ali> Hey, sorry all.
<re_irc>
<Mehmet Ali> Jlink supports .elf out of the box.
<re_irc>
<Mehmet Ali> The flasher was able to handle it.
<re_irc>
<Mehmet Ali> My quick google was not a huge banner like "J-Link Flasher supports elf files", but one should try first, I guess.
<re_irc>
<firefrommoonlight> omar_u8: What specific points have you had trouble with, or didn't match the RM well?
<re_irc>
<firefrommoonlight> I'm open to suggestions on stm32-hal
<re_irc>
<omar_u8> firefrommoonlight: I only started with HAL experimenting recently, so I can start with a particular case I ran into today, I was trying to figure out how to configure GPIO pins using the HAL for the STM32f401RE. I was looking at the data sheet and RM side by side to a working example in the HAL git repo. The datasheet states the steps as: 1) Configure the desired I/O as an alternate function in the GPIOx_MODER register...
<re_irc>
... 2) Select the type, pull-up/pull-down and output speed via the GPIOx_OTYPER, GPIOx_PUPDR and GPIOx_OSPEEDR registers, respectively 3) Connect the I/O to the desired AFx in the GPIOx_AFRL or GPIOx_AFRH register.
<re_irc>
In the example, there was the into_alternate() method being called that seemed to correspond to step 1, but where the rest was happening was not clear at all. If anything at least step 3 needed to be done as well, though navigating through the docs I could not clearly identify where that was happening. Obviously, if I were to do it on the PAC level following the same steps would be much easier.
<re_irc>
<omar_u8> Looking at other HALs sometimes I notice that for some peripherals there are usage examples as well. Though the way same things are done are different. Example PWM in the STMF1xx HAL vs the STMF4xx HAL.
<re_irc>
<burrbull> F1 chips are significantly different in questions of GPIO mode setting from other series
<re_irc>
<adamgreig> omar_u8: when you call into_alternate() you specify which AF needs to be written to AFRL/AFRH, but usually rust infers it for you
<re_irc>
<adamgreig> there's into_alternate_open_drain() if needed to take care of OTYPER, and .set_speed() and .internal_pull_up() and .internal_pull_down() for PUPDR/OSPEEDR
<re_irc>
<adamgreig> searching for things like "pull_up" or "open_drain" on the search bar there was how I found those methods just now
<re_irc>
<adamgreig> room hi everyone, meeting time again! agenda is https://hackmd.io/nn6Ntz71S4uAWsKrVocm5w, please add anything you'd like to announce or discuss and we'll start in 5min
<re_irc>
<adamgreig> very exciting "twosday" date
<re_irc>
<adamgreig> OK, let's start
<re_irc>
<adamgreig> only announcement I could find is that rust 1.59 comes out on thursday, with stable inline assembly, which should be nice for a lot of embedded users!
<re_irc>
<adamgreig> please shout if you have any other announcements or things to mention
<re_irc>
<therealprof> We'll have to wait until we can actually use it though. 😉
<re_irc>
<adamgreig> I can wait two more days
<re_irc>
<therealprof> MSRV - 2?
<re_irc>
<adamgreig> nope, MSRV is just "latest stable", has been for ages
<re_irc>
<adamgreig> so that leads us neatly to the next thing which is https://github.com/rust-embedded/cortex-m/pull/423 that swaps cortex-m/cortex-m-rt/cortex-m-semihosting/panic-semihosting to use asm/global_asm, no inline_asm feature, no pre-built binaries, no external assembly files, no outlined inline asm
<cr1901>
outline inline asm?
<re_irc>
<d3zd3z> I should mention that I just submitted a proposal to present on using non-C languages with Zephyr. Not sure how Rust-on-RTOS fits with the rest of the Rust Embedded community.
<re_irc>
<adamgreig> cr1901: the funny name we came up with for the current technique of using nightly rust with inline asm to build a static library that we then distributed and link against
<re_irc>
<therealprof> adamgreig: Hah, some adamgreig dude advocated to change it. I remember now. 😉
<cr1901>
ahhh
<re_irc>
<adamgreig> I think at the time I was proposing MSRV-2 and we discussed it at length in meetings and plain MSRV was more popular, but I wrote the RFC :P
<re_irc>
<adamgreig> d3zd3z: oh, cool! got a link or anything?
<re_irc>
<adamgreig> lots of people are very interested in rust-on-rtos
<re_irc>
<adamgreig> for the cortex-m PR, my proposal is that cortex-m itself doesn't change until 0.8, since that's already what's cooking in master, and keeps our old MSRV for the 0.7 series, which gives things more time to adapt if needed (and saves the effort of backporting the change)
<re_irc>
stable release. For example, if the latest stable Rust version was 1.32.1 a
<re_irc>
<therealprof> adamgreig: Before the change it was:
<re_irc>
new minor release of the `cortex-m` crate can't bump the MSRV higher than
<re_irc>
1.31.
<re_irc>
<d3zd3z> adamgreig: Nothing yet, I just came up with the idea and submitted the proposal today. I'll try to gather what information I have found. I'm also going to try to push for making Zephyr a little friendlier to non-C languages.
<re_irc>
<adamgreig> but for cortex-m-rt, we don't otherwise have breaking changes, and it tends to be used by executables more than libraries, so I'm a little tempted to keep it 0.7, but maybe the ~2-year jump in MSRV justifies going for 0.8 there too, not sure
<re_irc>
<therealprof> Before the change it was:
<re_irc>
new minor release of the `cortex-m` crate can't bump the MSRV higher than
<re_irc>
stable release. For example, if the latest stable Rust version was 1.32.1 a
<re_irc>
1.31.
<re_irc>
<therealprof> (Argh, pasting markdown seems to be broken)
<re_irc>
<thejpster> Any reason we can't make it 1.0?
<re_irc>
<adamgreig> thejpster: we _could_, but we have major changes to cortex-m in mind that seem more justified of 1.0... they could always be 2.0 of course, the current general design has certainly been quite stable
<re_irc>
<adamgreig> on the other hand, we've had breaking changes regularly enough that I'd rather keep it sub-1 at the moment personally
<re_irc>
<adamgreig> like, no major design changed from 0.5 to 0.6 to 0.7 and even 0.8 is basically tweaks to debug infrastructure, but they all had breaking changes that we'd have had to either not do or cause a 2.0/3.0/4.0 bump
<re_irc>
<jannic> As a debian developer I tend to prefer being conservative regarding MSRV - whatever is available in debian stable is fine :-)
<re_irc>
However, I see no reason at all not to use a recent rust release for embedded stuff.
<re_irc>
<adamgreig> conversely I don't see much argument _for_ 1.0 at the moment, literally all of cortex-m's dependencies are sub-1.0 too
<re_irc>
<adamgreig> jannic: yea, this is the sort of trade off that's tricky, we used to be a lot more conservative and in general still are (e.g. it's currently 1.42 which is from early 2020), but this is such a major improvement for these crates that it feels justified to me
<re_irc>
<therealprof> Yeah, good old going-1.0-trap. 😉
<re_irc>
<adamgreig> that cortex-m PR is a draft until thursday and needs a rustfmt run which I'll do before then, but otherwise it should all be in place if anyone wants to check it over
<re_irc>
<adamgreig> it should be functionally the same but there are a few style/functionality choices, especially around how it handles being compiled on non-thumb platforms
<re_irc>
<d3zd3z> I think Zeno's paradox applies to 1.0. There will be an endless, but possibly decreasing in magnitude things that should go in before 1.0.
<re_irc>
<adamgreig> and the cortex-m-rt part adds some new features that are very easy with global_asm
<re_irc>
<therealprof> d3zd3z: Yeah, that's why I usually skip 1.0 altogether.
<re_irc>
<adamgreig> hah, just go right for 2.0? or 2022.2?
<re_irc>
<therealprof> I actually prefer the latter but semver...
<re_irc>
<d3zd3z> Date-based versions an semver interact weirdly. I've seen things that are 2017.x, with a fairly large 'x' because there were no API changes, but the latest release was still 2022.
<re_irc>
<adamgreig> heh, it gets weird once you're into sort of the 53rd month of 2017 huh
<re_irc>
<therealprof> lol
<re_irc>
<adamgreig> there's also a killer macro lightly modified from dirbaio's work to get global_asm to work with #[cfg], heh
<re_irc>
<therealprof> You can also combine year with a sequential minor.
<re_irc>
<d3zd3z> Today, being 2017.05.1758 after all.
<re_irc>
<adamgreig> my understanding was that the position is the same as the WG's: there's no promise that the MSRV won't change after 1.0, and we won't consider it a breaking release, so probably the issue can just be closed, but I guess the statement in the readme could clarify that we'd be happy to change it
<re_irc>
<adamgreig> d3zd3z: I thought it was the 723rd of march, 2020...
<re_irc>
<adamgreig> (but this is for the HAL team...)
<re_irc>
<eldruin> yeah I think we should document the commitment clearly
<re_irc>
<eldruin> somethink like MSRV applies to minor releases like done elsewhere
<re_irc>
<eldruin> I mean, we will not update the MSRV in patch releases
<re_irc>
<eldruin> but we have not formally decided on this
<re_irc>
<eldruin> I can make a change proposal to the readme and we can vote on it
<re_irc>
<adamgreig> 👍️
<re_irc>
<eldruin> that is just what I would propose
<re_irc>
<adamgreig> the wg-wide policy is literally just "always build on stable", but it seems reasonable for e-h to document something like "will only bump on minor releases", especially since it's so widely depended-upon
<re_irc>
<therealprof> adamgreig: You know it used to be different. 😛
<re_irc>
<adamgreig> mabez: that's what it was written for first, right?
<re_irc>
<d3zd3z> How does this relate to "rust = "..."" in Cargo.toml?
<re_irc>
<mabez> adamgreig: Indeed!
<re_irc>
<adamgreig> ours is for global_asm instead of asm sicne we're not using naked functions yet
<re_irc>
<eldruin> I think it would be good to put the "perl revival" macro in a crate if possible
<re_irc>
<adamgreig> though I wish we could soon and get rid of all the CFI stuff, but... doesn't look like they'll land in time for 1.60
<re_irc>
<adamgreig> d3zd3z: ooh, good point, we should start adding that too, I'll add it to that PR
<re_irc>
<adamgreig> that just documents for Cargo what the MSRV of that crate is, so it can give helpful errors
<re_irc>
<adamgreig> maybe it can also use it to resolve dependencies actually, I'm not sure?
<re_irc>
<d3zd3z> Doesn't having a "rust =" in the toml file kind of give an MSRV as well, of at least the first version that included support for that?
<re_irc>
<therealprof> adamgreig: I don't think there's any effect on used dependencies.
<re_irc>
<eldruin> d3zd3z: yes, it does, it only makes sense if raising the MSRV beyond that
<re_irc>
<eldruin> but here cortex-m would raise the MSRV to latest stable so it's fine
<re_irc>
<adamgreig> (1.56 for rust-version)
<re_irc>
<d3zd3z> That should at least give more helpful errors than unstable feature errors, or just compilation failures.
<re_irc>
<eldruin> adamgreig: thanks! I always find myself reading through RFC issues and implementation tracking issues in the rust repo to find out in which version something became stable which is not part of the std docs
<re_irc>
<therealprof> d3zd3z: "rust-version =" you mean?
<re_irc>
<d3zd3z> therealprof: It looks like it. I guess I haven't tracked it since the original rfc.
<re_irc>
<therealprof> d3zd3z: No worries, just making sure we're talking about the same thing.
<re_irc>
<eldruin> for rustdoc they solved it nicely but in my opinion this is not easily visible from the RFC/tracking issues, which is what you are referred to by the compiler itself
<re_irc>
<therealprof> "#[stable_since="1989"]"
<re_irc>
<eldruin> like it happens to me when I am compiling something with an older rust where a certain feature was part of some PR but not stable yet. then I want to see when it became stable to decide whether to raise MSRV or whatever
<re_irc>
<eldruin> anyway different topic sorry
<re_irc>
<adamgreig> only other thing on the agenda is the e-h SPI split in https://github.com/rust-embedded/embedded-hal/pull/351 which has had some progress and updates since last time, when it was already "nearly ready to merge" I guess
<re_irc>
<eldruin> yeah almost, I need to catch up with rahix's latest coments
<re_irc>
<eldruin> but a general opinion from therealprof would be nice
<re_irc>
<therealprof> Ugh, not an avid SPI bus sharer here.
<re_irc>
<therealprof> General opinion is: if it works for people who care -- ship it.
<re_irc>
<eldruin> sounds good
<re_irc>
<eldruin> although note that it changes the overall SPI API also for not sharers
<re_irc>
<therealprof> Sure does. Time to bump "display-interface-spi" I guess.
<re_irc>
<adamgreig> great! is there anything else anyone would like to discuss?
<re_irc>
<therealprof> I'll have a look about the impact (on the HAL and user side) if I find some time.
<re_irc>
<firefrommoonlight> omar_u8: Is this clearer? This is the API I use:
<re_irc>
let mut rotor1 = Pin::new(Port::B, 0, PinMode::Alt(2));
<re_irc>
rotor1.output_speed(OutputSpeed::High);
<re_irc>
<firefrommoonlight> I guess you have to press the "I believe" button that it's doing all the steps you listed
<re_irc>
<firefrommoonlight> And the PAC directly would be better if you want to document each step inline for example
<re_irc>
<firefrommoonlight> For many multistep PAC procedures, I try to document HAL code line by line with RM quotes and references, but this still requires the end user to read the HAL code, so doesn't solve your concern completely
<re_irc>
<firefrommoonlight> -many
<re_irc>
let mut rotor1 = Pin::new(Port::B, 0, PinMode::Alt(2));
<re_irc>
<firefrommoonlight> Is this clearer? This is the API I use:
<re_irc>
rotor1.output_speed(OutputSpeed::High);
<re_irc>
rotor1.pull(Pull::Up);
<re_irc>
<firefrommoonlight> Until you learn you can "trust" a HAL, ie know its assumptions, the PAC can be more comfortable to work in
<re_irc>
<adamgreig> (let's end the meeting here, thanks everyone!)
tokomak has quit [Ping timeout: 240 seconds]
<re_irc>
<jkelleyrtp> Has anyone experimented with over-the-air updates for the nrf52 line of chips?
<re_irc>
<thalesfragoso> adamgreig: Dont forget inline outline inline asm, where we used linker-plugin-lto
<re_irc>
<thalesfragoso> I'm not sure I get the cfg_global_asm macro, is it calling global asm multiple times ? I.e. each time it finds a `#[cfg]` ?
<re_irc>
<adamgreig> thalesfragoso: May it rest in peace
<re_irc>
<adamgreig> thalesfragoso: It processes each tt in the input and builds up a stack, only including each tt where the cfg passes
<re_irc>
<adamgreig> It only calls global_asm once, at the end
<re_irc>
<GrantM11235> I can't figure out how to do multi-line suggestions on github PRs, otherwise I would do that
<re_irc>
<adamgreig> Click and drag by the line number
<re_irc>
<adamgreig> Like click as normal for a one line suggestion but then keep holding and drag
<re_irc>
<GrantM11235> Thanks!
<re_irc>
<jannic> I'm trying to implement the v1.0.0-alpha.7 traits for rp2040-hal. Are there any drivers available which already use them, so I can test the implementation?
<re_irc>
<GrantM11235> dirbaio et al: is there any way to automatically reconfigure the bus (word size, speed, phase/polarity, etc) for each transaction?
<re_irc>
<GrantM11235> Ah, I see that was brought up in the PR already