using the 3.3v power is a good idea. I'm not particularly thrilled with the resistor dividers for various reasons so I'll have to go back to the drawing board on that. While I'm at it figure adding SSerial wouldn't be a bad idea. Wasn't really in the plans for this board but I'd probably kick myself if I didn't since My mill spindle has an 8i20 running on SSerial. Looks like there's examples in the repo so I'd assume it's working on SOCFPGA?
Looking at a 7i76e manual it's differential RS422 while the example configs suggest at the FPGA level it's a 2 pin RX/TX deal, is that right? One example shows a TX enable pin, but I don't think this is implemented on a board like the 7i76e which is all I'm trying to duplicate. Any insight on this? On Saturday, June 29, 2019 at 1:12:34 PM UTC-4, Michael Brown wrote: > > Its easy to convert float to u32 and visa versa in a handmade hal > component. > For the printer temp sensor config I created the: > hal_temp_atlas.py > <https://github.com/machinekit/machinekit-hal/blob/master/src/hal/user_comps/hal_temp_atlas.py> > user > component variant instansiated here: > > https://github.com/the-snowwhite/Hm2-soc_FDM/blob/master/Cramps/PY/Prusa-i3_Dev/cramps.py#L25 > > I ended up with wirering the Cramps adc reference to the 3.3 volt power > line, and then connecting adc channel 8 to the 3.3 V rail > used as a reference in that component. > > In a hal comp component you can just typecast between u32 and float like > in this comp: > Example is float to u32 > <https://github.com/the-snowwhite/Hm2-soc_FDM/blob/trinamic-spi/projects/Comp/trinamic_dbspi.comp#L150> > > > On Saturday, 29 June 2019 03:11:03 UTC+2, justin White wrote: >> >> 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/97312957-ccab-41a5-a86d-7a1a4feb3a9b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
