No changing numinst should work just fine On Monday, 19 August 2019 18:05:28 UTC+2, justin White wrote: > > One thing I noticed, I recall seeing this the first time I started messing > with the .vhd's. All of the pinfiles in the DExx_Nano_xxx_Cramps config use > this line for stepgens > > (StepGenTag, x"02", ClockLowTag, x"0A", StepGenRateAddr& > PadT, StepGenNumRegs, x"00", StepGenMPBitMask), > > The NumInst being "0A" looked a little strange to me so I changed it to > the actual number (06) for every pinfile I've been working with. Could that > be causing an issue? > > On Monday, August 19, 2019 at 11:33:29 AM UTC-4, justin White wrote: >> >> On Monday, 19 August 2019 13:24:22 UTC+2, Michael Brown wrote: >>>> >>>> I have an older config that has worked with 8 stepgens: >>>> hm2_soc_ol config line here: >>>> <https://github.com/the-snowwhite/Hm2-soc_FDM/blob/master/Cramps/PY/Mibrap-X_hm3_fdm-soc/fdm/config/motion.py#L15> >>>> Have you tried with: >>>> num_stepgens=6 in the hm2_soc_ol config line ? >>>> >>> >> Yes, my config line is: >> [HOSTMOT2] >> DRIVER=hm2_soc_ol >> BOARD=5i25 >> CONFIG="num_encoders=6 num_stepgens=6" "enable_adc=1" >> DEVNAME=hm2-socfpga0 already_programmed=1 >> >> If the stepgens=6 wasn't there hm2 wouldn't instantiate them in HAL. They >> are actually completely visible and HAL seems to think they're working. I >> dug up one of my first test hal files and #4 did in fact work with that but >> I had much less else going on. >> >> I'm not terribly familiar with Quartus. I usually just do as in the >> readme https://github.com/the-snowwhite/mksocfpga to build the firmware. >> I did have an issue before where it was building firmware that wouldn't >> boot, deleting mksocfpga and pulling it again fixed that. That may even >> have had something to do with trying to open the project previously. Ill >> try re-pulling it and see what happens. >> >> I ran the analysis in in QP and this is what I'm seeing with the >> stepgens: >> >> [image: QP.png] >> >> >> >> >> >> >> On Monday, August 19, 2019 at 7:46:58 AM UTC-4, Michael Brown wrote: >>> >>> Quartus Update: >>> After compiling (the default DE10_Nano_FB_Cramps project) Notice that >>> all 9 (0-8) stepgens instansiated in the pin file have a (not null) sized >>> SRL16E:\steptable:0:asr16e instance: >>> >>> [image: Quartus_DE10_Nano_FB_Default_Num-Stepgens_Compiled.png] >>> >>> >>> >>> On Monday, 19 August 2019 13:24:22 UTC+2, Michael Brown wrote: >>>> >>>> I have an older config that has worked with 8 stepgens: >>>> hm2_soc_ol config line here: >>>> <https://github.com/the-snowwhite/Hm2-soc_FDM/blob/master/Cramps/PY/Mibrap-X_hm3_fdm-soc/fdm/config/motion.py#L15> >>>> Have you tried with: >>>> num_stepgens=6 in the hm2_soc_ol config line ? >>>> >>>> Also You can look in the Compiled (Or after analysis & elaboration) >>>> Quartus project and see how many stepgens are elaborated like in below pic: >>>> >>>> [image: Quartus_Num_Stepgens.png] >>>> >>>> >>>> On Monday, 19 August 2019 00:31:53 UTC+2, justin White wrote: >>>>> >>>>> The hal component did work fine then my friend "cleaned it up" and it >>>>> acts weird when you enable the filter. Could just remove the filter pin >>>>> and >>>>> post it but it is rather handy. >>>>> >>>>> I've been tracking down an issue with the stepgens and depending on >>>>> what the issue is it may be part of the smart serial issue. I have 4 out >>>>> of >>>>> 6 stepgens that work, on my 5th stepgen only the direction pin works, not >>>>> the step pin. Neither work on the 6th stepgen. I disabled SS for the >>>>> time >>>>> being but it was using consecutive pins with the 5th and 6th stepgens. It >>>>> was difficult to see what was going on until I got my GUI setup. Now I >>>>> can >>>>> see that in hal it is actually working and I'm getting feedback to the >>>>> PID >>>>> loop but the pins of the Nano itself do not electrically do anything, I >>>>> can >>>>> verify that with my scope. Thinking maybe I damaged the GPIO pins from >>>>> all >>>>> the hardware swapping I've been doing, I picked up another DE10 Nano and >>>>> the same thing happens. I tried swapping stepgen instance 0,1 for 4,5 in >>>>> the .vhd and rebuilt the firmware without changing any hal configuration >>>>> and stepgens 4 and 5 work fine if they are controlling different GPIO >>>>> pins >>>>> without making any hal changes. I jumped the GPIO pins for a working >>>>> stepgen to the PCB pins I use for 4 and 5 and the interface hardware >>>>> works >>>>> fine that way. >>>>> >>>>> So the conclusion I'm drawing is that there's an issue with the >>>>> firmware that's getting built. hm2 thinks all 6 stepgens are there but >>>>> there is only 4 1/2 stepgens actually working. I seem to recall there is >>>>> a >>>>> parameter that has to change to add a certain amount of certain pin >>>>> types, >>>>> but I didn't think it applied in this case and I'm not sure what it is. >>>>> >>>>> My current VHD with SS disabled attached >>>>> >>>>> >>>>> >>>>> On Saturday, August 17, 2019 at 6:40:07 AM UTC-4, Michael Brown wrote: >>>>>> >>>>>> OK back to being able to be online with my workstation: >>>>>> I have allways had a fight setting up proper display resolutions on >>>>>> the altera soc's however I can give you some key notes: >>>>>> In qsys there are 3 cores to consider: >>>>>> For display timing settings: >>>>>> alt_vip_vfr_hdmi (framereader) >>>>>> >>>>>> alt_vip_itc_0 (Clocked video output) >>>>>> >>>>>> The display core clock itself: >>>>>> pll_lcd --> lcd_clk >>>>>> >>>>>> >>>>>>> 1600x900 would allow me to test it out on my mill and I might have a >>>>>>> use for 800x480. I didn't realize the resolution was fixed, my 1080P >>>>>>> monitors don't have a problem displaying 1024x768, all my other >>>>>>> monitors >>>>>>> do. I suppose in a real usage scenario I'd have to look further into >>>>>>> your >>>>>>> previous reply and try to figure out how to set a resolution for >>>>>>> whatever >>>>>>> monitor I intended to use. >>>>>> >>>>>> >>>>>> Sadly there are currently no presets for these 2 resolutions for the >>>>>> framebuffer related cores (presets are found in qsys view menu), as I >>>>>> havent had use of these resolutions myself (in newer time). >>>>>> And I also have no (qsys) formula other than intuitive guess work..... >>>>>> >>>>>> Last there is the Devicetree entry this is the current one: >>>>>> >>>>>> https://github.com/the-snowwhite/soc-image-buildscripts/blob/master/SD-Image-Gen/patches/4.9.76-ltsi-rt/current/0012-Added-DE-10-Nano-with-uio-with-without-framebuffer-1.patch#L291 >>>>>> >>>>>> This entry: >>>>>> >>>>>> vip@0x100031000 { >>>>>> compatible = "altr,vip-frame-reader-1.0", "ALTR,vip-frame-reader-9.1"; >>>>>> reg = <0x00000001 0x00031000 0x00000080>; >>>>>> max-width = <1024>; >>>>>> max-height = <768>; >>>>>> bits-per-color = <0x8>; >>>>>> colors-per-beat = <0x4>; >>>>>> beats-per-pixel = <0x1>; >>>>>> mem-word-width = <0x80>; >>>>>> }; >>>>>> >>>>>> >>>>>> On Friday, 9 August 2019 03:55:13 UTC+2, justin White wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Tuesday, August 6, 2019 at 1:07:38 PM UTC-4, Michael Brown wrote: >>>>>>>> >>>>>>>> Not very easy from my cell phone here however: >>>>>>>> In qsys there are 2 instances where you set up the timings for the >>>>>>>> screen monitor. There should be some saved setups HD etc. Lastly you >>>>>>>> need >>>>>>>> to place the correct screen settings in the device tree there is a HD >>>>>>>> example there too. 1920 x1080. Sorry for not being online atm... >>>>>>>> >>>>>>> >>>>>>> Gonna Give this a try soon as I get a chance. Waiting for my friend >>>>>>> to correct a minor issue with the time based filter in the RT hal >>>>>>> component >>>>>>> he whipped up for me for the ADC then I'll post it up here. Maybe you >>>>>>> can >>>>>>> include it in your project if you think it's useful. It certainly is >>>>>>> for >>>>>>> someone like me who only works with hal. >>>>>>> >>>>>> >>>>>> Well It would be nice with a hal rt component for calculating >>>>>> temperature readings based on ntc probes instead of the python user >>>>>> component hal_temp_atlas I derived from the hal_temp_bbb .... :-) >>>>>> >>>>>> >>>>>
-- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/07ff0dff-71df-488a-aadf-4bd46eaa6f66%40googlegroups.com.
