#linuxcnc-devel Logs

Dec 12 2017

04:59 AM jthornton: cradek: I still get this error even with that url
05:00 AM jthornton: git clone ssh://git@github.com:LinuxCNC/linuxcnc.git emc3
05:00 AM jthornton: Cloning into 'emc3'...
05:00 AM jthornton: Permission denied (publickey).
05:00 AM jthornton: fatal: Could not read from remote repository.
05:00 AM jthornton: Please make sure you have the correct access rights
05:00 AM jthornton: and the repository exists.
05:19 AM rene-dev: jthornton if you dont have a ssh key set up, clone via http
05:23 AM jthornton: rene-dev: I've had my ssh key set up since May 2009
05:23 AM jthornton: I've not pushed since the change to github tho
05:24 AM jthornton: I have a github account with a few things in it
05:25 AM rene-dev: can you push using that key to your own repo?
05:26 AM jthornton: been a year since I pushed to my account
05:26 AM rene-dev: try now
05:28 AM jthornton: no I can't even clone my stuff with git clone
05:38 AM jthornton: added my ssh pub key to my repo and now I can clone it
05:42 AM rene-dev: check your account settings
05:43 AM rene-dev: https://help.github.com/articles/error-permission-denied-publickey/
05:44 AM jthornton: thanks
05:50 AM jthornton: working now :O)
12:31 PM andypugh: pcw_home: How hard would it be to make a super-sserial firmware with wider data? (224 bits / 7 registers for example). I can see that in the Regmap you would run into the UART.
12:33 PM pcw_mesa: I would just make an alternate version at another address >0x8000
12:34 PM pcw_mesa: (so no EPP but thats OK)
12:35 PM pcw_mesa: I already have a new module > 0x8000 (inmux)
12:38 PM pcw_mesa: you may not always want the bigger version because or resource constraints
12:39 PM andypugh: I would guess that the driver would choose to only use as many as are needed by the attached remotes.
12:40 PM rene-dev: yes, but they still take up space in the fpga
12:41 PM rene-dev: andy just thought about using num_registers to tell the driver how many registers there are
12:41 PM rene-dev: pcw_home how hard would it be to make the number of user registers configurable in the firmware?
12:42 PM andypugh: Though mesaflash reports that sserial has 6 registers.
12:42 PM andypugh: OK, that might be nearly true.
12:43 PM andypugh: There are 6 different types of register.
12:44 PM rene-dev: there are 6, 3 user and command, data and cs
12:44 PM pcw_mesa: It should not be too hard but the way the code currently works, it depends on the UARTs having big enough FIFOs to hold the complete RX/TX messages
12:46 PM pcw_mesa: On spartan6 and > it should be trivial and resource friendly to change the UART FIFOs to 32 deep since SP6 and > support SRL32s
12:48 PM andypugh: If the firmware had more “width” then I guess that would show up in num_registers in the MD?
12:49 PM pcw_mesa: Yes (and probably a constant readable via the command/data interface)
12:54 PM rene-dev: hmm, you are probably not keen on changing the firmware? :D
12:56 PM pcw_mesa: Its not a lot of fun (the hardware parts are OK, the "stiffware" not so much )
12:57 PM rene-dev: the driver? andy will probably do the driver :D
12:58 PM pcw_mesa: There are other things we have been looking at doing (adding a baud rate search so 2.5, 5, 10, 20m, 115200)
12:59 PM rene-dev: ah, yes. higher would be better. but really no need, with only 1khz update rate.
12:59 PM pcw_mesa: our PIC stuff wont do it but FPGA remotes will run at 20 MB
12:59 PM rene-dev: but maybe then it would be possible to have the sserial reply in the same thread
01:00 PM rene-dev: the stm32 does 5 easily
01:00 PM pcw_mesa: Yes that the other addition we were contemplating (separating the RX from TX)
01:02 PM pcw_mesa: the PICs will do 10 MB but you have to throw out the digital filter on the RX which makes them more susceptible to impulse noise
01:04 PM pcw_mesa: retain the normal doit (RX+TX) but add a RX and TX only doit
01:04 PM pcw_mesa: remotes need the added 2 RPCs
01:06 PM rene-dev: yes
01:06 PM rene-dev: that would be easy to do
01:06 PM rene-dev: (from the device side)
01:07 PM pcw_mesa: yeah that not a very big change even on the SSLBP side, just more code