<cr1901_modern>
I just wanted to reduce the chance someone nitpicks since it takes a long time for patches to be accepted/reviewed
<rjo>
cr1901_modern: but that's not true. the configuration can be used just fine for debugging the target FPGA (even loaded with the target bitstream and not with the proxy bitstream). what would prevent that?
<cr1901_modern>
rjo: I was under the impression that the FPGA part of openOCD only interacted w/ the JTAG commands meant to load a bitstream, and wouldn't let you do anything else like boundary scan (or whatever else you can do w/ it)
<cr1901_modern>
If that's incorrect, I'll remove the comment
<rjo>
you can do whatever you like as long as its supported by the FPGA: boundary scans, play with the XADC, play svf, read the id, read back configuration.
<cr1901_modern>
I did not know this until today ._.
<cr1901_modern>
I've only ever used it for programming FPGAs
<cr1901_modern>
In any case, removing the comment
<cr1901_modern>
Pushed
cr1901_modern has quit [Ping timeout: 264 seconds]
<bb-m-labs>
build #2348 of artiq is complete: Failure [failed python_unittest_2] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/2348 blamelist: Florent Kermarrec <florent@enjoy-digital.fr>
<GitHub-m-labs>
[artiq] whitequark commented on issue #1005: Right. Overloading is not currently supported. Note that because of static dispatch, even once it's implemented, the results may be surprising. https://github.com/m-labs/artiq/issues/1005#issuecomment-389529456
<GitHub-m-labs>
[artiq] whitequark commented on issue #1005: Sure. You don't have to repeat this every time there's an issue in the compiler. You know I take error messages very seriously and fix every instance. https://github.com/m-labs/artiq/issues/1005#issuecomment-389530595
<GitHub-m-labs>
[artiq] whitequark commented on issue #1005: I don't remember the reason for not having overloading. It might be that once I fix the bug, it'll just work, with the caveat above (which already kicks in under different circumstances). https://github.com/m-labs/artiq/issues/1005#issuecomment-389531539
<marmelada>
afaict it's now the only difference between artiq and greg's init sequence
<marmelada>
since this is during chip resetting itself such clk may cause weird issues
<kristianpaul>
sb0: lol me either, but honestly lm32 is so simple to use that i'll give it a try again ;)
<sb0>
marmelada, I'm not completely up-to-date about how the SPI core and the HMC830 work; but maybe playing with CS polarity (cs_polarity_write) can toggle CS without touching the other signals?
<GitHub183>
[smoltcp] barskern commented on pull request #214 3d4a881: Would returning `None` in `poll_at` imply that we want to be polled immidiately? The tests pass using the following code.... https://github.com/m-labs/smoltcp/pull/214#discussion_r188676851
<GitHub65>
[smoltcp] whitequark commented on pull request #214 3d4a881: No, that's an accident. The return value for "polled immediately" is `Some(Instant::from_millis(0))`. You could actually put that in `Retransmit { expires_at }`, but `FastRetransmit` is definitely cleaner. https://github.com/m-labs/smoltcp/pull/214#discussion_r188680184
rohitksingh has joined #m-labs
<GitHub188>
[smoltcp] barskern commented on pull request #214 3d4a881: But isn't the return value from `poll_at` supposed to be an absolute value? So we're kinda returning that it should have been polled in the future? https://github.com/m-labs/smoltcp/pull/214#discussion_r188683027
<GitHub116>
[smoltcp] barskern commented on pull request #214 3d4a881: But isn't the return value from `poll_at` supposed to be an absolute value? So we're kinda returning that it should have been polled in the future?
<GitHub34>
[smoltcp] pothos commented on pull request #214 3d4a881: I'm not a reviewer, but I think I can answer your question. The return value of `poll_at` lands in `poll_delay` which is used for `wait`. `None` means to block until a packet arrives but a timeout of 0 will return immediately. `poll_delay` will do this for all return values of `poll_at` that are older than the current time given to `poll_delay`. To be sure I
<GitHub116>
[smoltcp] dlrobertson commented on pull request #214 3d4a881: See the implementation for UDP socket [here]. `Some(Instant::from_millis(0))` would be some time in the past, which means poll now AFAIK.... https://github.com/m-labs/smoltcp/pull/214#discussion_r188684161
<GitHub16>
[smoltcp] whitequark commented on pull request #214 3d4a881: It might actually be a good idea to make a enum for `poll_at`. Something like `enum PollAt { Never, Now, At(Instant) }`. The current situation is too opaque. https://github.com/m-labs/smoltcp/pull/214#discussion_r188692772
<GitHub-m-labs>
artiq/master 99f7672 Robert Jordens: ad53xx: tweak spi readback
<GitHub141>
[smoltcp] barskern commented on pull request #214 3d4a881: Yeah that would be just perfect! I was actually thinking about proposing it because like you say, currently it's non-intuitive. https://github.com/m-labs/smoltcp/pull/214#discussion_r188707520
<bb-m-labs>
build #2351 of artiq is complete: Failure [failed lit_test] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/2351 blamelist: whitequark <whitequark@whitequark.org>, Robert Jordens <jordens@gmail.com>, Sebastien Bourdeauducq <sb@m-labs.hk>
<GitHub198>
[smoltcp] whitequark commented on issue #215: > Isn't the smoltcp::phy::sys::wait there for providing this? I know it's conditionally compiled, however it is re-exported within smoltcp.... https://github.com/m-labs/smoltcp/issues/215#issuecomment-389620991
<GitHub177>
[smoltcp] barskern opened pull request #216: Implement new return type for `poll_at` (master...feature/poll-at-type) https://github.com/m-labs/smoltcp/pull/216
<GitHub-m-labs>
[buildbot-config] whitequark pushed 1 new commit to master: https://git.io/vpFp2
<GitHub-m-labs>
buildbot-config/master 9de06a6 whitequark: Fix artiq_corelog invocation to use artiq_coremgmt.
bb-m-labs has quit [Quit: buildmaster reconfigured: bot disconnecting]
bb-m-labs has joined #m-labs
<GitHub35>
[smoltcp] barskern commented on issue #216: The failed tests on Travis are because of the function `is_ingress`, which is currently only being used in the `TcpSocket`. I was thinking that this function will probably be useful in other contexts aswell to filter out non-interesting sockets. It is just to make that check a bit less verbose. I could add a attribute to conditionally compile it, but wouldn't that require un
<GitHub146>
[smoltcp] barskern commented on issue #216: The failed tests on Travis are because of the function `PollAt::is_ingress`, which is currently only being used in the `TcpSocket`. I was thinking that this function will probably be useful in other contexts aswell to filter out non-interesting sockets. It is just to make that check a bit less verbose. I could add a attribute to conditionally compile it, but wouldn't that
<GitHub148>
[smoltcp] m-labs-homu closed pull request #216: Implement new return type for `poll_at` (master...feature/poll-at-type) https://github.com/m-labs/smoltcp/pull/216
<GitHub177>
[smoltcp] m-labs-homu commented on issue #214: :umbrella: The latest upstream changes (presumably 3fb0c22fd4edcecd75f4c6767a86b0333cac9366) made this pull request unmergeable. Please resolve the merge conflicts. https://github.com/m-labs/smoltcp/pull/214#issuecomment-389685453
<travis-ci>
m-labs/smoltcp#946 (master - 3fb0c22 : Ole Martin Ruud): The build passed.