<whitequark>
they're not in for ARM yet though so I can't do that on stock rustc
<whitequark>
well that or an
<whitequark>
MPU
<cr1901_modern>
stack probe will detect when the stack crashes into the data section (and not just stack corruption; perfectly possible to crash into data section but you "just haven't used that data yet")?
<whitequark>
stack probe will *prevent* any corruption
<GitHub136>
[smoltcp] whitequark pushed 1 new commit to master: https://git.io/vQQdJ
<GitHub136>
smoltcp/master c5fc8f7 whitequark: Document the loopback.
froggytoad has joined #m-labs
<travis-ci>
m-labs/smoltcp#145 (master - c5fc8f7 : whitequark): The build passed.
<GitHub46>
[artiq] jordens commented on issue #782: What do you mean by "namespace", how would the help and what can you do with them that you can't do right now? "i2c" is the only i2c in that kc705 platform. In your platform with more i2c buses, you can call them e.g. "i2c_eem0" and "i2c". https://github.com/m-labs/artiq/issues/782#issuecomment-315362659
<jbqubit>
Also, it would be helpful to have a reference design for an ARTIQ device binary builder for KC705 suitable for toggling TTLs but nothing else.
<GitHub54>
[artiq] jbqubit commented on issue #783: Conda was stuck on an old version artiq-dev package. That is, conda update didn't work. Nor did conda install=version-no. So, erased ~/anaconda3 and reinstalled anaconda from scratch. And addressed #785. Now I can build. Closing. https://github.com/m-labs/artiq/issues/783#issuecomment-315458687
<GitHub185>
[artiq] jbqubit commented on issue #782: I2C wasn't the best example. Consider instead artiq/gateware/nist_clock.py which creates an "spi". This very nearly collides with migen/build/platforms/kc705.py "spiflash" and "mmc_spi". ... https://github.com/m-labs/artiq/issues/782#issuecomment-315467071
<GitHub178>
[artiq] jbqubit commented on issue #785: Adding the conda version constraint will save everybody time as it will flag an outdated version of conda. What's the problem with doing that in meta.yaml? https://github.com/m-labs/artiq/issues/785#issuecomment-315469391
<GitHub148>
[artiq] jordens commented on issue #782: Simply because the acronym "i2C" (or "SPI") occurs at all levels and in all repositories! Just because they refer to the same acronym doesn't mean "namespaces" are in order. Anyway, what do you mean by "namespace". And still the same three questions as above. https://github.com/m-labs/artiq/issues/782#issuecomment-315475271
<GitHub67>
[artiq] jordens commented on issue #782: What do you mean by "namespace", how would they help and what can you do with them that you can't do right now? "i2c" is the only i2c in that kc705 platform. In your platform with more i2c buses, you can call them e.g. "i2c_eem0" and "i2c". https://github.com/m-labs/artiq/issues/782#issuecomment-315362659
<GitHub35>
[artiq] jbqubit commented on issue #780: Can you give me a hand? See attached for the patch of what I've got. I'm modifying the phaser build for kc705 as a starting point. Several observations.... https://github.com/m-labs/artiq/issues/780#issuecomment-315475800
<GitHub120>
[artiq] npisenti commented on issue #782: Perhaps the appropriate way forward here is name mangling -- top-level user io mappings could be conventionally prefaced with a meaningful designator which is orthogonal to the underlying artiq/migen/misoc platform extensions. ... https://github.com/m-labs/artiq/issues/782#issuecomment-315480994