cyrillu[m] has quit [Ping timeout: 252 seconds]
cyrillu[m] has joined #glasgow
ec0 has quit [Ping timeout: 245 seconds]
pg12_ has quit [Ping timeout: 245 seconds]
jn__ has quit [Ping timeout: 245 seconds]
ec0 has joined #glasgow
jn__ has joined #glasgow
pg12_ has joined #glasgow
_whitelogger has joined #glasgow
futarisIRCcloud has joined #glasgow
Getorix has quit [Ping timeout: 240 seconds]
<whitequark> esden: windows is sort-of supported
<whitequark> note that one thing about windows support is that the first time you plug in Glasgow, it HAS to be preloaded with firmware on 8051
<whitequark> or winusb will break until some awful things are done with registry
<esden> uhh good to know ...
<esden> so we should probably ship out all the glasgows with firmware loaded onto the eeprom for fx2
<sorear> is osx support{ed,able} at all
<whitequark> esden: yes definitely
<whitequark> sorear: it's certainly supportable
<whitequark> the amount of goodwill i have for testing things on macos these days is approaching zero rapidly
<whitequark> i'm pretty sure people already made it work
pg12_ has quit [Quit: pg12_]
pg12 has joined #glasgow
<_whitenotifier> [GlasgowEmbedded/Glasgow] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/JecMM
<_whitenotifier> [GlasgowEmbedded/Glasgow] whitequark 48fc08f - cli: fix misbehavior on ^C if an applet doesn't flush at the end.
m4ssi has joined #glasgow
craigo has quit [Ping timeout: 240 seconds]
<emily> yeah, people have gotten it working
<emily> and I try to keep the nixpkgs packages building on darwin
diverger has quit [Read error: Connection reset by peer]
diverger has joined #glasgow
craigo has joined #glasgow
danilonc has quit [Ping timeout: 265 seconds]
danilonc has joined #glasgow
Exec1N has joined #glasgow
<electronic_eel> esden: I just found some more small nits - how come you know me better than myself?
<electronic_eel> block diagram, i2c bus line above the upper settable power supply, there is a small break in the line
<electronic_eel> block diagram, upper settable power supply block, the red power arrow leaving the power supply leaves at a different position than the one on the lower power supply. I think the arrow one the lower one looks better
<electronic_eel> block diagram, black arrows between pullup/down and the GPIOs, the end of the arrow touches the "GPIO Fontend" block. I think it looks better if there is a small space between them like in the original diagram
Exec1N has quit [Ping timeout: 240 seconds]
Exec1N has joined #glasgow
m4ssi has quit [Remote host closed the connection]
<esden> I am calling it good and will update the page. I think remaining nitpick improvements will have to wait for the official campaign launch page. :D
Exec1N has quit [Ping timeout: 240 seconds]
<electronic_eel> esden: thank you for incorporating my improvement ideas, looking very good now
<tnt> Did anyone use the jtag-svf applet to program an ecp5 ?
<whitequark> yes
<whitequark> works fine for me
<tnt> And loading a svf should just load the 'runtime' config right ? ignoring whatever is in flash ?
<whitequark> yes
<whitequark> i think it may depend on the svf file actually
<whitequark> but the default by ecppack should do that
<tnt> Looks like the very last SDR fails.
<whitequark> hm
<whitequark> strange
<daveshah> What is your ecppack command line
<tnt> ecppack --svf out.svf --input test.config
<daveshah> Seems fine - I know sometimes the chip gets unhappy with bitstreams with SPI flash commands (when setting mode or frequency) being sent over JTAG
<tnt> I do get "W: g.applet.interface.jtag_svf: SVF: test vector did not reset DUT explicitly, resetting"
<tnt> but ... not sure if that's an issue.
<daveshah> Can you see what the last SDR does read?
<tnt> E: g.applet.interface.jtag_svf: SDR command failed: TDO <00000000011110000000000000000000> & <00000000100001000000000000000000> != <00000000100000000000000000000000>
<ktemkin> in the case where the extra SPI flash commands makes it unhappy, it'll report that the bitstream "provides data past the device's SRAM array"in its status register
<tnt> Is the meaning of the bits explained somewhere ?
<daveshah> tnt: yes, in the sysCONFIG TN
<daveshah> that looks like 9, 10, 11, 12 which means "not done; read and write enabled; configuration logic is busy" afaics
<daveshah> maybe glasgow is just too fast...
<mwk> glasgow being too fast has happend before
<tnt> Arf I changed the pause at the end from 1ms to 1s and now it doesn't report any error ...
Exec1N has joined #glasgow
<tnt> Although I'm not sure my design is actually loaded, looks like it still loaded the flash one.
<tnt> Arf no ... pebkak.
<tnt> So I had programn defined in the top level but not assigned to anything (since it was just a blinky test). ysosy mapped it to default 1'b0. So when jtag loading was done, it was immediately rebooting to flash and I guess the jtag probe for 'done' was happening right during the flash reconfig.
<daveshah> Ah that makes sense
<_whitenotifier> [Glasgow] electroniceel opened pull request #166: applet.interface.i2c_master: add "scan" command - https://git.io/JecjH
Exec1N has quit [Ping timeout: 240 seconds]
<esden> electronic_eel: Thank you for all your input. The diagram is definitely better now. :)
<esden> (still waiting for CS to update the page though...)
<emily> "1BitSquared's Glasgow" oh dear :)
ali_as has quit [Ping timeout: 240 seconds]
grazfather has joined #glasgow
<grazfather> will the glasgow use some host-side tool to flash bitstreams for certain protocols? As opposed to using a shell-line inverface over uart?
<grazfather> oh damn, yeah that appears to be the case 'glasgow applet'
<sorear> welcome
<zeiris> applet + gateware being defined in the same python file is hella cool
<emily> grazfather: applet gateware is automatically generated, synthesized and flashed when you `glasgow run applet`
<emily> which takes only a few seconds
<sorear> grazfather: curiosity: did you just discover the project, and if so where?
<tnt> can't wait for bitstream caching ... I'm currently oscillating between the jtag-svf and uart applet and it's annoying :p
thaytan has quit [Ping timeout: 265 seconds]
thaytan has joined #glasgow