Well that makes sense, my SS pins were on GPIO1_00 and GPIO1_01, Stepgens start on GPIO1_02 so it might explain quite a bit.
I would have tested it out a bit earlier but I went full nerd yesterday and built a 3900x/5700xt system I've been working on getting running. I got quatus installed and used the config files you attached and I see all of the stepgens are now full. Going to build the .rbf and set it back up to test SS again......hopefully it all just....works lol thanks fellas On Tuesday, August 20, 2019 at 2:06:34 PM UTC-4, Michael Brown wrote: > > Note: > It did really help to have your full quartus project online to play with, > that was probaly what immediately triggered my internal > analyzer/debugger.... :-) > > On Tuesday, 20 August 2019 19:54:02 UTC+2, Michael Brown wrote: >> >> Valid Files Here: >> >> On Tuesday, 20 August 2019 19:50:53 UTC+2, Michael Brown wrote: >>> >>> Ups Sorry sorry sorry ... my BAD .... (Suddently my biain kicked in :-) ) >>> I should have spotted it immediately. >>> Culprit is due to my single experimental (verilog) added capasitive >>> depth/touch sensor core. >>> This is not a part of the "original mesa hm2 vhdl config system, and the >>> pins are hardwired to: >>> GPIO_1 pins 00 + num sense parameter. (if that exact core is enabled in >>> config file) >>> --- >>> Solution is very simple: >>> edit mksocfpga/HW/hm2/config/DExx_Nano_xxx_Cramps/ >>> atlas_st_fpga_soc_dc1f_ss.sv >>> --> parameter Capsense = 0; >>> >>> I have tested with: >>> (StepGenTag, x"02", ClockLowTag, x"06", >>> StepGenRateAddr&PadT, StepGenNumRegs, x"00", StepGenMPBitMask), >>> >>> and all >>> SRL16E:\steptable:1:asr16e 4.2 (0.0) 8.5 (0.0) 4.3 (0.0) 0.0 (0.0) 0.0 >>> (0.0) 5 (0) 17 (0) 0 (0) 0 0 0 0 0 >>> entities show up populated. >>> :-) >>> once again excuse for my temporary brain paralysys.. >>> ... >>> >>> On Tuesday, 20 August 2019 16:30:50 UTC+2, Charles Steinkuehler wrote: >>>> >>>> Dig through the synthesis log (*.map.rpt) a bit and look for warnings >>>> that indicate undriven nets. Sadly, most tool chains consider >>>> undriven signals a warning vs. an error, so they'll happily optimize >>>> away huge chunks of your design. A typical warning would look >>>> something like: >>>> >>>> Warning (10541): VHDL Signal Declaration warning at >>>> HD_Core_CycloneV_pipen1b.vhd(45): used implicit default value for >>>> signal "clk250_out" because signal was never assigned a value or an >>>> explicit default value. Use of implicit default value may introduce >>>> unintended design optimizations. >>>> >>>> In vim, I use the regex: ^Warning.*$ which highlights the whole line >>>> (if you're in GUI mode). >>>> >>>> Note you will see lots of other warnings, most of which are probably >>>> OK. In particular, the ever present: >>>> >>>> Warning (10036): Verilog HDL or VHDL warning at >>>> HD_Core_CycloneV.vhd(471): object "HDMI_clk" assigned a value but >>>> never read >>>> >>>> ...is (usually) perfectly OK, it's similar to an unused variable in >>>> "C". This _might_ be an actual error (if the signal was supposed to >>>> go somewhere) but is typically OK. >>>> >>>> On 8/20/2019 9:09 AM, justin White wrote: >>>> > Thanks for the advice Charles. Actually I use this project: >>>> > >>>> https://github.com/machinekit/mksocfpga/tree/master/HW/QuartusProjects/DE10_Nano_FB_Cramps >>>> >>>> > >>>> > Michael explained it has more functionallity than the DB25 project, >>>> so I've >>>> > never tried the DB25. >>>> > >>>> > Not really up on my git stuff, I forked master and slapped my config >>>> files >>>> > in, like I said these are modifications of the "3x24_cap_enc" config. >>>> > https://github.com/blazini36/mksocfpga >>>> > >>>> > The pin assignments are so different from anything else I can't >>>> imagine >>>> > it's looking at another pinfile, it's likely I just didn't modify >>>> something >>>> > I probably should have. I'll try to look into your suggestions a bit >>>> later. >>>> > >>>> > >>>> > On Tuesday, August 20, 2019 at 9:41:57 AM UTC-4, Charles Steinkuehler >>>> wrote: >>>> >> >>>> >> It sounds like the synthesis tools are optimizing away the stepgen >>>> >> logic, almost certainly because of an issue with signal connectivity >>>> >> to the top level I/O pins. The actual step accumulator is still >>>> >> generated because it's value gets read back via the register >>>> >> interface, but the steptables are only needed to generate the output >>>> >> signals so they're getting optimized away. >>>> >> >>>> >> Is your project checked into github somewhere I can grab it? I can >>>> >> try building in the desktop Quartus tools and see what's wrong. >>>> >> >>>> >> Otherwise, double-check the pin assignments the top-level I/O port >>>> >> definitions, and make sure the physical I/O pins are properly >>>> >> connected to the hm2 instance. >>>> >> >>>> >> I took a quick look at the project I think you're using: >>>> >> >>>> >> >>>> >> >>>> https://github.com/machinekit/mksocfpga/blob/master/HW/QuartusProjects/DE10_Nano_SoC_FB_DB25/ >>>> >>>> >> >>>> >> ...and the top-level stuff looks OK at first glance. The important >>>> >> part is the use of the correct PIN_<config> library, which gets >>>> called >>>> >> out here: >>>> >> >>>> >> >>>> >> >>>> https://github.com/machinekit/mksocfpga/blob/master/HW/QuartusProjects/DE10_Nano_SoC_FB_DB25/hostmot2_cfg.vhd.in#L74 >>>> >>>> >> >>>> >> Make sure in your working copy the hostmot2_cfg.vhd file is getting >>>> >> generated with the correct name in the "use" line, and make sure the >>>> >> pin file you're including in the project has proper values for >>>> IOWidth >>>> >> and IOPorts. >>>> >> >>>> >> You can dig through the first part of the compile log messages to >>>> >> verify the correct PIN file is _really_ getting analyzed and not >>>> some >>>> >> other file. >>>> >> >>>> >> I'm also not sure how mixing the system verilog config files with >>>> VHDL >>>> >> packages works (I know just enough Verilog to generally be able to >>>> >> transcode it to VHDL). If there's any problems with that, Michael >>>> B. >>>> >> will have to comment. >>>> >> >>>> >> On 8/20/2019 8:04 AM, justin White wrote: >>>> >>> I deleted my mksocfpga directory and re-pulled it and I get the >>>> same >>>> >>> results after building the .rbf. >>>> >>> >>>> >>> Still not quite sure what's going on, though I did catch something >>>> in >>>> >>> Quartus. Using "0A" for stepgens in the pinfile creates 10 >>>> stepgens, >>>> >> but >>>> >>> only the first 4 seem to be complete. #4 (the 5th stepgen) when >>>> expanded >>>> >>> shows blank resources for "SRL16E:\steptable:0:asr16e", but does >>>> show >>>> >>> resources for "SRL16E:\steptable:1:asr16e". On every stepgen after >>>> they >>>> >> are >>>> >>> both blank which looks like it mimics exactly the problem I'm >>>> having. If >>>> >> "steptable:1" >>>> >>> relates to the dir pin and "steptable:0" relates to the step pin, >>>> it >>>> >>> explains why I have a working direction pin on #4 but no step pin, >>>> and >>>> >> #5 >>>> >>> doesn't work at all. In this case I'd assume no later stepgens >>>> would >>>> >> work. >>>> >>> >>>> >>> I'm not really sure how Quartus works with the configs. I'm just >>>> >> dropping >>>> >>> the pinfile I made into the >>>> >>> '../mksocfpga/HW/hm2/config/DExx_Nano_xxx_Cramps' directory and >>>> renaming >>>> >>> the "atlas_3x24_cap_enc.sv" to match my pinfile, which is what I >>>> do >>>> >> with >>>> >>> the mksocfpga docker build. I don't specify a pinfile or anything >>>> when >>>> >>> running the analysis in Quartus, yet it does seem to catch the >>>> changes >>>> >> I've >>>> >>> made to that specific pinfile even though I don't specify anything >>>> in >>>> >>> Quartus, I just load the "DE10_Nano_FB_Cramps.qpf" file. >>>> >>> >>>> >>> Pics, QP1 shows all 10 stepgens, QP2 shows the difference between >>>> the >>>> >>> working #3 stepgen (0-3 all look the same) and #4 and #5 where the >>>> >> problem >>>> >>> starts. "combinational ALUTS" and every feild after is blank. >>>> >>> >>>> >>> [image: QP1.png] >>>> >>> >>>> >>> [image: QP2.png] >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> On Monday, August 19, 2019 at 5:00:11 PM UTC-4, Michael Brown >>>> wrote: >>>> >>>> >>>> >>>> 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] >>>> >>>>> >>>> >>>> >>>> >>> >>>> >> >>>> >> >>>> >> -- >>>> >> Charles Steinkuehler >>>> >> [email protected] <javascript:> >>>> >> >>>> > >>>> >>>> >>>> -- >>>> Charles Steinkuehler >>>> [email protected] >>>> >>> -- 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/0a8b6106-9b68-458b-a344-a108bc48b8a6%40googlegroups.com.
