Yeah you fumbled and things looked a bit odd on Github until I understood what you had attempted, no biggie :-) (wrote you some notes there)
--- The Bitfiles are generated and distributed via a online build system in apt packages: Whats not so apparent is that when a PR to the mksocfpga repo is merged (always by someone different than the submitter as a rule), this merge starts first an online bitfile builder that builds the bitfiles for both the Quartus and the Vivado projects, afterwards these bitfiles are piped into a package build system that first puts the new bitfiles into debian packages(named socfpga-bit and socfpga-rbf), and lastly exports them to the machinekit repo. (if all goes well) 'This whole build process takes somewhere around 2 hours. --- Next time a machinekit(socfpga) user then does: sudo apt update && sudo apt upgrade The new bitfiles are then pulled into his/hers system and automatically placed in the correct folders. On Monday, 30 September 2019 23:21:07 UTC+2, justin White wrote: > > Forked and created a new PR, git is not my specialty. "dc1f" wasn't > "released", dc1G is the correct config. I don't see any bitfiles in > mksocfpga, only pin files. If you want me to PR the bitfile let me know > where it goes. > > On Mon, Sep 30, 2019 at 3:52 AM Michael Brown <[email protected] > <javascript:>> wrote: > >> @Justin >> I just created a PR <https://github.com/machinekit/mksocfpga/pull/109> >> including >> the boards bitfile, I recon the lase edit of the PIN config file >> <https://github.com/machinekit/mksocfpga/pull/109/files#diff-e3c15966cdcbd9f076f42fe47e6aa88f>is >> >> in order else place your corrections as a commit message. >> Best wishes >> Michael B. >> >> On Monday, 23 September 2019 05:34:48 UTC+2, justin White wrote: >>> >>> I've decided to release the board I've been working on pretty much as >>> is, just with some open source considerations. It was intended for a >>> specific machine, but I rung out all of the I/O possibillities I could, no >>> DE10 GPIO pin went unused. There is an onboard 5v regulator that will power >>> the nano from GPIO and has a PTC fused connector to power about 3A worth of >>> external whatever. Specs: >>> >>> 9-25v VIN, >>> 5v regulator powers Nano from GPIO >>> 6 differential stepgen interfaces with 5v enable (for external drivers) >>> 6 differential encoder inputs (single ended encoders pull down encoders >>> work fine as well with no extra wiring) >>> 16 sourcing outputs at supplied field voltage Outputs are done at >>> whatever field voltage supplies the board (recommend 24v) >>> 2 high current opto-mosfet outputs >>> 16 inputs arranged with single 3-pin connectors each to simplify NPN or >>> PNP type switch wiring. Inputs upto 30v >>> 1 RS422 connector interface for SmartSerial. (not well tested, may be >>> issues with MK SS) >>> On PCB terminal blocks for ground and field V+ that simplify wiring in >>> smaller machines >>> a 3A PTC fused connector for powering external devices from the overkill >>> 5V/5A regulator (Nano+onboard components probably don't use more than 2.5A >>> @ 5v) >>> 2 scaled analog input interfaces (4 channels each). 5v interface for >>> using potentiometers and such at 5v_ref, and one 4 channel interface that >>> is hardware scaled to accept 0-10v external input. (ADC hal component in >>> repo) >>> >>> The stepgens or outputs could probably be configured in hm2 firmware to >>> support PWM. Stepgens would provide differential PWM @ 5v, outputs would be >>> single ended PWM @ supplied field voltage haven't tested PWM yet but >>> there's not much to it. >>> >>> There are hal files, a gladevcp GUI, and display python file that will >>> set the DE10-FB image up as a test platform for the board. The hal files >>> are examples of pin masking and pin inversion that is done in hal to make >>> the i/o intuitive. It could use some sort of hm2 overlay type thing but >>> that is beyond me. There is also 2 versions of an ADC hal component that >>> will convert the 12bit data from the onboard ADC into a usable scaled >>> voltage input in hal. >>> >>> The board isn't super cheap, that wasn't the intention but compared to >>> the BBB hardware it's probably not too bad. It's a fairly large board >>> (200x155), but that's because I prefer Phoenix connectors and overall >>> wiring cleanliness over small form factor stuff. Still working on the git, >>> but it's up. >>> >>> https://github.com/ShadeTechnik/socfpga-developement-OSHW >>> >>> Testing a stepgen and encoder: >>> >>> https://www.dropbox.com/s/qa4ro9r0io0dlvf/Video%20Sep%2022%2C%209%2054%2040%20PM.mov?dl=0 >>> >>> >>> >>> >>> >>> >>> >>> -- >> 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] <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/machinekit/a966b8b2-ac8e-4c8f-831e-c481ef8ddc44%40googlegroups.com >> >> <https://groups.google.com/d/msgid/machinekit/a966b8b2-ac8e-4c8f-831e-c481ef8ddc44%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- 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/4c4cdbef-854f-488a-a73c-20a660f0a97b%40googlegroups.com.
