whitequark changed the topic of #glasgow to: glasgow debug tool · code https://github.com/GlasgowEmbedded/Glasgow · logs https://freenode.irclog.whitequark.org/glasgow
ali-as has quit [Ping timeout: 245 seconds]
englishm has quit [Excess Flood]
englishm has joined #glasgow
baka has joined #glasgow
mezu has quit [Ping timeout: 248 seconds]
_whitelogger has joined #glasgow
_whitelogger has joined #glasgow
_whitelogger has joined #glasgow
HexGlaze has quit [Ping timeout: 248 seconds]
HexGlaze_ has joined #glasgow
<whitequark> tnt: actually, I think maybe SPI master *should* in fact always allow fractional words
<whitequark> one reason: iCE40 wants some weird amount of dummy cycles like 17 or 42.
<tnt> whitequark: for the ice40 that's just a "nice to have" right ? those are minimum values. But I'm sure somewhere out there there is a device that needs it.
<whitequark> tnt: i am thinking of having a "3 wire serial" applet
<whitequark> and SPI, microwire, would actually reuse it
<whitequark> so if someone somewhere needs 17 bit SPI, it is simply a matter of deriving from a slightly different applet instead of a rewrite
<whitequark> tnt: oh... wait
<whitequark> that won't work
<whitequark> SPI sends MSB first...
<tnt> Ah yeah, the applet would have to do some byte shuffling before sending to the gateware (assuming the gateware can do both lsb/msb first bytes).
<whitequark> yea, something like that might work
<whitequark> but that casts some doubt on whether it's a good idea?..
<whitequark> does anyone do like, 16-bit SPI?
<tnt> I mean it's really just one single 24 bit word ...
<whitequark> awww yeah i remember such devices now
<whitequark> i think i actually have an ADC like that?
<tnt> Oh yeah, I remember some ADC being that way too.
<whitequark> i mean more like
<whitequark> ADC with 20-bit words
<whitequark> and the moment you clock in 21st bit it starts another conversion or something
<tnt> Yeah that rings a bell. I can't immediately find one like that but lookig at a bunch of them, they all have weird bit length adn some have aux control lines that need to be lined up with the spi data to control sampling.
_whitelogger has joined #glasgow
daveshah has quit [Ping timeout: 252 seconds]
daveshah has joined #glasgow
ali_as has joined #glasgow
<_whitenotifier-3> [GlasgowEmbedded/Glasgow] whitequark pushed 3 commits to master [+0/-0/±5] https://git.io/fj9hD
<_whitenotifier-3> [GlasgowEmbedded/Glasgow] whitequark c70d1d3 - applet.interface.jtag_probe: disable autoflush.
<_whitenotifier-3> [GlasgowEmbedded/Glasgow] whitequark 8c46f91 - applet.interface.spi_master: redesign command set to be like jtag_probe.
<_whitenotifier-3> [GlasgowEmbedded/Glasgow] whitequark a2845aa - applet.interface.spi_master: remove length restrictions.
<_whitenotifier-3> [Glasgow] whitequark opened issue #147: Refactor spi-master to use SERDES + sideband design - https://git.io/fj9hQ
englishm has quit [Excess Flood]
englishm has joined #glasgow
miek has quit [Ping timeout: 245 seconds]
miek has joined #glasgow
carl0s has joined #glasgow
carl0s has quit [Read error: Connection reset by peer]
<tnt> whitequark: for all the checks 'self._family == "56"', somehow I feel like checking for 430Xv2 core would be more appropriate. I think most mention of '5xx' '6xx' family in the doc is just legacy, now that other devices from other families are 430Xv2 as well ...
<whitequark> tnt: but I can know family from JTAG ID, but not core from JTAG ID
<whitequark> so there would have to be something like "self._core_not_xv2" or something
<whitequark> I mean, maybe that's better, yes...
<tnt> Ah yeah to know 430 vs 430X you need to read the device id.
<TD-Linux> I2S is another example of weird bit length spi
carl0s has joined #glasgow
carl0s has quit [Read error: Connection reset by peer]
<whitequark> aha
<tnt> In _write_control, what "policy" did you decide to use for the default state cntrl_sig = self._DR_CNTRL_SIG(R_W=1, TAGFUNCSAT=1, TCE1=1) that you picked ?
<whitequark> tnt: i dumped the bits used in all their examples and looked at the ones they always set
<whitequark> but, there are also good reasons
<whitequark> R_W=1 is set so that if you mishandle a transaction it does not write memory
<whitequark> they advise resetting R_W to read in a few places in the doc for this reason
<whitequark> (good advice.)
<whitequark> TCE1=1 is required to be set on every control write or the CPU is not under JTAG control after that write
<whitequark> I am not sure how that differs from releasing it via IR
<whitequark> it might be like "target continue" instead of "target detach"
<whitequark> TAGFUNCSAT=1 is some weird kinda flash thing, i have nfc what it does but they keep it always set
<whitequark> so i assume it's important
<tnt> Oh, yeah, also need some way to probe if the device is flash based or FRAM based ... procedures vary.
<whitequark> tnt: I would just transcribe the table
<whitequark> into glasgow.database
<whitequark> then you could have cpux=True|False and fram=True|False.
<tnt> ok, will do that.
<tnt> whitequark: not sure if you noticed, but the device ID is actually big endian ... :p
<whitequark> *sigh*
<tnt> (well technically it's specified as 2 bytes and not a 16b word, but 0x2553 device id makes more sense for a MSP430G2553 than 0x5325)
<whitequark> oh. ohhh
<whitequark> i thought it looked weird
<tnt> first attempt
<whitequark> looks basically good. please prefer .format() over %
<tnt> How do you '%r' using format ?
<whitequark> {:r}
<tnt> ok, til :)
<whitequark> it's the same things mostly but you can do things like
<whitequark> {:0{}b}
<whitequark> for precision
<whitequark> and yeah you finally can format as binary
<whitequark> that ext_id should probably just default to None
<whitequark> but this is all nits
<tnt> I'll fix the format. Trying to workout the conflicts atm ... (because of course device_id are not unique ...)
rcombs has joined #glasgow