Back
[08:57:06] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15nicokid commented on issue #161: Fixed the mistake when saving as string the axis values for test. (Sorry). 02
https://github.com/LinuxCNC/linuxcnc/pull/161#issuecomment-246180359
[09:15:56] <skunkworks> zlog,
[12:46:48] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15jepler commented on issue #161: Hello @nicokid and thanks for working on these stepconf issues. Issue #57 does seem to be fixed, :+1:... 02
https://github.com/LinuxCNC/linuxcnc/pull/161#issuecomment-246191828
[12:55:51] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15jepler commented on issue #57: Hm.... 02
https://github.com/LinuxCNC/linuxcnc/issues/57#issuecomment-246192317
[13:45:10] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15SebKuzminsky commented on issue #57: I think @jepler is right: Cancel should discard any changes made, and Ok should preserve them by copying them from the "X Axis Test" popup back to the "Axis X" page of the Stepconf main window. My bug report was in error for claiming Cancel should preserve them.... 02
https://github.com/LinuxCNC/linuxcnc/issues/57#issuecomment-246195024
[13:48:00] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15SebKuzminsky commented on issue #57: @nicokid I verified that this affects X, Y, and Z axes (in 2.7.7). 02
https://github.com/LinuxCNC/linuxcnc/issues/57#issuecomment-246195171
[14:30:47] <jepler> hmph, still haven't gained a clue why SPI isn't working on the xu3. Same behavior with the little boards I ordered or point-to-point jumpers: all zeros are read back, rather than the hostmot2 cookie
[14:31:36] <jepler> best hypothesis seems to be that the 7i90 isn't getting the SPI data in (MOSI), since the actual SPI data read by the XU4 is aaaaaaaa 00000000 00000000 00000000
[14:32:17] <jepler> hooked the old u3 back up and verified that it still works properly, so it's got to be the new xu4 or the wiring
[14:41:33] <seb_kuzminsky> can you scope the pins?
[14:43:03] <jepler> yeah two at a time
[14:43:45] <pcw_home> ~3V swing on data MOSI?
[14:45:48] <jepler> yeah 0V - 3.5V swing
[14:46:38] <jepler> the level translator board is hardkernel / odroid's design with TSX0108E
[14:47:08] <jepler> switching the VCCB standard from 3.3 to 5 changes the measured output swing
[14:48:12] <pcw_home> clock/data polarity right?
[14:48:20] <pcw_home> (SPI mode)
[14:48:50] <jepler> dunno, the code is the same (spidev ioctl API) and it has the API calls to set the polarities so I'm going to guess "yes"
[14:50:40] <jepler> what is the bit order supposed to be? 0100a840 is the command it's sending according to the debugging schmutz I added to mesaflash, 01000000 10101... seems to be the first thing transmitted by reading the scope trace manually
[14:51:02] <pcw_home> MOSI data must be valid on the rising edge of the clock
[14:51:22] <pcw_home> (with adequate setup and hold times)
[14:52:20] <pcw_home> (and MSb first)
[14:54:38] <jepler> so if the first word really starts 0100 0000 0101... binary then it's hex 405.. and not 010...
[14:54:52] <jepler> I can't see hex 405 anywher in 0100a840
[14:55:29] <jepler> but yes, clock starts low and MOSI is stable when clock rises
[14:56:36] <cradek> I can't make that bit pattern make any sense either
[15:01:43] <pcw_home> 0x0100A840 means read 4 doublewords starting at 0x100 (cookie loc) which sounds right as a starting point
[15:01:55] <jepler> https://goo.gl/photos/E6bVh6GDFtv3Vjfm8
[15:03:15] <jepler> wait, is it starting 40 a8 and my bytes are backwards?
[15:03:50] <pcw_home> yeah could be
[15:06:58] <jepler> spidev_set_lsb_first(sd, false);
[15:08:11] <jepler> yeah it's bit order
[15:08:19] <cradek> I also read 40a8 in the photo, when you got 405... you were off a bit
[15:08:35] <jepler> I'm a bit off.
[15:08:38] <jepler> .. it's settled
[15:08:43] <cradek> plus two more zero bits after that
[15:18:34] <jepler> yup the bytes are backwards
[15:18:41] <jepler> now with byte swapping it can read the hmid
[15:18:46] * jepler declares success for the day
[15:19:04] <cradek> yay!
[15:25:41] <jepler> 448817b Samsung sources drop
[15:25:48] <jepler> commit messages like this are not helpful
[15:26:01] <jepler> .. when your task is: check when they screwed up the handling of byte order
[15:29:39] <jepler> spi_1: spi@12d30000 {
[15:29:40] <jepler> ..
[15:29:45] <jepler> swap-mode;
[15:31:20] <cradek> at least it's software...
[20:19:40] <jepler> yup
[20:20:21] <jepler> seems like I should try just removing swap-mode and rebuilding the devicetree
[20:22:01] <jepler> or actually test the flag SPI_LSB_FIRST instead of the hard-coded swap-mode, which ends up at sci->swap_mode == SWAP_MODE
[21:07:04] <jepler> yay that works
[21:09:13] <jepler> Loaded HAL Components:
[21:09:13] <jepler> ID Type Name PID State
[21:09:16] <jepler> 11 RT hm2_spi ready
[21:09:22] <cradek> ooh
[21:09:35] <jepler> hm but
[21:09:35] <jepler> hm2/hm2_7i90.0: error finishing write! iter=2)
[21:22:40] <jepler> must be a bug introduced somewhere along the way, somehow we reach hm2_finish_write with no bytes queued for the card
[21:22:43] <jepler> a bit surprising
[21:25:10] <jepler> so it looks like it's possibly working, but max-time is >500uS just for spi read and write, so you won't get to 1kHz (it readily gets realtime errors if you compile while realtime is running)
[21:35:38] <jepler> I think it's using DMA mode for all transfers; in my tests back on U3, this was bad for performance with linuxcnc realtime (small transfers suffered)
[21:44:36] <jepler> hm, disabling dma mode makes things worse
[21:44:46] <jepler> max-time from ~600us to ~1300us
[21:44:48] <jepler> let's not do that