I never got the hang of Quartus reporting..... :) After a full compilation Drag the line between the project navigator .. hieracy window and the Compilation report (table of contents ), to the right to expand the project navigator to show/see the LMN's needed info ..etc like in my pic above
On Monday, 19 August 2019 17:33:29 UTC+2, 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/1a2eb33b-6d72-4321-b479-b643a798ca5c%40googlegroups.com.
