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/36d24fa5-765e-42c1-a87f-2c72748fa995%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
