On Saturday, 4 May 2019 18:03:51 UTC+2, justin White wrote: > > OK, now I'm getting somewhere > >> The encoder core uses single ended inputs, differential encoder inputs I >> belive may be a built in HW feature on the Mesa boards. >> >> It is, I just wasn't sure how it was setup in the bitfile. I looked at a > bitfile from mesa with 1x3 encoder inputs, so yeah, nothing changes there. > I have a DIP package differential line receiver that I breadboarded up > with the nano and the differential encoder and I'm able to get the encoder > counting on the nano. I can't find my single ended cheapo encoder at the > moment but that should be more straight forward anyway. I just realized the > encoder you mentioned you ordered was the single ended version. >
Wonder which human readable file you are refering to as the bitfiles are the binaries (*.rbf) generated by quartus from the *.vhd and *.sv, *.v source files... > >> Currently I have found out that using 220 ohm pullups to 3.3V works just >> fine. > > That seems like a rather strong pullup. I've been testing 4.7k > pullups/pulldowns since it's a pretty typical value for microcontrollers > and they seem to work fine. It's possible that 4.7k might be a bit sluggish > but I won't know til later. I'm seeing that the HM2 GPIO pins go true when > pulled up and false when pulled down. The "not" pins are obviously there > but it now seems a bit more intuitive to actually pull them down and use > high logic to activate the inputs. I'm sure it's just the way hm2 is > configured. Thoughts on that? > I'm no electronics expert... The datasheet for my single ended encoder says max 30 mA, so I figured 220 ohm at 3.3volts gives max 15mA or so... > > It may be easier to test the encoder function without a GUI, try running >> these commands from a linux console (copy paste): >> >> Halrun/halcmd works but I find Halshow to be a bit more intuitive since > it's graphical and I can just load up a watchlist. I tried loading halshow > in basically the same way you mentioned with the separate terminal instance > after loading the RT components and threads and I get a segfault. My > programmer buddy might be able to look into that but halcmd will work for > now. > If your FULL error message is: halshow > halsh: FATAL - 'MACHINEKIT_INI' missing in environment > Segmentation fault > > then try doing: export MACHINEKIT_INI=/etc/linuxcnc/machinekit.ini I had to do some more to get it to run via a ssh -XY .... console, however I'm also running the newer machinekit-hal-rt-preempt machinekit-cnc-rt-preempt packages > About using internal pull-ups in the fpga: >> >> >> https://electronics.stackexchange.com/questions/248248/altera-fpga-i-o-weak-pull-ups >> >> The Cyclone V family only has a 25Kohm (weak) internal pull-up resistor >> that can be enabled: >> >> https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/hb/cyclone-v/cv_51002.pdf >> >> Not usable for this purpose I think. >> > Yeah, being that weak they would be pretty sluggish I would think. They > are likely just onboard to keep unused pins from floating. I would think in > the case of something like this it's probably best they are left off since > hm2 is reconfigurable. It is good to know the state though since they can > cause issues with voltage dividers and such if not accounted for. > > >> The VHD files are VHDL code describing the logic inside the FPGA. >> This code gets compiled by the vendor tool-chain and turned into a >> configuration file used to program the FPGA. >> >> You asked earlier about HM2 to support encoder interfaces. The HM2 >> driver already supports all the different types of logic currently >> implemented in the FPGA, including encoder, stepgen, pwm, smart >> serial, etc. To get an encoder to show up, just program the FPGA with >> an appropriate configuration file and the HM2 driver will detect the >> encoder instances. >> > > Charles, > I haven't really done anything with Quartus yet so bear with me. Searching > for this specific answer I haven't really found anything. > > The hm2 .vhd file (and presumeably other .vhd files) are part of building > the .rbf file in Quartus correct? So if I wanted to apply a different pin > configuration I would re-write this .vhd file and apply it in Quartus to > build the new .rbf, is that correct? > > I'll look into the specifics of doing it when the time comes, I'm just > trying to get the gyst of how that works. > > -- website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit --- You received this message because you are subscribed to the Google Groups "Machinekit" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. Visit this group at https://groups.google.com/group/machinekit. For more options, visit https://groups.google.com/d/optout.
