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. On Friday, 3 May 2019 13:16:43 UTC+2, [email protected] wrote: > > > > On Friday, 3 May 2019 05:29:27 UTC+2, justin White wrote: >> >> Awesome, thanks that gets one issue of me trying to figure out what's >> going on out of the way lol. >> >> > Your welcome > > >> That's a good starting point because all I really need is one instance of >> each pin/interface type for now. I'm slightly confused about the .vhd file >> yet though. I get that it's the pin descriptor file, but when I go to >> layout the GPIO differently, is all that is required is for me to assign >> the pins in the new .vhd file. I'm not quite sure what to do with the vhd >> file either at the moment, does it got loaded from the hal file. Also any >> idea why halshow fails to load from the Axis GUI? >> >> I attatched the .vhl fil just because I had'nt pushed my commit to github > at that time. (It is used for compiling the .rbf bitfile only) > > Rightnow that file is pushed to this folder here: > > https://github.com/the-snowwhite/mksocfpga/tree/encoder_work/HW/hm2/config/DE10_Nano_FB_Cramps > > If you look in the section beginning with: > constant ModuleID : ModuleIDType :=( > -- GTag Version Clock NumInst BaseAddr > NumRegisters Strides MultiRegs > you can see 2 encoder instances are specified: > (QcountTag, x"02", ClockLowTag, x"02", QcounterAddr&PadT, > QCounterNumRegs, x"00", QCounterMPBitMask), > > If you look in the section beginning with: > > constant PinDesc : PinDescType :=( > you can see the pins for the 2 encoders: > IOPortTag & x"00" & QCountTag & QCountIdxPin, -- I/O 41 > GPIO_1 06 06 Encoder Z > IOPortTag & x"00" & QCountTag & QCountQBPin, -- I/O 42 > GPIO_1 07 07 Encoder B > IOPortTag & x"00" & QCountTag & QCountQAPin, -- I/O 43 > GPIO_1 08 08 Encoder A > IOPortTag & x"01" & QCountTag & QCountIdxPin, -- I/O 44 > GPIO_1 09 09 Encoder Z > IOPortTag & x"01" & QCountTag & QCountQBPin, -- I/O 45 > GPIO_1 10 10 Encoder B > IOPortTag & x"01" & QCountTag & QCountQAPin, -- I/O 46 > GPIO_1 11 13 Encoder A > > > >> Also, I'm not 100% sure how the hm2 card bitfiles are configured for the >> encoder interface but I assumed the FPGA actually used 3 I/O pins for the >> encoder. >> > > Yes > > >> On the Mesa cards you swap jumpers to change from differential to single >> ended type encoder. In that case I figured they used a differential >> receiver chip to for differential encoders and bypassed it with the jumpers >> when using a single ended encoder. >> > > The encoder core uses single ended inputs, differential encoder inputs I > belive may be a built in HW feature on the Mesa boards. > > >> I see that this .vhd file uses 2 I/O pins per channel for the encoder so >> I assume it is configured to accept the differential encoder directly. In >> the case of using a single ended encoder is it just a matter of using a >> single input per channel or would it need to be reconfigured? >> > > No reconfiguration is needed as you have 2 x 3 single ended encoder inputs > in that .rbf file > > I also assume all GPIO has pullups enabled on the FPGA, so they need to >> sink to change state? >> >> > There is maybe some provision that works for enabling pull ups on > individual fpga pins, let me follow up on that later.(right now no pullups > active) > Currently I have found out that using 220 ohm pullups to 3.3V works just > fine. > > >>> Also any idea why halshow fails to load from the Axis GUI? > > It may be easier to test the encoder function without a GUI, try running > these commands from a linux console (copy paste): > > halrun > loadrt hostmot2 > newinst hm2_soc_ol hm2-socfpga0 already_programmed=1 -- > config="num_pwmgens=1 num_stepgens=4 num_encoders=1 enable_adc=1" debug=1 > loadrt threads name1=test-thread period1=1000000 > addf hm2_5i25.0.read test-thread > addf hm2_5i25.0.write test-thread > > start > > Then open a different console and paste this: > > halcmd show pin hm2_5i25.0.encoder.00 > > turn your connected encoder (with manual pullups) > > and repeat the "reading" > halcmd show pin hm2_5i25.0.encoder.00 > > > >> On Thursday, May 2, 2019 at 9:00:39 PM UTC-4, [email protected] wrote: >>> >>> Ups a little bit hasty there: >>> not the fdtfile variable but: >>> >>> place the attached *.rbf file in: /lib/firmware/socfpga and (you can >>> also alter u-boot variables from a linux console) >>> sudo fw_setenv bitimage >>> '/lib/firmware/socfpga/DE10_Nano_FB_Cramps.3x24_cap_enc.rbf' >>> >>> then reboot >>> >>> >>> On Friday, 3 May 2019 02:42:44 UTC+2, [email protected] wrote: >>>> >>>> >> Were you planning on using the HAL encoder component? >>>> >>>> Nope :-) >>>> >>>> I have just completed adding the missing parts in the DExx.._Cramps >>>> Quartus projects and added a new encoder config. >>>> >>>> Right now im running a Docker build before getting ready to commit my >>>> changes.... Since It is late late night here (I'm gointg to bed now): >>>> I attach the *.rbf file and the Pin fil in which you can see which pins >>>> are used on the 2 GPIO ports. >>>> the encoder inputs are on the second port (gpio_1). >>>> >>>> change the fdtfile name to: DE10_Nano_FB_Cramps.3x24_cap_enc.rbf >>>> in uboot and >>>> >>>> Happy testing: >>>> >>>> Best wishes Michael B. >>>> >>>> >>>> >>>> On Friday, 3 May 2019 01:32:18 UTC+2, justin White wrote: >>>>> >>>>> Thanks for the response, I was beginning to think I wasn't going to >>>>> get any help on this one. >>>>> >>>>> That's a coincidence, I use the same 1000PPR Omron differential >>>>> encoder on both my project machine and my mill. Those are both x86 >>>>> Linuxcnc/Mesa machines though the project machine is the candidate for >>>>> MK. >>>>> Actually I hadn't realized that the MK socfpga component did not >>>>> implement >>>>> the mesa encoder interface, I didn't plan on running the software hal >>>>> encoder component. Do you know if anyone is working on porting the HM2 >>>>> encoder interface to socfpga? Were you planning on using the HAL encoder >>>>> component? >>>>> >>>>> On Thursday, May 2, 2019 at 11:02:42 AM UTC-4, [email protected] >>>>> wrote: >>>>>> >>>>>> Hi Justin >>>>>> >>>>>> The DE10_Nano_FB_Cramps.3x24_cap.rbf bitfile is as the name implies >>>>>> designed to interface with a Cramps board and provide a framebuffer >>>>>> onthe >>>>>> hdmi pins of the DE10 Nano. >>>>>> I have created an Interface board for interfacing the DExx Nano (soc) >>>>>> boards to the Cramps and >>>>>> the design files are here: >>>>>> >>>>>> >>>>>> https://github.com/the-snowwhite/socfpga-kicad/tree/master/Cramps2nano-soc >>>>>> >>>>>> https://github.com/the-snowwhite/socfpga-kicad/blob/master/Cramps2nano-soc/Cramps2Nano.pdf >>>>>> >>>>>> This shows the pins of the DExx Gpio pins and can be easiely bread >>>>>> boarded. >>>>>> >>>>>> The cap sensor is not part of Cramps functionality so these pins are >>>>>> not on that schematic... >>>>>> >>>>>> -- >>>>>> About the "SOC-no-fw-load" config method: >>>>>> >>>>>> This makes Machinekit not reprogram the fpga when MACHINEKIT >>>>>> starts... correct >>>>>> >>>>>> The "fpgaload_on_boot 1" in u-boot makes u-boot program the fpga >>>>>> BEFORE linux starts up so that the Framebuffer then can be picked up, >>>>>> >>>>>> Ensure that the right devicetree (the one with framebuffer enabled) >>>>>> is loaded by u-boot. >>>>>> >>>>>> Really I'm just looking to breadboard an encoder interface and level >>>>>>> shifting circuits and get some feedback from MK as to how the GPIO is >>>>>>> responding at this point >>>>>>> >>>>>> >>>>>> Coincendentially I have just purchased an encoder: >>>>>> E6B2-CWZ6C >>>>>> >>>>>> And will be doing the same exercise currently it seems... :-) >>>>>> >>>>>> While it may be possible to hook up this encoder to some gpio pins >>>>>> and then run a "soft" encoder in the hal, >>>>>> the Mesa Hostmot2 cores do provide Encoder cores that can be run in >>>>>> the fpga HW fabric, this meens a new config has to be added to the >>>>>> DE10_Nanoxxx_FBxxxx Quartus project in the Mksocfpga repo >>>>>> >>>>>> http://www.machinekit.io/docs/drivers/hostmot2/#encoder >>>>>> >>>>>> >>>>>> On Wednesday, 1 May 2019 04:33:52 UTC+2, justin White wrote: >>>>>>> >>>>>>> So I picked up a DE10 Nano to do some testing on. As I explained in >>>>>>> a previous thread, a remote GUI running on a different CPU is the >>>>>>> intended >>>>>>> goal with the DE10-Nano handling MK and the hardware headless as I'm >>>>>>> sure >>>>>>> most would intend it's use. I'm having all sorts of issues with just >>>>>>> about >>>>>>> everything MachineKit but this I got somewhere with. >>>>>>> >>>>>>> I need to work on making an interface board to get useable I/O out >>>>>>> of this thing for my intended purpose. I found the >>>>>>> "DE10-Nano/mksocfpga_stretch_machinekit_4.9.76-2018-05-26-de10_nano_desktop_sd.img" >>>>>>> >>>>>>> and got that setup with HDMI support and LXqt. The thought is that If I >>>>>>> can >>>>>>> get a working GUI setup going with a more or less generic bitfile I can >>>>>>> basically breadboard the DE10-Nano and use HalShow and a few other >>>>>>> LinuxCNC >>>>>>> tools to verify the circuits. I ran into a couple of issues and there's >>>>>>> some things I'm unsure of.... >>>>>>> >>>>>>> I tried what sounded like a more ideal bitimage but the HDMI output >>>>>>> was no good unless I used >>>>>>> the /lib/firmware/socfpga/DE10_Nano_FB_Cramps.3x24_cap.rbf bitimage. I >>>>>>> couldn't find info on what the pin designations for this image are, I'm >>>>>>> not >>>>>>> really up to snuff on the 3D-printer/CRAMPS thing. I'm not really sure >>>>>>> of >>>>>>> how to create my own bitfile either especially if it's tied to the HDMI >>>>>>> out. >>>>>>> >>>>>>> I did load MK and the only stock config I could get to load was the >>>>>>> something "SOC-no-fw-load" config. I assume this does not reprogram >>>>>>> the >>>>>>> FPGA on start since the "fpgaload_on_boot 1" variable is set to program >>>>>>> the >>>>>>> FPGA on boot? Since I have no hardware to attach I can't really say >>>>>>> whether >>>>>>> the I/O was actually doing anything although I guess I would expect >>>>>>> following errors or something if it wasn't while I was jogging around. >>>>>>> I >>>>>>> also couldn't start Halshow from the Axis GUI, just didn't open. It'd >>>>>>> be >>>>>>> great if somebody could point me in the right direction as to how I can >>>>>>> either setup my own hardware bitfile or use a rather generic one that I >>>>>>> can >>>>>>> reference pin designations too. Really I'm just looking to breadboard >>>>>>> an >>>>>>> encoder interface and level shifting circuits and get some feedback >>>>>>> from MK >>>>>>> as to how the GPIO is responding at this point. >>>>>>> >>>>>> -- 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.
