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/8908697e-9b48-416b-ad21-f364d1c24918%40googlegroups.com.
PIN_st_fpga_soc_dc1f.vhd
Description: Binary data
