LPC11xx experimental branch #318
Conversation
farcaller
force-pushed
the
lpc111x
branch
2 times, most recently
from
96b6943
to
712ae37
Compare
This provides better error messages and more context is added by using the macros to configure replayer. The code seems to be thread-fragile though.
Proper way to do it discussed in hackndev#329
| }).unwrap(); | ||
| let res = j.join(); | ||
|
|
||
| expect!(res.is_err()).to(be_equal_to(true)); |
There was a problem hiding this comment.
I think it can be:
expect!(res).to(be_err());There was a problem hiding this comment.
Yup, apart from the issue that it was a compiler error for some reason 😄
There was a problem hiding this comment.
compiler error for some reason
Two hip-hip hoorays for having to track nightlies!
There was a problem hiding this comment.
Two hip-hip hoorays for having to track nightlies!
Did I tell you that we will need to fork cargo to keep the nightly going? Buy the ticket, take the ride! 🎢
There was a problem hiding this comment.
we will need to fork cargo
because of rust-lang/cargo#1796 ?
farcaller
force-pushed
the
lpc111x
branch
4 times, most recently
from
5a03594
to
4af51e8
Compare
farcaller
force-pushed
the
lpc111x
branch
2 times, most recently
from
0f9a975
to
240ae86
Compare
|
This fixes lots of things apart form lpc11xx so I will land it now and deal with consequences later. LPC11xx is still non-existent and isn't expected to work meaningfully. |
Build fixes; basic lpc11xx support; better tests for zinc crate
This is work in progress of my attempt to an architecture based purely on the placement ioregs (the reason why it's not lpc176x getting a refab is that this mcu has just 20 register blocks and is rather trivial).
The ideas I want to pinpoint are:
mod regsis private, any access is done via relevant APIs that areunsafewhen reasonable