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.
