Thanx for the clairifying Charles, I doublechecked tha line and it reads: (StepGenTag, x"02", ClockLowTag, x"06", StepGenRateAddr&PadT, StepGenNumRegs, x"00", StepGenMPBitMask),
So that should be ok... On Monday, 19 August 2019 22:37:42 UTC+2, Charles Steinkuehler wrote: > > Actually, the NumInstances field of the ModuleRecord is defined as an > 8 bit std_logic_vector: > > > https://github.com/machinekit/mksocfpga/blob/master/HW/hm2/config/IDROMConst.vhd#L839 > > > In VHDL, it should throw an error if you use 06 for this value (VHDL > won't convert an integer value into a std_logic_vector without some > sort of type conversion). > > If you meant that you are using x"06" (an 8-bit hexadecimal value), > that should work fine, but you will only get 6 stepgens instead of the > 10 you'd get with x"0A". > > On 8/19/2019 3:19 PM, Michael Brown wrote: > > 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 .... :-) > >>>>>>> > >>>>>>> > >>>>>> > > > > > -- > Charles Steinkuehler > cha...@steinkuehler.net <javascript:> > -- 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/19ec725e-5093-4368-a7ad-ae4cd07a2756%40googlegroups.com.