You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The rtt-target crate assumes it is running on a 32-bit target. The use of pointers and usize in the header and channel structs prevent the crate from working on non 32-bit targets.
I hacked together a branch switching the pointers and usizes with u32s along with many try_into().unwrap()s sprinkled in to prove out it can work for a 64-bit target.
Is this a direction the crate would want to go? Ideally the pointer conversion checks would happen at compile time and we could prove some of the usize to u32 conversions would be infallible.
At a minimum the 32-bit limitation currently undocumented and could be called out in the README and docs.
The text was updated successfully, but these errors were encountered:
Yeah, I definitely want 64 bit support.
That might be inherently limited a bit though because you need to halt the core to read memory fast afaik, which kind of defies the purpose of RTT because it destroys any real-time guarantees it should give.
But I have not played with 64 bit targets, so I cannot tell how it's actually impacted.
The rtt-target crate assumes it is running on a 32-bit target. The use of pointers and
usize
in the header and channel structs prevent the crate from working on non 32-bit targets.I hacked together a branch switching the pointers and
usize
s withu32
s along with manytry_into().unwrap()
s sprinkled in to prove out it can work for a 64-bit target.Is this a direction the crate would want to go? Ideally the pointer conversion checks would happen at compile time and we could prove some of the
usize
tou32
conversions would be infallible.At a minimum the 32-bit limitation currently undocumented and could be called out in the README and docs.
The text was updated successfully, but these errors were encountered: