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 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. To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/c32a696d-a585-98aa-4ffd-831c821a6375%40steinkuehler.net.
