cyrillu[m] has left #glasgow ["Kicked by @appservice-irc:matrix.org : Idle kick: User has been idle for 30+ days."]
_whitelogger has joined #glasgow
ali_as has quit [Ping timeout: 245 seconds]
_whitelogger has joined #glasgow
_whitelogger has joined #glasgow
_whitelogger has joined #glasgow
_whitelogger has joined #glasgow
_whitelogger has joined #glasgow
_whitelogger has joined #glasgow
_whitelogger has joined #glasgow
<tnt>
bits manipulation with python list semantic are just ... confusing. I have to write b[16:20] + b[0:16] when really I want to be writing b[15:0] + b[19:16] (yes, I know it's not "pythonic" but that's just how bit notation works)
ali_as has joined #glasgow
<whitequark>
tnt: the problem is not that it's "pythonic" or not
<whitequark>
the problem is that every single other container (including the bitarray we used before) does not work like that
<whitequark>
also, i'm pretty sure you can write b[0:15] in verilog too
<whitequark>
tnt: and actually it will simply not work if i did it, because overloading __getitem__ tells python this is a container
<whitequark>
and things like list(bits) will iterate through it
<whitequark>
from low to high
<whitequark>
so you'd need b.slice(15,0)...
<tnt>
And it's as wrong in verilog too :p (just like in VHDL you can write std_logic_vector(0 to 15) as well instead of std_logic_vector(15 downto 0)). And I'm not saying there aren't implementation reasons for which it's hard to do otherwise. I'm just saying it'd be more natural if it was the other way.
<tnt>
(at least for me)
<whitequark>
tnt: i mean, it would be less confusing for you but more confusing for everyone else who touches that file
<whitequark>
this is a clear loss overall
<whitequark>
the same reason (n)migen use [low:high] indexing btw
<tnt>
yeah, and I hate it in migen as well :)
<whitequark>
that's kind of just how life is, i guess
<whitequark>
i mean, do you know just how much i hate python?
<whitequark>
the only reason glasgow is in python is for collaboration. if i was doing it solely for myself i'd have used ocaml
<tnt>
Oh yeah that would probably have reduced the user/dev base for sure.
<whitequark>
yeah. to one.
<tnt>
I think MLDonkey is the only ocaml app I ever did changes to :)
cyrillu[m] has joined #glasgow
<tnt>
So, to get the 430Xv2 under jtag control, you need to (among other) execute the ExecutePOR_430Xv2 macro, whose exact process depends if the device is FRAM or Flash based, and to know that you need the device ID, but to read that you need the device to be under jtag control.
<whitequark>
tnt: classic
<yorick>
whitequark: the corsair force 1tb m.2 ssd is really cheap in comparison to all the others
<whitequark>
is it any good tho
<whitequark>
also 1tb ones aren't too expensive for me
<whitequark>
it's more that 2tb ones don't even seem to be *imported*
<yorick>
the roommate hasn't noticed any problems
<yorick>
660p 2tb is half as fast as the others but also half the price
<yorick>
(intel)
<tnt>
So ... there is a jtag instruction called IR_DEVICE_ID which you would think returns the device ID ... but no, it returns a memory pointer to where you can read the device ID from.
<whitequark>
incredible
<whitequark>
though, that's still useful, no?
<whitequark>
make it a tiny bit future-proof
<tnt>
Sure. Excepts it's only on v2 devices which currently have all their ID at the same place. But yeah, I guess for the future.
diverger has joined #glasgow
<_whitenotifier-3>
[GlasgowEmbedded/Glasgow] whitequark pushed 2 commits to master [+0/-0/±5] https://git.io/fjHoA
<_whitenotifier-3>
[GlasgowEmbedded/Glasgow] whitequark abd4673 - applet.interface.jtag_probe: factor out run_tap() from derived applets.
<_whitenotifier-3>
[GlasgowEmbedded/Glasgow] whitequark c8ebd6b - applet.program.xc9500xl: be more resistant to incorrect connections.