Support channel names in RTIO errors #209
No reviewers
Labels
No Milestone
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: M-Labs/artiq-zynq#209
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "esavkin/artiq-zynq:1697-rtiomap"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Closes https://github.com/m-labs/artiq/issues/1697
@ -74,3 +75,2 @@
artiq_raise!("RTIOUnderflow",
"RTIO underflow at {0} mu, channel {1}, slack {2} mu",
timestamp, channel as i64, timestamp - get_counter());
format!("RTIO underflow at channel {}:{}, {{1}} mu, slack {{2}} mu", channel, resolve_channel_name(channel as u32)),
No. It's not "at channel".
@ -335,0 +354,4 @@
}
Ok(())
} ).or_else(|err| {
error!("read_device_map: error reading `device_map` from config: {}", err);
Why do you have the "read_device_map:" prefix here and not just above?
@ -9,6 +9,7 @@
#![feature(naked_functions)]
#![feature(asm)]
#[macro_use]
Why?
format macro wasn't available
I guess that works, but it will make porting this firmware to RISC-V later (to merge it with the main ARTIQ runtime) more difficult, since it relies on cache coherency which is not available on MiSoC/RISC-V.
So all
resolve_channel_name
calls should be made on the core1 (like in RISC-V version now)?I suppose you meant core0.
As long as we're on Zynq your proposed solution is more or less acceptable (though a bit ugly with the implicit synchronization), but we'll probably have to change it when merging firmwares.
3bc8c067d3
to7420a584eb
7420a584eb
tob249e69b4c
Changed that behavior so that it is more similar to RISC-V implementation.
@ -248,2 +248,3 @@
write_i32(stream, exception.id as i32).await?;
write_exception_string(stream, exception.message).await?;
if exception.message.len() == usize::MAX {
Obviously, all review comments from the ARTIQ PR are also applicable here.
@ -248,2 +248,3 @@
write_i32(stream, exception.id as i32).await?;
write_exception_string(stream, exception.message).await?;
if exception.message.len() == usize::MAX {
Obviously, all review comments from the ARTIQ PR are also applicable here.
Obviously, all review comments from the ARTIQ PR are also applicable here.
@ -248,2 +248,3 @@
write_i32(stream, exception.id as i32).await?;
write_exception_string(stream, exception.message).await?;
if exception.message.len() == usize::MAX {
Obviously, all review comments from the ARTIQ PR are also applicable here.
@ -248,2 +248,3 @@
write_i32(stream, exception.id as i32).await?;
write_exception_string(stream, exception.message).await?;
if exception.message.len() == usize::MAX {
Obviously, all review comments from the ARTIQ PR are also applicable here.
@ -200,3 +200,2 @@
artiq_raise!("RTIOUnderflow",
"RTIO underflow at {0} mu, channel {1}",
timestamp as i64, channel as i64, 0);
"RTIO underflow at {{1}} mu, channel {rtio_channel_info:0}",
Why is it
{{1}}
here and{1}
inartiq
?This remains unanswered and unaddressed.
In this version
format!
macro is used. In artiq - it is not@ -220,3 +227,3 @@
Ok(Packet::DestinationOkReply) => (),
Ok(Packet::DestinationSequenceErrorReply { channel }) =>{
error!("[DEST#{}] RTIO sequence error involving channel 0x{:04x}", destination, channel);
error!("[DEST#{}] RTIO sequence error involving channel 0x{:04x}:{}", destination, channel, resolve_channel_name(channel));
Message format is inconsistent with
artiq
.b249e69b4c
to439653b02a