Awesome, thanks that gets one issue of me trying to figure out what's going on out of the way lol.
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? 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. 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. 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? I also assume all GPIO has pullups enabled on the FPGA, so they need to sink to change state? 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.
