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/9706c0b6-4988-4cea-8190-70c47808de84%40googlegroups.com.
