[Machinekit] Re: DE10 Nano suggested development environment?
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, mib.ho...@gmail.com 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 > NumRegistersStrides MultiRegs > you can see 2 encoder instances are specified: > (QcountTag, x"02", ClockLowTag,x"02", QcounterAddr, > 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=100 > addf hm2_5i25.0.read test-thread > addf hm2_5i25.0.writetest-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, mib.ho...@gmail.com 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
Re: [Machinekit] Re: DE10 Nano suggested development environment?
On 5/2/2019 10:29 PM, justin White wrote: > 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? 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. It sounds like Michael is helping you with an appropriate FPGA configuration. -- Charles Steinkuehler char...@steinkuehler.net -- 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 machinekit+unsubscr...@googlegroups.com. Visit this group at https://groups.google.com/group/machinekit. For more options, visit https://groups.google.com/d/optout.
[Machinekit] Re: DE10 Nano suggested development environment?
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 NumRegistersStrides MultiRegs you can see 2 encoder instances are specified: (QcountTag, x"02", ClockLowTag,x"02", QcounterAddr, 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=100 addf hm2_5i25.0.read test-thread addf hm2_5i25.0.writetest-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, mib.ho...@gmail.com 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, mib.ho...@gmail.com 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
