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.
> > 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? 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. 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.
