On Tuesday, 7 May 2019 05:49:58 UTC+2, justin White wrote: > > Have you whached the presentation Charles linked to ? >> >> Actually I've seen the presentation about twice before it was mentioned > here. Just for reference, I'm not really trying to build the Quartus image > right now I'm just trying to figure out the actual FPGA pin usage so I know > how to interface it. My experience with Mesa cards is the AIO Eth cards > like the 7i76e and 7i96. In those cases the actual pins are already > hardware interfaced as in you wind up with a 6 pin differential encoder > input, and 4 pin step gen outputs. Without looking at the vhd file, I > probably would not have realized that it actually only uses 3 FPGA pins for > the encoder and 2 FPGA pins for the stepgens. > > When you are laying out your own custom DExx interface board, you don't have to stay restricted to allready made pinouts. you can create your own custom pinout containing any of the mesa cores contained in the top level of this folder: https://github.com/machinekit/mksocfpga/tree/master/HW/hm2 this commit shows all that is needed to do to to add a customized core/pin configuration: https://github.com/machinekit/mksocfpga/commit/0c48daa7620a16c132b70140297063a5fb889025
This section specifies what cores are created in the hardware: https://github.com/machinekit/mksocfpga/commit/0c48daa7620a16c132b70140297063a5fb889025#diff-e6cd80d773989dda2ea07b1afd468319R73 This section specifies the exact pins connected to each mesa core: https://github.com/machinekit/mksocfpga/commit/0c48daa7620a16c132b70140297063a5fb889025#diff-e6cd80d773989dda2ea07b1afd468319R111 All usable "tags" reside in this file: https://github.com/machinekit/mksocfpga/blob/master/HW/hm2/config/IDROMConst.vhd there are some notes written during the process of creating the mksocfpga project which also may be usefull: https://github.com/machinekit/mksocfpga/tree/master/docs The current workin quartus bitfile generators are the (DE0_xxx / DE10_xxx) projects residing in this folder: the xxxx_DB25 contain only the original Mesa functionality (ie no display and no DExx_Nano adc), and are geared towards the DB25 connector Charles has made to interface directly to Mesa hardware. It is importaint to note that some of the pinouts on the route from the .PIN file to the actual GPIO's are rerouted to different pins. The xxx_Cramps versions are (initially) geared towards interfacing with the Cramps interface made by Charles for the BBB, via Cramps2nano-soc here: https://github.com/the-snowwhite/socfpga-kicad This enables 3D printing. (Hence the ADC functionality), for those maybe seeking an easy path to upgrade from a Beagle B setup. > >> The xxx_Cramps (quartus project) configs are the only current configs >> that provide ADC functionality straight into the Hal, the tags are there so >> that the hostmot2 soc hal driver can pick them up if needed. >> >> With the DE0_Nano_SoC board the (xxx_CRAMPS) ADC functionality works as >> it is supposed to, for some mystical reason this is not the case with my 2 >> DE!0_Nano boards, so I'm trying to debug this issue currently. >> > > As for the ADC I just realized where I was getting confused there. I > didn't realize the ADC was an SPI interface (had to read the manual again). > I thought they were direct connections to the FPGA. That explains why the > ADC header doesn't appear as a separate 8 pin section in the vhd file. > > The ADC are actually connected directly to the FPGA via dedicated non changable I/O pins. via these 4 pins: https://github.com/machinekit/mksocfpga/blob/master/HW/QuartusProjects/DE10_Nano_FB_Cramps/DE10_Nano_FB_Cramps.sv#L12 However they are specific for the Terasic boards so this functionality is keept somewhat separate as it is har to make generiric enough for possible future additions. > Even though you may have written this earlier (someplace else) >> I would be great for me if you can place a description or a link as to >> what you are aiming to accomplish, so that I then can come up with more >> presice answers pointing you in the right direction. >> >> That's kind of difficult to say. Specifically I want to work up an > interface board for the DE10 Nano that's more or less specific to my > project machine. While I don't really need half of what I want to stuff in > there, ultimately a little extra time on the schematic and a couple of > chips and resistors is really all that extra functionallity costs. > > Remember it is very easy/simple to change pinouts inside the FPGA, you can also route to the Arduino connectors if so needed...! > Less specifically I've been working on a machine vision imaging system for > some time now. It's kind of a niche thing so it's hard to explain it's > actual purpose. This is like one of those probably never ending projects > that have any rational reasoning behind it, other than I've had to teach > myself quite a few different things every time I decided to do something > different. First I built a raggedy "proof of concept" running on > LinuxCNC/Mesa. Then I Converted a Small Mill to CNC once again running on > LinuxCNC to prototype some more reasonable parts. After designing the whole > thing I realized I wasn't super happy with all the bulk of the off the > shelf components so I learned KiCAD and started whipping up PCBs. I built a > a whole Glade GUI for it and a friend of mine has done all of the custom > programming. > > It currently runs on a reasonably powerful x86 PC that I built to be small > and use a DC-DC power supply so I can run the whole machine on a single 24v > supply. What happens there is that I wind up needing More CPU than actually > necessary because displaying the cameras uses quite a bit of processor and > it leads to high jitter on a marginal PC. I've gotten on an ARM kick > recently (I've got about 8 SBC's running all sorts of stuff, no Pi's > though) and realized that if I can run Machinekit on something like the > DE10Nano, I can keep the RT layer off the CPU that is connected to the > camera's and there's the added bonus that the FPGA is built right into the > same chip as the processor so that hardware becomes very small and low > power. On top of that I no longer actually need a fast X86 at all. Image > processing, without GPU acceleration spreads out very evenly along CPU > cores so these newer 6 core ARM processors handle it pretty well. I picked > up an Odroid N2 when it was released so it's not really wel developed under > Linux but it still handled it pretty well > Looks nice :-) https://www.hardkernel.com/blog-2/odroid-n2/ > > So yeah there's quite a bit of work to be done to get it running under MK > but I figured I'd start by trying to make the DE10 useable as a hardware > controller first. > > > https://www.dropbox.com/s/66sjfddnhj5u0mg/Video%20Sep%2007%2C%209%2014%2016%20AM_0.mov?dl=0 > > https://www.dropbox.com/s/tflf1rtmt8aof5q/remmina_Viewer1%20VNC_192.168.1.108_2019131-14244.932851.jpeg?dl=0 > > > The Current working DE10_Nano_FB_Cramps mksocfpga HW project has lots of surplus space in the fpga fabric: [image: Screenshot_DE10_Nano_FB_Cramps-device-utilisation.png] Later you could possibly move the image detection into the fpga fabric: https://rocketboards.org/foswiki/Projects/SoCLicensePlateRecognition Just an example... -- 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/2180fe02-96a6-49a4-8d8b-f8947d1cba54%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
