I figured that was pretty much the case, I just haven't seen the enable_adc parameter used. I added the parameter and the nano_soc_adc pins exposed in HAL as expected.
I suppose I didn't fully understand what to expect from the values the pins expose, I see an integer that looks to be 32bits wide (U32 pin) with a variation of 12bits if that makes any sense. With an input of 0v to the 5v_ref there is a change of 4096 which explains the 4v max. Slightly difficult to deal with with pure HAL. Passing the outputs through an offset then scale component is what I would do but since it's a U32 pin it'll require a U32 to float conversion first. I'm sure there's a more elegant way to handle the values but unless there's a more suitable hal component that's probably what I'd do. I didn't realize the value would max out at 4.095v but looking at the ADC chip's datasheet it does explain that. Not a huge deal as they can handle over 5v electrically. My 2nd board takes runs resistor dividers to accept 0-10v on 4 of the ADC pins. On Friday, June 28, 2019 at 6:24:04 PM UTC-4, Michael Brown wrote: > > Yes that tag's fine leave it as it is. (this tag gets the adc support > compiled into the .rbf) > Since the adc is onboard the adc pins are wired internally (not via > gpio's) so there are no pin settings in that file. > > All you need to do is ensure you load/instansiate the hostmot2_ol driver > with the enable_adc=1 parameter included. > > then the adc pins will show up on the hm2_5i25.0 component > (ie:hm2_5i25.0.nano_soc_adc.ch.0.out etc ) > > You can take a look at my python based Prusa-i3 config here: > > > https://github.com/the-snowwhite/Hm2-soc_FDM/blob/master/Cramps/PY/Prusa-i3_Dev/prusa-i3_dev.ini#L4 > > > https://github.com/the-snowwhite/Hm2-soc_FDM/blob/master/Cramps/PY/Prusa-i3_Dev/cramps.py#L85 > > BTW: remember that the DExx ADC's max out at 4 Volt... > > > > On Friday, 28 June 2019 02:59:20 UTC+2, justin White wrote: >> >> What is the method for using the ADC? I wasn't very concerned about the >> ADC on the first go so I didn't bother with it at all really. I'm going to >> have to whip up a new .vhd and .rbf for another revision of my board and >> I'm actually using it. >> >> I have the "pintype" copied over from the original .vhd I used as a >> template: >> (NANOADCTag, x"00", ClockLowTag, x"08", NANOADCAddr&PadT, >> NANOADCNumRegs, x"00", NANOADCBitMask), >> >> >> Couldn't find an example of how to add it to the pin description section >> of the PIN.vhd (if that's necessary) or how to instantiate it in the >> ini/hal file. >> >> >> On Friday, June 21, 2019 at 5:51:53 PM UTC-4, justin White wrote: >>> >>> Where did you find the (no-fw-load.ini)example where that line was Not >>>> commeted out ? >>> >>> Like I said in the first post, I started with that image. I couldn't >>> mount the original image to check the .ini but I do see that the Git repo >>> version is commented out. Maybe I uncommented it, not sure how I'd miss >>> uncommenting one line and not commenting the other though.........but it >>> happens. >>> >>> On Friday, June 21, 2019 at 6:27:55 AM UTC-4, Michael Brown wrote: >>>> >>>> I dont know how the discussion got off-list, so here's a paste: >>>> >>>> On Thu, Jun 20, 2019 at 6:10 PM Michael Brown write: >>>> Ups Sorry for providing too much information, let me clarify: >>>> You can use either: >>>> the no load ini method (requires you setup u-boot variables to program >>>> the fpga on boot) >>>> OR >>>> using a .dtbo file (device tree fragment that programs the fpga) you >>>> specify machinekit(the hm2_soc_ol driver) to load on startup >>>> But never both...! (as this will give problems with the uio device) >>>> >>>> So bottom line is If you choose to have the display option on th >>>> DE10_Nano hdmi port: forget the .dtbo related stuff. >>>> --- >>>> ok ? >>>> >>>> >>>> That's actually good to know. I don't think the framebuffer or at least >>>>> the HDMI port will be necessary after I get the hardware sorted out. Do >>>>> you >>>>> know if VNC require an actual framebuffer? If I can access the desktop >>>>> through VNC I would probably reconfigure without it when I'm done. >>>>> >>>> No I don't know about vnc. >>>> >>>> >>>>> Now that I look at it, the reason I messed with a .dtbo file in the >>>>> first place is because the .ini i modified contained the >>>>> "CONFIG=xxx3x24.dtbo" line and that was throwing LinuxCNC errors until I >>>>> renamed it. It's a bit confusing because the example FB .ini's still >>>>> reference a .dtbo file is compiled from a .dts file that points to a non >>>>> FB >>>>> .rbf. >>>>> I just commented out that config line in the .ini and MK still seems >>>>> to load up just fine, which is probably what I should have just done in >>>>> the >>>>> beginning. Should this line be removed, or commented out from the >>>>> provided >>>>> example MK no-load .ini's? >>>> >>>> >>>> Where did you find the (no-fw-load.ini)example where that line was Not >>>> commeted out ? >>>> >>>> >>>> On Thursday, 20 June 2019 23:37:42 UTC+2, justin White wrote: >>>>> >>>>> However can you explain to me why you think you need the .dtbo ? >>>>>> >>>>> >>>>> Well actually it's because you said: >>>>> >>>>> The .dtbo file is compiled from the (renamed/edited).dts file via the >>>>>> dtc (device tree compiler) tool. >>>>> >>>>> So if you just renamed the .dtbo file it will stil configure the fpga >>>>>> with the "old" .rbf file. >>>>> >>>>> >>>>> the "no-load.ini" (Machinekit does not load firmware on startup) >>>>>> method masks this mistake as it requires you load your firmware via >>>>>> u-boot >>>>>> before the linux kernel starts up (to not get a blank screen or worse if >>>>>> mackinekit re-loads the firmware). >>>>> >>>>> >>>>> So I thought you were saying that just renaming the .dts (plus >>>>> changing the firmware tag) and .dtbo files was not sufficient. It does >>>>> work >>>>> but I am using the "no-load.ini" right now. I have to make some changes >>>>> to >>>>> the board and the pinouts are changing some as well so since I have to do >>>>> this again I may as well figure out how to do it right. Are you >>>>> suggesting >>>>> that I don't need to worry about the .dtbo? >>>>> >>>>> On Thursday, June 20, 2019 at 4:12:49 AM UTC-4, Michael Brown wrote: >>>>>> >>>>>> You can just download the dtc compiler .deb from debian buster then >>>>>> you do not have to use the -@ switch. >>>>>> However can you explain to me why you think you need the .dtbo ? >>>>>> >>>>>> On Thursday, 20 June 2019 04:08:21 UTC+2, justin White wrote: >>>>>>> >>>>>>> Had to compile a newer version of dtc on the desktop, apparently the >>>>>>> -@ switch isn't available until later versions. I get a .dtbo output >>>>>>> but..... >>>>>>> >>>>>>> $ dtc -@ -I dts -O dtb -o DE0_Nano_SoC_Cramps.st_fpga_soc_dc1.dtbo >>>>>>> DE0_Nano_SoC_Cramps.st_fpga_soc_dc1.dts >>>>>>> DE0_Nano_SoC_Cramps.st_fpga_soc_dc1.dts:8.29-27.19: Warning >>>>>>> (unit_address_vs_reg): /fragment@0/__overlay__: node has a reg or >>>>>>> ranges >>>>>>> property, but no unit name >>>>>>> DE0_Nano_SoC_Cramps.st_fpga_soc_dc1.dts:18.59-26.27: Warning >>>>>>> (unit_address_format): /fragment@0/__overlay__/hm2-socfpga0@0x40000: >>>>>>> unit >>>>>>> name should not have leading "0x" >>>>>>> DE0_Nano_SoC_Cramps.st_fpga_soc_dc1.dts:4.20-28.11: Warning >>>>>>> (avoid_unnecessary_addr_size): /fragment@0: unnecessary >>>>>>> #address-cells/#size-cells without "ranges" or child "reg" property >>>>>>> DE0_Nano_SoC_Cramps.st_fpga_soc_dc1.dts:21.33-58: Warning >>>>>>> (interrupts_property): >>>>>>> /fragment@0/__overlay__/hm2-socfpga0@0x40000:interrupt-parent: Bad >>>>>>> phandle >>>>>>> >>>>>>> >>>>>>> Anything to worry about? >>>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> On Wednesday, June 19, 2019 at 8:26:04 PM UTC-4, Charles >>>>>>> Steinkuehler wrote: >>>>>>>> >>>>>>>> If you want to create an overlay you need to use the -@ command >>>>>>>> line >>>>>>>> switch with dtc. >>>>>>>> >>>>>>>> On 6/19/2019 7:02 PM, justin White wrote: >>>>>>>> > Any instructions on compiling the .dtbo? Trying to take some >>>>>>>> notes on what >>>>>>>> > I had to do to get this going and figured I'd try to do this the >>>>>>>> right way >>>>>>>> > but it keeps choking on the following error: >>>>>>>> > >>>>>>>> > machinekit@mksocfpga-nano-soc:/lib/firmware/socfpga/dtbo$ dtc -I >>>>>>>> dts -O dtb >>>>>>>> > -o DE0_Nano_SoC_Cramps.st_fpga_soc_dc1.dtbo >>>>>>>> > DE0_Nano_SoC_Cramps.st_fpga_soc_dc1.dts >>>>>>>> > Error: DE0_Nano_SoC_Cramps.st_fpga_soc_dc1.dts:1.12-18 syntax >>>>>>>> error >>>>>>>> > FATAL ERROR: Unable to parse input tree >>>>>>>> > >>>>>>>> > Same thing trying to compile it on my desktop and the DE10. Looks >>>>>>>> like it's >>>>>>>> > choking on "plugin" in the .dts file? >>>>>>>> > >>>>>>>> > >>>>>>>> > On Sunday, June 16, 2019 at 10:14:04 PM UTC-4, justin White >>>>>>>> wrote: >>>>>>>> >> >>>>>>>> >> Did you mean compiled ? >>>>>>>> >>> >>>>>>>> >> No, I mean copied >>>>>>>> >> >>>>>>>> >> The .dtbo file is compiled from the (renamed/edited).dts file >>>>>>>> via the dtc >>>>>>>> >>> (device tree compiler) tool. >>>>>>>> >>> So if you just renamed the .dtbo file it will stil configure >>>>>>>> the fpga >>>>>>>> >>> with the "old" .rbf file. >>>>>>>> >>> >>>>>>>> >> I couldn't find the .dtbo or .dts files so I figured I'd try >>>>>>>> this. No >>>>>>>> >> bullshit, it works. All of the I/O (encoders,stepgens) is where >>>>>>>> it belongs. >>>>>>>> >> Though if I do find the right files I'll move them. >>>>>>>> >> >>>>>>>> >>> the "no-load.ini" (Machinekit does not load firmware on >>>>>>>> startup) method >>>>>>>> >>> masks this mistake as it requires you load your firmware via >>>>>>>> u-boot before >>>>>>>> >>> the linux kernel starts up (to not get a blank screen or worse >>>>>>>> if >>>>>>>> >>> mackinekit re-loads the firmware). >>>>>>>> >>> >>>>>>>> >> Maybe that explains it :) >>>>>>>> >> >>>>>>>> >> >>>>>>>> >>> you need to change the u-boot variable bitimage: >>>>>>>> >> >>>>>>>> >> (assuming you copied you new (st_fpga_soc_dc1.rbf ?) bitfile to >>>>>>>> >> /lib/firmware/socfpga) you can do: >>>>>>>> >> sudo fw_setenv bitimage >>>>>>>> '/lib/firmware/socfpga/st_fpga_soc_dc1.rbf' >>>>>>>> >> sudo reboot now >>>>>>>> >> On the soc >>>>>>>> >> and then watch for the flashing led :-) >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> That's what I did, the LED flashes and I've been using it since >>>>>>>> my last >>>>>>>> >> post. Like you said, maybe I got away with it because of the >>>>>>>> "no-load" >>>>>>>> >> >>>>>>>> >> On Sunday, June 16, 2019 at 9:27:41 PM UTC-4, Michael Brown >>>>>>>> wrote: >>>>>>>> >>> >>>>>>>> >>> I had some errors starting MK. I copied the 3x24.dtbo >>>>>>>> >>>> >>>>>>>> >>> Did you mean compiled ? >>>>>>>> >>> >>>>>>>> >>> >>>>>>>> >>>> and dts and renamed it to match my config >>>>>>>> >>>> >>>>>>>> >>> >>>>>>>> >>> The .dtbo file is compiled from the (renamed/edited).dts file >>>>>>>> via the dtc >>>>>>>> >>> (device tree compiler) tool. >>>>>>>> >>> So if you just renamed the .dtbo file it will stil configure >>>>>>>> the fpga >>>>>>>> >>> with the "old" .rbf file. >>>>>>>> >>> >>>>>>>> >>> >>>>>>>> >>>> and changed the firmware line in the dts to point to the new >>>>>>>> firmware. >>>>>>>> >>>> Then all it seems I had to do was modify the no-load.ini >>>>>>>> >>>> >>>>>>>> >>> >>>>>>>> >>> the "no-load.ini" (Machinekit does not load firmware on >>>>>>>> startup) method >>>>>>>> >>> masks this mistake as it requires you load your firmware via >>>>>>>> u-boot before >>>>>>>> >>> the linux kernel starts up (to not get a blank screen or worse >>>>>>>> if >>>>>>>> >>> mackinekit re-loads the firmware). >>>>>>>> >>> >>>>>>>> >>> >>>>>>>> >>>> to point to my firmware and instantiate the proper number of >>>>>>>> stepgens >>>>>>>> >>>> and encoders. >>>>>>>> >>>> >>>>>>>> >>> >>>>>>>> >>> --> no >>>>>>>> >>> >>>>>>>> >>>> Looks like a good start until I get a chance to write a proper >>>>>>>> hal file >>>>>>>> >>>> - >>>>>>>> >>>> >>>>>>>> >>> you need to change the u-boot variable bitimage: >>>>>>>> >>> (assuming you copied you new (st_fpga_soc_dc1.rbf ?) bitfile to >>>>>>>> >>> /lib/firmware/socfpga) you can do: >>>>>>>> >>> >>>>>>>> >>> sudo fw_setenv bitimage >>>>>>>> '/lib/firmware/socfpga/st_fpga_soc_dc1.rbf' >>>>>>>> >>> sudo reboot now >>>>>>>> >>> On the soc >>>>>>>> >>> and then watch for the flashing led :-) >>>>>>>> >>> >>>>>>>> >>> >>>>>>>> >>> >>>>>>>> >>> On Sunday, 16 June 2019 22:24:41 UTC+2, justin White wrote: >>>>>>>> >>>> >>>>>>>> >>>> I renamed the files you mentioned and got an output, not sure >>>>>>>> if the >>>>>>>> >>>> below error means anything: >>>>>>>> >>>> >>>>>>>> builder@300dd4c4fceb:/work/HW/QuartusProjects/DE10_Nano_FB_Cramps$ >>>>>>>> >>>> Inconsistency detected by ld.so: dl-close.c: 762: _dl_close: >>>>>>>> Assertion >>>>>>>> >>>> `map->l_init_called' failed! >>>>>>>> >>>> >>>>>>>> >>>> >>>>>>>> >>>> I had some errors starting MK. I copied the 3x24.dtbo and dts >>>>>>>> and >>>>>>>> >>>> renamed it to match my config and changed the firmware line in >>>>>>>> the dts to >>>>>>>> >>>> point to the new firmware. Then all it seems I had to do was >>>>>>>> modify the >>>>>>>> >>>> no-load.ini to point to my firmware and instantiate the proper >>>>>>>> number of >>>>>>>> >>>> stepgens and encoders. Looks like a good start until I get a >>>>>>>> chance to >>>>>>>> >>>> write a proper hal file >>>>>>>> >>>> >>>>>>>> >>>> >>>>>>>> >>>> On Sunday, June 16, 2019 at 12:53:10 PM UTC-4, Michael Brown >>>>>>>> wrote: >>>>>>>> >>>>> >>>>>>>> >>>>> Looking at your errorlog this is what sticks out for me: >>>>>>>> >>>>> >>>>>>>> >>>>> Warning (12019): Can't analyze file -- file >>>>>>>> >>>>> ../../hm2/config/DExx_Nano_xxx_Cramps/ >>>>>>>> atlas_st_fpga_soc_dc1.sv is >>>>>>>> >>>>> missing >>>>>>>> >>>>> >>>>>>>> >>>>> So you can create a copy of a suitable atlas_3x24 .....sv >>>>>>>> named >>>>>>>> >>>>> atlas_st_fpga_soc_dc1.sv >>>>>>>> >>>>> < >>>>>>>> http://www.google.com/url?q=http%3A%2F%2Fatlas_st_fpga_soc_dc1.sv&sa=D&sntz=1&usg=AFQjCNFaXzIhSaX4akk6lI9iwZh_k2ltVA> >>>>>>>> >>>>>>>> >>>>>>>> >>>>> (With your naming convention), >>>>>>>> >>>>> and customize it if you fell so inclined..... then it should >>>>>>>> build. >>>>>>>> >>>>> Best Wishes >>>>>>>> >>>>> Michael Brown >>>>>>>> >>>>> >>>>>>>> >>>>> >>>>>>>> >>>>> >>>>>>>> >>>>> On Sunday, 16 June 2019 18:36:03 UTC+2, Michael Brown wrote: >>>>>>>> >>>>>> >>>>>>>> >>>>>> Please notice that only the header and extension is >>>>>>>> different in the >>>>>>>> >>>>>> two added files: >>>>>>>> >>>>>> >>>>>>>> >>>>>> >>>>>>>> HW/hm2/config/DExx_Nano_xxx_Cramps/PIN_3x24_cap_enc_dbspi.vhd >>>>>>>> >>>>>> HW/hm2/config/DExx_Nano_xxx_Cramps/ >>>>>>>> atlas_3x24_cap_enc_dbspi.sv >>>>>>>> >>>>>> >>>>>>>> >>>>>> >>>>>>>> >>>>>> On Sunday, 16 June 2019 18:31:31 UTC+2, Michael Brown wrote: >>>>>>>> >>>>>>> >>>>>>>> >>>>>>> To add a new config you have to add 2 new files like in >>>>>>>> this pending >>>>>>>> >>>>>>> commit Charles yet has not had time to look at: >>>>>>>> >>>>>>> >>>>>>>> >>>>>>> >>>>>>>> https://github.com/machinekit/mksocfpga/pull/106/commits/cf035069c539dda57131a2190499f204f9f5412f >>>>>>>> >>>>>>>> >>>>>>> >>>>>>>> >>>>>>> Note that I have tried to build a cosistant (by function) >>>>>>>> file naming >>>>>>>> >>>>>>> convention as the names of the 2 files reflect in the >>>>>>>> bitfiles you get out >>>>>>>> >>>>>>> at the other end. >>>>>>>> >>>>>>> >>>>>>>> >>>>>>> >>>>>>>> >>>>>>> On Sunday, 16 June 2019 14:25:23 UTC+2, Charles >>>>>>>> Steinkuehler wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> It looks like the pertinent error is: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Error (10161): Verilog HDL error at >>>>>>>> DE10_Nano_FB_Cramps.sv(132): >>>>>>>> >>>>>>>> object "boardtype" is not declared. Verify the object name >>>>>>>> is >>>>>>>> >>>>>>>> correct. >>>>>>>> >>>>>>>> If the name is correct, declare the object. File: >>>>>>>> >>>>>>>> >>>>>>>> /work/HW/QuartusProjects/DE10_Nano_FB_Cramps/DE10_Nano_FB_Cramps.sv >>>>>>>> >>>>>>>> Line: 132 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I'm not quite sure what's going wrong, I haven't really >>>>>>>> worked with >>>>>>>> >>>>>>>> Michael's new System Verilog top-level design. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 6/15/2019 8:31 PM, justin White wrote: >>>>>>>> >>>>>>>>> Trying to build the bitfile, I'm sure I'm doing something >>>>>>>> wrong. >>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>>> I modified the "PIN_3x24_cap_enc.vhd" pinfile posted >>>>>>>> earlier to >>>>>>>> >>>>>>>> suit my >>>>>>>> >>>>>>>>> board and tried to build it via the readme based on the >>>>>>>> >>>>>>>>> "DE10_Nano_FB_Cramps" project. I'm sure I'm missing a >>>>>>>> step here. >>>>>>>> >>>>>>>> Print and >>>>>>>> >>>>>>>>> .vhd attached. >>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>>> On Saturday, June 15, 2019 at 2:55:03 PM UTC-4, justin >>>>>>>> White >>>>>>>> >>>>>>>> wrote: >>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>>>> No smoke yet. >>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>>>> [image: Photo Jun 15, 2 47 40 PM.jpg] >>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>>>> On Tuesday, June 11, 2019 at 10:41:16 PM UTC-4, justin >>>>>>>> White >>>>>>>> >>>>>>>> wrote: >>>>>>>> >>>>>>>>>>> >>>>>>>> >>>>>>>>>>> Well once I get a PCB all assembled I'll have to go >>>>>>>> back through >>>>>>>> >>>>>>>> this >>>>>>>> >>>>>>>>>>> thread and figure out how to get the FPGA all set up >>>>>>>> lol. The >>>>>>>> >>>>>>>> Arduino >>>>>>>> >>>>>>>>>>> connector on the DE10 kind of irk me, they are extended >>>>>>>> height >>>>>>>> >>>>>>>> an 4 or 5mm >>>>>>>> >>>>>>>>>>> taller than the 2x20 headers so either tall pin sockets >>>>>>>> have to >>>>>>>> >>>>>>>> be sourced >>>>>>>> >>>>>>>>>>> or I've thought about just desoldering the Arduino >>>>>>>> connectors >>>>>>>> >>>>>>>> from the DE10. >>>>>>>> >>>>>>>>>>> >>>>>>>> >>>>>>>>>>> On Tuesday, June 11, 2019 at 1:56:27 AM UTC-4, Bas de >>>>>>>> Bruijn >>>>>>>> >>>>>>>> wrote: >>>>>>>> >>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>> On 11 Jun 2019, at 01:25, justin White < >>>>>>>> [email protected]> >>>>>>>> >>>>>>>> wrote: >>>>>>>> >>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>> Possibly, >>>>>>>> >>>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>> Need to do some testing once I get the first rev >>>>>>>> assembled. >>>>>>>> >>>>>>>> This >>>>>>>> >>>>>>>>>>>> Particular board is probably a bit too expensive to >>>>>>>> make for >>>>>>>> >>>>>>>> the open >>>>>>>> >>>>>>>>>>>> source world to want, and the I/O arrangement is >>>>>>>> somewhat >>>>>>>> >>>>>>>> specific to my >>>>>>>> >>>>>>>>>>>> needs. That many Phoenix Contact blocks gets pretty >>>>>>>> expensive. >>>>>>>> >>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>> I would be interested, keep me updated! >>>>>>>> >>>>>>>>>>>> I think machinekit can do with some additional >>>>>>>> hardware between >>>>>>>> >>>>>>>>>>>> controllers and wires. >>>>>>>> >>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>> but imo cheap is a nice to have, function and quality >>>>>>>> come >>>>>>>> >>>>>>>> first. Think >>>>>>>> >>>>>>>>>>>> about how something industrial gets wired. Then you >>>>>>>> need some >>>>>>>> >>>>>>>> contact >>>>>>>> >>>>>>>>>>>> blocks to easily connect wires. In the total a more >>>>>>>> expensive >>>>>>>> >>>>>>>> part here >>>>>>>> >>>>>>>>>>>> will give you an edge somewhere else (manual labor). >>>>>>>> And indeed >>>>>>>> >>>>>>>> when you’re >>>>>>>> >>>>>>>>>>>> a diy-er labor does not come into the equation. >>>>>>>> >>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>>> I'll probably drop some OS version into the wild once >>>>>>>> I get it >>>>>>>> >>>>>>>> sorted, >>>>>>>> >>>>>>>>>>>> with a more general I/O layout. This board is setup >>>>>>>> with 6 >>>>>>>> >>>>>>>> differential (or >>>>>>>> >>>>>>>>>>>> single ended) encoder inputs, 6 differential stepgen >>>>>>>> outputs, >>>>>>>> >>>>>>>> 16 5v-30v >>>>>>>> >>>>>>>>>>>> inputs, 24 field voltage outputs up to 500ma, 2 >>>>>>>> opto-mosfet >>>>>>>> >>>>>>>> outputs @2A >>>>>>>> >>>>>>>>>>>> snubbed. Has a 5A 5v DC-DC regulator that will accept >>>>>>>> up to >>>>>>>> >>>>>>>> 42VDC, power >>>>>>>> >>>>>>>>>>>> the DE10-nano through GPIO and output the spare 5v up >>>>>>>> to 3A. My >>>>>>>> >>>>>>>> method of >>>>>>>> >>>>>>>>>>>> stepgen outputs and GP inputs needs some testing. >>>>>>>> >>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> >>>>>>>> Charles Steinkuehler >>>>>>>> >>>>>>>> [email protected] >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>>> > >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> 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]. Visit this group at https://groups.google.com/group/machinekit. To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/22e17e8a-ae17-4886-9a46-344ad8580a50%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
