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
> [email protected] <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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/machinekit/19ec725e-5093-4368-a7ad-ae4cd07a2756%40googlegroups.com.
