Back
[01:00:19] <kwallace> I'm trying to recall an .ini entry I may have made a while back but can't seem to remember -- features = 4 and found
https://github.com/araisrobo/linuxcnc/blob/master/tests/interp/abort-hot-comment/test.ini
[01:01:08] <kwallace> Gremlin and lathes seem to come to mind, maybe -- any ideas?
[01:14:34] <kwallace> I'll have to sleep on it, G'night.
[01:37:51] ChanServ changed topic of
#linuxcnc-devel to:
http://linuxcnc.org | Latest release: 2.6.2
[10:42:27] <cradek> seb_kuzminsky: yay! thanks again.
[11:01:39] <seb_kuzminsky> :-)
[11:08:15] <seb_kuzminsky> the only release-manager thing i can't do is update the www.linuxcnc.org front page News section
[11:08:36] <archivist> just like London buses , you wait ages then 3 come at once.../me ducks
[11:11:13] <seb_kuzminsky> heh
[11:12:30] <seb_kuzminsky> both the .1 and .2 bugfixes could have been found sooner if people had been testing the -pre releases... /me ducks
[12:28:47] <jepler> pcw_home: so it looks like that first word should read back as AAAAAAAA ?
[12:29:14] <pcw_home> Yes
[12:29:56] <jepler> none of the phase and polarity flags have given me that
[12:30:11] <pcw_home> Hmm
[12:30:15] <jepler> 55 55 55 54 B5 55 AA A0 45 55 A3 00 55 55 55 54
[12:30:31] <jepler> that's what I read back with all 4 of the phase / polarity options
[12:30:44] <pcw_home> what clock rate?
[12:31:36] <jepler> supposed to be 500kHz
[12:32:38] <pcw_home> CS timing maybe
[12:33:32] <jepler> I don't seem to have any CS timing control on the linux end
[12:33:58] <jepler> btw mode 0 and 3 give consistent values (55 55 55 54), mode 1 and 2 give varying values
[12:36:59] <pcw_home> the SPI slave interface samples input data on the clock rising edge and outputs data on the falling edge
[12:37:01] <pcw_home> (this matches CPOL,CPHA = 0,0 AFAICT)
[12:38:17] <jepler> scope shows ~3us from falling /CS to first falling edge of SCK
[12:39:50] <pcw_home> ok so plenty
[12:40:51] <jepler> I guess I should dig out my logic analyzer, a 2-channel scope is not the right tool for this
[12:40:57] <pcw_home> so SPI master should sample its input data on rising edge of clock, but it sounds like it is not
[12:41:07] <jepler> is it right that SCK should be high at the start and end of the transaction?
[12:41:15] <pcw_home> no
[12:41:27] <pcw_home> wrong cpol
[12:41:51] <pcw_home> should idle low
[12:45:08] <jepler> hmm
[12:45:33] <jepler> both choices for clock polarity have clock being high at the falling edge of CS
[12:46:06] <pcw_home> CPOL setting is broken maybe
[12:48:35] <jepler> hmm, somewhere along the line the 7i31 blinkenlights changed from being all lit
[12:48:43] <jepler> something must have been received and acted on
[12:48:50] <jepler> not the lights pattern I intended, however
[12:50:54] <pcw_home> if the clock starts high the first falling edge will output bit 30 (bit 31 will be lost)
[12:51:22] <pcw_home> (the 0x5555554)
[12:51:34] <jepler> what happens when I change CPOL is that the first clock pulse is a runt
[12:51:45] <jepler> I can get ~~~~~~~_~~__~~__~~...
[12:51:52] <jepler> or ~~~~~~~__~~__~~__~~...
[12:52:43] <pcw_home> as long as they happen when CS is not asserted, they dont matter
[12:52:55] <jepler> oh no, this is all after CS goes low
[12:53:15] <pcw_home> oops thats just wrong
[12:54:20] <pcw_home> http://en.wikipedia.org/wiki/Serial_Peripheral_Interface_Bus
[12:54:53] <pcw_home> maybe the driver is dwiddling with the modes dynamically
[12:54:55] <jepler> no, that's not particularly how my waveform looks
[12:55:25] <jepler> SCK is just not behaving like that
[12:55:33] <pcw_home> My guess is the driver is funky
[12:55:49] <jepler> that's not what I wanted to find out
[12:56:30] <pcw_home> it can be worked around if need be
[12:57:42] <pcw_home> if CPOL =1 makes the clock look right the FPGAs polarities could be fixed
[12:58:15] <jepler> all the combinations I bothered to scope so far have clock being at high logic level at the start
[12:58:33] <pcw_home> weird
[12:58:45] <jepler> no sign of functional fixes to the driver ("s3c24xx") since the tree I'm working from
[12:59:10] <jepler> bbl, farmer's market time
[12:59:19] <pcw_home> Bye
[13:11:04] <CaptHindsight> doesn't take up much FPGA space and there's a SPI analyzer plugin
http://www.sump.org/projects/analyzer/client/
[14:18:47] <jepler> CaptHindsight: actually I just brought a board with that on it upstairs
[14:18:54] <jepler> last time I used it, the software was irritating
[14:19:11] <jepler> worse, it was java
[14:19:55] <CaptHindsight> yeah, just a low budget for-what-it's-worth suggestion
[14:20:06] <jepler> sure, I appreciate it
[14:23:08] <CaptHindsight> I was thinking the VHDL could be modified to only 6-8 channels for things like this
[14:23:44] <CaptHindsight> and sit on a mesa FPGA with enough spare gates
[14:24:13] <CaptHindsight> add logic analyzer to HAL
[15:13:00] <pcw_home> actually if the clock is high when CS is asserted (and CPOL is 0) you dont need a logic analyser
[15:13:01] <pcw_home> this needs to be fixed in the driver (or if the hardware is broken, make a SPI slave that works with CPOL=1)
[15:19:08] <jepler> so the logic analyzer sees a rather noisy version of the signals
[15:19:15] <jepler> reading on the 5V side after the TXB0401
[15:20:31] <jepler> but what I thought I had seen with the clock starting out high is not there now
[15:20:52] <jepler> .. there have been many reboots of the odroid in between, so it's possible some bad register setting will stick, rather than getting cleared
[15:22:14] <memleak> what API used by the machine plot UI? the screen where it shows the backplot / visual trace of the machine?
[15:22:22] <memleak> *is used
[15:22:48] <memleak> i.e. opengl, directfb, sdl, etc.
[15:23:01] <jepler> memleak: opengl
[15:23:15] <jepler> http://emergent.unpythonic.net/files/sandbox/ow-my-cs.png
[15:23:18] <memleak> oh nice!
[15:23:31] <jepler> I don't even know what the mesa's supposed to do with a waveform like that!
[15:28:51] <Tom_itx> is CS active low?
[15:29:01] <jepler> Tom_itx: yes
[15:29:08] <Tom_itx> same with the data?
[15:30:03] <Tom_itx> doesn't look so odd... you should expand it to a couple transfers
[15:30:19] <jepler> you don't think it's weird for CS to go high for a few ns in the middle of a transfer?
[15:30:19] <Tom_itx> the saleae will give you hex data out
[15:30:38] <Tom_itx> i can't tell where the transfers start or stop
[15:30:42] <Tom_itx> between bytes?
[15:30:45] <jepler> one transfer is shown there
[15:30:49] <Tom_itx> it could be a bit odd yes
[15:31:36] <jepler> http://emergent.unpythonic.net/files/sandbox/ow-my-cs2.png
[15:31:39] <jepler> there it is zoomed in
[15:32:02] <Tom_itx> are they long enough to interfere?
[15:32:05] <jepler> I am pretty confident that is just noise on CS
[15:32:08] <Tom_itx> looks 'not normal'
[15:32:33] <Tom_itx> they're not very wide for sure
[15:32:57] <Tom_itx> i wonder what else is switching at those times
[15:33:05] <Tom_itx> is it coming from the fpga?
[15:33:15] <jepler> if I zoom further, almost all of the spurious pulses are at a moment when SCK has a transition
[15:33:59] <jepler> the setup for this trace is: oduino SPI @ 1.8V -> 6" wire -> TXB0401 level translator @ 5V -> 6" wire -> open logic sniffer with its own level translation chip
[15:34:01] <Tom_itx> is CS held high and pulled low? maybe add a pulldown on it to see what happens
[15:34:08] <CaptHindsight> http://www.kerrywong.com/blog/wp-content/uploads/2013/02/SPI.png SPI (write)
[15:35:41] <jepler> Tom_itx: I don't have accurate information about the I/O details of the SPI pins, beyond that they are on a 1.8V standard
[15:35:53] <jepler> so it is possible that CS is open collector or something like that
[15:36:01] <Tom_itx> yeah
[15:36:12] <Tom_itx> i wouldn't think so but you never know
[15:36:25] <jepler> er, odroid, not oduino
[15:36:28] <jepler> so many damned devices
[15:36:46] <Tom_itx> this is on the arm device?
[15:36:57] <jepler> yes
[15:37:17] <jepler> mesa card is not even hooked up in this test
[15:37:28] <Tom_itx> ok
[15:38:22] <CaptHindsight> plus SPI has 4 modes for clock polarity and clock edge
[15:38:29] <Tom_itx> right
[15:38:36] <Tom_itx> CPOL CPHA sets that
[15:40:02] <jepler> assuming that the driver handles the various modes correctly, just trying all 4 modes didn't give a working result
[15:40:03] <pcw_home> currently CS high clears the bit count so glitches on CS are bad
[15:40:17] <pcw_home> bit count
[15:43:21] <jepler> perhaps my choice of level translator was a poor one.
[15:43:39] <jepler> it had the virtue of being on a breakout board :-/
[15:44:34] <pcw_home> you might scope CS on the 1.8V side
[15:47:32] <pcw_home> I had intended to put a digital filter on CS, that might help
[15:47:34] <pcw_home> (also make sure you have multiple grounds, dont need much ground bounce to get to a 1.8V logic high
[15:47:35] <pcw_home> maybe as little as ~0.7V
[15:50:32] <CaptHindsight> looks like all SPI signals on that board are just brought right to a header, no passives
[15:51:41] <CaptHindsight> https://doc-0s-4g-docs.googleusercontent.com/docs/securesc/ha0ro937gcuc7l7deffksulhg5h7mbp1/qbl6iul9dfn8vknsk6jp5ou0uc7v64f2/1407700800000/13129578833489239856/*/0B4UPrML8Nk9lSk5aai1MQ1VVTmc?h=16653014193614665626&e=download
[15:52:11] <jepler> pcw_home: there's only one ground on the odroid's headers
[15:52:54] <pcw_home> if you have cables, the odroid side cable should be as short as possible
[15:56:47] <jepler> going back to te scope, there's easily noise seen on the 1.8V side's CS line that exceeds 750mv
[15:58:30] <pcw_home> well, thats not good...
[15:59:21] <pcw_home> scope ground on odroid ground pin?
[15:59:36] <jepler> no, which I was just about to fess up to
[16:05:37] <CaptHindsight> from the schematic it's just the 4 SPI pins on the 4 pin header
[16:05:55] <jepler> CaptHindsight: yes, so the nearest ground I can take is on the next header, an inch or two away
[16:09:19] <jepler> measuring at the end of the 6" wires, there's still noise >700mV
[16:09:52] <jepler> I guess 1.8V logic is not intended to run very far in unshielded wire
[16:11:39] <jepler> OK, spi from this board goes on the back burner now
[16:11:51] <jepler> I'll actually make some heady working on an assembler preprocessor.
[16:13:22] <CaptHindsight> yeah, don't worry about it. I'll take a look at SPI again here as soon as I get a chance
[16:15:12] <jepler> there are too many untested parts in my SPI setup. odroid, level translator breakout, and spi on 7i43 are all potential sources of egregious brokenness
[16:22:25] <jepler> https://github.com/rumpkernel/wiki/wiki
[16:27:16] <CaptHindsight> memleak has the cubie2 running again
[16:27:43] <CaptHindsight> and all the tools are here
[16:41:50] <CaptHindsight> preempt_rt on new AMD APU's with the hardware accell driver jumps to 240uS under abuse, so we are stuck until AMD fixes the driver
[17:31:42] <Tom_itx> jepler i've had good luck with NXP level translators
[17:32:01] <Tom_itx> work down to 1v
[17:32:13] <Tom_itx> no direction pin necessary
[17:33:47] <Tom_itx> GTL2003PW is an 8bit wide ver, they vary from 2 bit to many
[17:37:28] <Tom_itx> i could show a layout for it if you're interested
[18:03:06] <CaptHindsight> SPI kernel driver Master Mode Only for the A20
https://github.com/linux-sunxi/linux-sunxi/blob/sunxi-3.4/drivers/spi/spi_sunxi.c
