#linuxcnc-devel Logs
May 15 2020
#linuxcnc-devel Calendar
12:57 AM rmu|w: Tom_L: mesaflash --spi --device 7i90 --addr /dev/spidev0.0 --readhmid
01:01 AM rmu|w: Tom_L: mesaflash --spi --device 7i90 --addr /dev/spidev0.0 --write 7i90_spi_svss6_8.bit
01:01 AM rmu|w: SPI driver needs to be enabled
06:24 AM Tom_L: thanks i'll try that after bit
10:55 AM Tom_L: yay! spi is working. thanks all
10:58 AM Tom_L: so the merged version of mesaflash works on spi, epp and yet to test eth
11:01 AM Tom_L: skunkworks, how did you configure yours for ethernet? i tried a couple things and it doesn't wanna cooperate
11:12 AM jepler: I assume you configure wifi for internet and ethernet for the mesa. the interface is called eth0, and the lines for /etc/network/interfaces in `man hm2_eth` should work after adaptation.
11:12 AM jepler: not sure about whether hardware-irq-coalesce-rx-usecs applies to pi
11:14 AM Tom_L: yes wifi interweb, eth0 static at 10.10.10.1
11:15 AM Tom_L: it works fine on a pc
11:15 AM Tom_L: just getting used to the pi
11:17 AM Tom_L: i've always just entered the ip and subnet mask
11:18 AM Tom_L: i looked at interfaces as well as dhcpcd.conf
11:19 AM pcw_home: what does "ip a" report?
11:20 AM jepler: (reboot after /etc/network/interfaces changes, too)
11:20 AM Tom_L: i got it
11:21 AM Tom_L: i had to add the static routers=10.10.10.10
11:21 AM Tom_L: to the dhcpd.conf file
11:22 AM jepler: honestly I'm not sure why dhcp is in play here
11:22 AM Tom_L: so you need the static ip as well as the routers
11:22 AM Tom_L: me either
11:22 AM jepler: If you followed the suggestion to "eth0 static ..." it should not be using dhcp to configure eth0 at all
11:22 AM Tom_L: so merged mesaflash works on spi, epp and eth
11:23 AM Tom_L: jepler, i tried that first
11:23 AM Tom_L: it was also 1am so i may have missed something
01:46 PM skunkworks: Tom_L: jt's site shows what to put in the dhcpd.cnf
01:46 PM skunkworks: conf
02:08 PM jepler: > interface eth0
02:08 PM jepler: > static ip_address=10.10.10.11/24
02:08 PM jepler: oh that is not what I would have done. but, if it works?
02:56 PM Tom_L: yes
02:57 PM Tom_L: what is the /24 on the end for?
02:59 PM struf: 24 is mask of the network, equals to 255.255.255.0
02:59 PM Tom_L: oh well that's good to know
03:00 PM jepler: which means the computer should use that network interface for addresses within 10.10.10.x.
03:01 PM Tom_L: explains why they didn't have an input for subnet mask
03:55 PM seb_kuzminsky: jepler: will you give me a brief education about this PR? https://github.com/LinuxCNC/mesaflash/pull/36
03:56 PM jepler: Sure, I'll try
03:56 PM seb_kuzminsky: JT-Shop added travis builds in his repo and i brought it forward to the consolidated repo in the LinuxCNC org
03:56 PM seb_kuzminsky: i've used travis a bunch, and github actions not at all
03:57 PM jepler: I wrote that PR not realizing there was Travis support
03:57 PM seb_kuzminsky: i read about it a bit just now but i don't feel like i know why i'd choose one over the other
03:57 PM jepler: so it may just not be ncessary
03:57 PM Tom_L: seb_kuzminsky, the mesaflash merges seem good
03:57 PM seb_kuzminsky: i like the github actions are well integrated into the rest of the github world
03:57 PM seb_kuzminsky: Tom_L: thanks for letting me know! i've gotten a couple of positive reports like that
03:58 PM jepler: the main thing that I like about github actions is, it's enabled everywhere for all users, so anyone who forks mesaflash gets the builds automatically. with travis, you have to go through steps to enable it
03:58 PM Tom_L: i tested spi, epp and eth over last couple days
03:58 PM seb_kuzminsky: i think i'll make one more mesaflash 3.4 prerelease and put it up on wlo for wider testing, then we'll go to 3.4.0
03:58 PM seb_kuzminsky: jepler: is that true? isn't it enough to fork a repo with a .travis file in it?
03:58 PM jepler: github actions is a bit newer so on the one hand it's bug-ridden but on the other hand it seems to do more docker/container stuff which could be good for transitioning more or even all builds to the system
03:59 PM jepler: yeah you have to allow travis on your repository, it's not enabled by default; and if it's your first travis, you have to sign up
03:59 PM seb_kuzminsky: i saw GHA supports running builds on your own VMs at home, not just their VMs/containers in their cloud
03:59 PM jepler: (but either way, it gets run when some PRs to our fork so it's not like it doesn't get tested by CI)
03:59 PM jepler: yes I know that is there but I don't know how it works
04:00 PM seb_kuzminsky: i like the tighter integration
04:00 PM * seb_kuzminsky clicks merge
04:00 PM seb_kuzminsky: thanks jeff
04:01 PM jepler: circuitpython is on github actions, and it's a mixed blessing. On the one hand, we have about 130(?) independent builds so we like the greater parallelism of GHA over Travis... but we do encounter bugs, and our CI builds are still up to an hour again
04:08 PM jepler: also they have a bug where their internal API paginates the builds and their user-facing pages don't bother going through the pagination, so it doesn't show accurate results if you have >100 builds in your matrix :(
04:08 PM jepler: seb_kuzminsky: should I roll a PR to remove the Travis CI, or do you want to keep both? I think they're different versions of ubuntu, for whatever that's worth