<conplan>
it simply tries to download bare-metal 1.3.0
<conplan>
for some reason, m program keeps trying to install bare metal 0.1.3 why might this be the case?
<re_irc>
<adamgreig> is it a problem? you presumably have a dependency on it (try running "cargo tree" to see why), but it should build OK
<re_irc>
<adamgreig> aah, I see, in 0.1.3 the const-fn feature was made default
<re_irc>
<adamgreig> so I think you probably want to either increase the version of bare-metal (it's probably being depending on by the PAC you're building, in its Cargo.toml)
<re_irc>
<adamgreig> or set it to default-fatures=false, also in the Cargo.toml, so that const-fn isn't enabled
<re_irc>
<adamgreig> you're building a 4-year-old crate it looks like, which used some unstable (nightly) compiler features at the time, which have long since been removed
<re_irc>
<adamgreig> you might have a better time seeing if anyone has a newer PAC for this msp430, or generating one yourself using svd2rust (https://crates.io/crates/svd2rust)
<conplan>
re_irc: ok, I figured it out. msp432p401r-hal requires msp432p401r-pac 0.1.0, which requires bare-metal 0.1.3. HOWEVER, msp432p401r-pac has version 3.0, which requires bare-metal 0.1.3
<conplan>
so, how do I get msp432p401r-hal to look for msp432p401r-pac 0.3.0
<re_irc>
<adamgreig> you will want to download msp432p401r-hal yourself too, and modify its Cargo.toml to require the pac 0.3.0, and depend on your local copy in your project
<re_irc>
<adamgreig> I vaguely recall another crate like "managed" that abstracted over either being given a Vec that could be grown/sized using the system allocator, or being given a mutable reference to a buffer that couldn't be grown, does anyone remember?
<re_irc>
<adamgreig> for libraries that want to support having an allocator being convenient but with the option to just have everything statically allocated
conplan has quit [Ping timeout: 252 seconds]
conplan has joined #rust-embedded
starblue has quit [Ping timeout: 264 seconds]
starblue has joined #rust-embedded
<conplan>
re_irc: questions beget more questions. I've been able to compile the dependencies, but now I'm getting a new error: a bunch of unresolved imports
<re_irc>
<adamgreig> (just by the way, re_irc is the IRC bridge for the Matrix chat room, the username in brackets afterwards is the person talking from there)
<conplan>
gtk
<conplan>
from crates I know I've included. it says that the msp432p401r is 'misssing from the root' what does this mean?
<re_irc>
<adamgreig> I wonder if you might have a better time picking a 2018 nightly rust edition and trying with that, back when all these crates presumably worked together... quite unsatisfactory though
<conplan>
do you know what it means for a crate to be 'missing from root'
<re_irc>
<adamgreig> no, afraid not. it might help if you can post a pastebin of the complete error message
<re_irc>
<adamgreig> I have to run now though, good luck!
<conplan>
is it normal to have to add dependencies of other dependencies to cargo.toml
<conplan>
that seems a little unneccesary
<re_irc>
<9names (@9names:matrix.org)> If you're just using the HAL you should be able to add the git version of msp432p401r-hal as a dependency instead of using the version on crate.io.
<re_irc>
It already uses the newer pac, etc.
<re_irc>
I cloned and built the examples and it all just worked.
<re_irc>
<9names (@9names:matrix.org)> No, manually patching deps of deps is not common but it does come up every so often.
<re_irc>
I documented the config in the README (added Cargo.toml info)
<re_irc>
One thing that's a bit unusual is the "FLASH : ORIGIN = 0x08004000"
<re_irc>
I have to admit that I know almost nothing about linking, ELF files, etc. so I wouldn't know where to find a linker script and if there is one 😅
<re_irc>
This is set up this way because the bootloader (separate binary) sits at "0x08000000"
<re_irc>
<dimpolo> adamgreig: I'll see what I can do, thanks for looking into this!
starblue has quit [Ping timeout: 246 seconds]
starblue has joined #rust-embedded
hwj has joined #rust-embedded
<re_irc>
<dimpolo> You might have some "unwrap" or "assert_eq!" calls that implicitly format stuff on failure
<re_irc>
<adamgreig> You might also want to have cargo build core, perhaps you have panics coming from there?
<re_irc>
<adamgreig> dimpolo: the big 0x4000 offset isn't a problem I don't think, it's the 0xf4 offset of the first section that's very weird and throwing things off, and I think it's exactly the size of your vector table which indeed doesn't appear to be in the binary
<re_irc>
<adamgreig> are you using cortex-m-rt? if so it provides a linker script and you provide a "memory.x" file that is included into the linker script, so that's the file to look at
<re_irc>
<adamgreig> hmm, or like, some of the vector table is there? I don't know why you have this 244-byte offset
<re_irc>
<adamgreig> dimpolo: the big 0x4000 offset isn't a problem I don't think, it's the 0xf4 offset of the first section that's very weird and throwing things off, and I think it's maybe the size of your vector table?
oak- has quit [Quit: Bridge terminating on SIGTERM]
oak- has joined #rust-embedded
hwj has quit [Ping timeout: 246 seconds]
<re_irc>
<korken89> Is there a way to get the number of priority bits at runtime from some register, or a way to figure it out?
<re_irc>
<korken89> It shows how many interrupt vectors there are
<re_irc>
<korken89> I want to know how many priority bits the NVIC has
<re_irc>
<datdenkikniet> Ah, not the amount of priorities
<re_irc>
<korken89> Without needing a PAC
conplan has quit [Remote host closed the connection]
<re_irc>
<dirbaio> do unimplemented prio bits always read as zero? then you could write 0xFF and read back and count ones
<re_irc>
<korken89> Hmmmm
<re_irc>
<korken89> Sneaky, I like it
<re_irc>
<datdenkikniet> dirbaio: AFAICT it's not a requirement (reading the docs for "Interrupt Priority Registers" on that same page)
<re_irc>
<datdenkikniet> * page only says "an app may work even if it doesn't know how many priorities are available")
<re_irc>
<datdenkikniet> * requirement, reading the docs for "Interrupt Priority Registers" on that same page only says "an app may work even if it doesn't know how many priorities are available", and nothing about reserved bits in those registers
<re_irc>
<dirbaio> iiuc that means the app can write any 8bit prio value, but that doesn't necessarily mean all 8 bits will "stick"
<re_irc>
<datdenkikniet> no, very true! But then it would be a manufacturer/implementor specific deal, I guess?
<re_irc>
<dirbaio> instead lower bits are ignored, making the priority level less "granular"
<re_irc>
<datdenkikniet> * yes,
<re_irc>
<dirbaio> uh I don't think each manufacturer can customize NVIC like that
<re_irc>
<dirbaio> they just set the amount of prio bits
<re_irc>
<dirbaio> i'd say if you test it on one chip and unimplemented prio bits read as zero, then that'll be the case in the NVIC of all chips
<re_irc>
<datdenkikniet> right, that would make more sense
<re_irc>
<datdenkikniet> dirbaio: Aha! The armv7m architecture manual actually confirms this, you're spot on! ref (https://documentation-service.arm.com/static/606dc36485368c4c2b1bf62f), section B1.5.4: "l priority value fields are 8-bits, and if an implementation supports fewer than 256 priority levels then low-order bits of these fields are R[ead-]A[s-]Z[ero]."
<re_irc>
<datdenkikniet> * "All
hwj has joined #rust-embedded
hwj has quit [Ping timeout: 246 seconds]
neceve has quit [*.net *.split]
Darius has quit [*.net *.split]
fooker has quit [*.net *.split]
fooker has joined #rust-embedded
neceve has joined #rust-embedded
neceve has joined #rust-embedded
neceve has quit [Changing host]
Darius has joined #rust-embedded
causal has quit [Quit: WeeChat 3.6]
conplan has joined #rust-embedded
<conplan>
finally got my MSP432p401r hal based project to compile! now I just have to figure out uniflash
Foxyloxy has quit [Remote host closed the connection]
Foxyloxy has joined #rust-embedded
conplan has quit [Remote host closed the connection]
explore has joined #rust-embedded
hwj has joined #rust-embedded
explore has quit [Quit: Connection closed for inactivity]
hwj has quit [Remote host closed the connection]
causal has joined #rust-embedded
conplan has joined #rust-embedded
conplan has quit [Remote host closed the connection]
conplan has joined #rust-embedded
<conplan>
anyone here know anything about openocd and the MSP432p401r
dc740 has joined #rust-embedded
neceve has quit [Ping timeout: 246 seconds]
neceve has joined #rust-embedded
conplan has quit [Remote host closed the connection]
dc740 has quit [Remote host closed the connection]