DE10 Nano suggested development environment?

[justin White]

So I picked up a DE10 Nano to do some testing on. As I explained in a previous thread, a remote GUI running on a different CPU is the intended goal with the DE10-Nano handling MK and the hardware headless as I'm sure most would intend it's use. I'm having all sorts of issues with just about everything MachineKit but this I got somewhere with.

I need to work on making an interface board to get useable I/O out of this thing for my intended purpose. I found the "DE10-Nano/mksocfpga_stretch_machinekit_4.9.76-2018-05-26-de10_nano_desktop_sd.img" and got that setup with HDMI support and LXqt. The thought is that If I can get a working GUI setup going with a more or less generic bitfile I can basically breadboard the DE10-Nano and use HalShow and a few other LinuxCNC tools to verify the circuits. I ran into a couple of issues and there's some things I'm unsure of....

I tried what sounded like a more ideal bitimage but the HDMI output was no good unless I used the /lib/firmware/socfpga/DE10_Nano_FB_Cramps.3x24_cap.rbf bitimage. I couldn't find info on what the pin designations for this image are, I'm not really up to snuff on the 3D-printer/CRAMPS thing. I'm not really sure of how to create my own bitfile either especially if it's tied to the HDMI out.

I did load MK and the only stock config I could get to load was the something "SOC-no-fw-load"  config. I assume this does not reprogram the FPGA on start since the "fpgaload_on_boot 1" variable is set to program the FPGA on boot? Since I have no hardware to attach I can't really say whether the I/O was actually doing anything although I guess I would expect following errors or something if it wasn't while I was jogging around. I also couldn't start Halshow from the Axis GUI, just didn't open. It'd be great if somebody could point me in the right direction as to how I can either setup my own hardware bitfile or use a rather generic one that I can reference pin designations too. Really I'm just looking to breadboard an encoder interface and level shifting circuits and get some feedback from MK as to how the GPIO is responding at this point. 

[mib.hol...@gmail.com]

Hi Justin

The DE10_Nano_FB_Cramps.3x24_cap.rbf bitfile is as the name implies designed to interface with a Cramps board and provide a framebuffer onthe hdmi pins of the DE10 Nano.

I have created an Interface board for interfacing the DExx Nano (soc) boards to the Cramps and

the design files are here: 

https://github.com/the-snowwhite/socfpga-kicad/tree/master/Cramps2nano-soc

https://github.com/the-snowwhite/socfpga-kicad/blob/master/Cramps2nano-soc/Cramps2Nano.pdf

This shows the pins of the DExx Gpio pins and can be easiely bread boarded.

The cap sensor is not part of Cramps functionality so these pins are not on that schematic...

--

About the  "SOC-no-fw-load" config method:

This makes Machinekit not reprogram the fpga when MACHINEKIT starts... correct

The  "fpgaload_on_boot 1" in u-boot makes u-boot program the fpga BEFORE linux starts up so that the Framebuffer then can be picked up,

Ensure that the right devicetree (the one with framebuffer enabled) is loaded by u-boot.

Really I'm just looking to breadboard an encoder interface and level shifting circuits and get some feedback from MK as to how the GPIO is responding at this point

 Coincendentially I have just purchased an encoder:

E6B2-CWZ6C

And will be doing the same exercise currently it seems... :-)

While it may be possible to hook up this encoder to some gpio pins and then run a "soft" encoder in the hal,

the Mesa Hostmot2 cores do provide Encoder cores that can be run in the fpga HW fabric, this meens a new config has to be added to the DE10_Nanoxxx_FBxxxx Quartus project in the Mksocfpga repo

http://www.machinekit.io/docs/drivers/hostmot2/#encoder

[justin White]

Thanks for the response, I was beginning to think I wasn't going to get any help on this one.

That's a coincidence, I use the same 1000PPR Omron differential encoder on both my project machine and my mill. Those are both x86 Linuxcnc/Mesa machines though the project machine is the candidate for MK. Actually I hadn't realized that the MK socfpga component did not implement the mesa encoder interface, I didn't plan on running the software hal encoder component. Do you know if anyone is working on porting the HM2 encoder interface to socfpga? Were you planning on using the HAL encoder component?

[mib.hol...@gmail.com]

>> Were you planning on using the HAL encoder component?

Nope :-)

I have just completed adding the missing parts in the DExx.._Cramps Quartus projects and added a new encoder config.

Right now im running a Docker build before getting ready to commit my changes.... Since It is late late night here (I'm gointg to bed now):

I attach the *.rbf file and the Pin fil in which you can see which pins are used on the 2 GPIO ports.

the encoder inputs are on the second port (gpio_1).

change the fdtfile name to: DE10_Nano_FB_Cramps.3x24_cap_enc.rbf

in uboot and  

Happy testing:

 

Best wishes Michael B.

[mib.hol...@gmail.com]

Ups a little bit hasty there:

not the fdtfile variable but:

place the attached *.rbf file in: /lib/firmware/socfpga and (you can also alter u-boot variables from a linux console)

sudo fw_setenv bitimage '/lib/firmware/socfpga/DE10_Nano_FB_Cramps.3x24_cap_enc.rbf'

then reboot

[justin White]

Awesome, thanks that gets one issue of me trying to figure out what's going on out of the way lol. 

That's a good starting point because all I really need is one instance of each pin/interface type for now. I'm slightly confused about the .vhd file yet though. I get that it's the pin descriptor file, but when I go  to layout the GPIO differently, is all that is required is for me to assign the pins in the new .vhd file. I'm not quite sure what to do with the vhd file either at the moment, does it got loaded from the hal file. Also any idea  why halshow fails to load from the Axis GUI? 

Also, I'm not 100% sure how the hm2 card bitfiles are configured for the encoder interface but I assumed the FPGA actually used 3 I/O pins for the encoder. On the Mesa cards you swap jumpers to change from differential to single ended type encoder. In that case I figured they used a differential receiver chip to for differential encoders and bypassed it with the jumpers when using a single ended encoder. I see that this .vhd file uses 2 I/O pins per channel for the encoder so I assume it is configured to accept the differential encoder directly. In the case of using a single ended encoder is it just a matter of using a single input per channel or would it need to be reconfigured? I also assume all GPIO has pullups enabled on the FPGA, so they need to sink to change state?

[mib.hol...@gmail.com]

On Friday, 3 May 2019 05:29:27 UTC+2, justin White wrote:

Awesome, thanks that gets one issue of me trying to figure out what's going on out of the way lol. 

Your welcome

 

That's a good starting point because all I really need is one instance of each pin/interface type for now. I'm slightly confused about the .vhd file yet though. I get that it's the pin descriptor file, but when I go  to layout the GPIO differently, is all that is required is for me to assign the pins in the new .vhd file. I'm not quite sure what to do with the vhd file either at the moment, does it got loaded from the hal file. Also any idea  why halshow fails to load from the Axis GUI? 

I attatched the .vhl fil just because I had'nt pushed my commit to github at that time. (It is used for compiling the .rbf bitfile only)

Rightnow that file is pushed to this folder here:

https://github.com/the-snowwhite/mksocfpga/tree/encoder_work/HW/hm2/config/DE10_Nano_FB_Cramps

If you look in the section beginning with:

    constant ModuleID : ModuleIDType :=(

    -- GTag             Version Clock           NumInst BaseAddr                    NumRegisters        Strides MultiRegs

you can see 2  encoder instances are specified:

  (QcountTag,     x"02",  ClockLowTag,    x"02",  QcounterAddr&PadT,          QCounterNumRegs,    x"00",  QCounterMPBitMask),

If you look in the section beginning with:

    constant PinDesc : PinDescType :=(

you can see the pins for the 2 encoders:

        IOPortTag & x"00" & QCountTag & QCountIdxPin,       --    I/O 41    GPIO_1 06   06      Encoder Z

        IOPortTag & x"00" & QCountTag & QCountQBPin,        --    I/O 42    GPIO_1 07   07      Encoder B

        IOPortTag & x"00" & QCountTag & QCountQAPin,        --    I/O 43    GPIO_1 08   08      Encoder A

        IOPortTag & x"01" & QCountTag & QCountIdxPin,       --    I/O 44    GPIO_1 09   09      Encoder Z

        IOPortTag & x"01" & QCountTag & QCountQBPin,        --    I/O 45    GPIO_1 10   10      Encoder B

        IOPortTag & x"01" & QCountTag & QCountQAPin,        --    I/O 46    GPIO_1 11   13      Encoder A

 

Also, I'm not 100% sure how the hm2 card bitfiles are configured for the encoder interface but I assumed the FPGA actually used 3 I/O pins for the encoder.

Yes

 

On the Mesa cards you swap jumpers to change from differential to single ended type encoder. In that case I figured they used a differential receiver chip to for differential encoders and bypassed it with the jumpers when using a single ended encoder.

The encoder core uses single ended inputs, differential encoder inputs I belive may be a built in HW feature on the Mesa boards.

 

I see that this .vhd file uses 2 I/O pins per channel for the encoder so I assume it is configured to accept the differential encoder directly. In the case of using a single ended encoder is it just a matter of using a single input per channel or would it need to be reconfigured?

No reconfiguration is needed as you have 2 x 3 single ended encoder inputs in that .rbf file

I also assume all GPIO has pullups enabled on the FPGA, so they need to sink to change state?

There is maybe some provision that works for enabling pull ups on individual fpga pins, let me follow up on that later.(right now no pullups active)

Currently I have found out that using 220 ohm pullups to 3.3V works just fine.

>>> Also any idea  why halshow fails to load from the Axis GUI? 

It may be easier to test the encoder function without a GUI, try running these commands from a linux console (copy paste):

halrun

loadrt hostmot2

newinst hm2_soc_ol hm2-socfpga0 already_programmed=1 -- config="num_pwmgens=1 num_stepgens=4 num_encoders=1 enable_adc=1" debug=1

loadrt threads name1=test-thread period1=1000000

addf hm2_5i25.0.read         test-thread

addf hm2_5i25.0.write        test-thread

start

Then open a different console and paste this:

halcmd show pin  hm2_5i25.0.encoder.00

turn your connected encoder (with manual pullups)

and repeat the "reading"

halcmd show pin  hm2_5i25.0.encoder.00

[Charles Steinkuehler]

On 5/2/2019 10:29 PM, justin White wrote:
> I'm not quite sure what to do with the vhd
> file either at the moment, does it got loaded from the hal file. Also any
> idea why halshow fails to load from the Axis GUI?

The VHD files are VHDL code describing the logic inside the FPGA.
This code gets compiled by the vendor tool-chain and turned into a
configuration file used to program the FPGA.

You asked earlier about HM2 to support encoder interfaces. The HM2
driver already supports all the different types of logic currently
implemented in the FPGA, including encoder, stepgen, pwm, smart
serial, etc. To get an encoder to show up, just program the FPGA with
an appropriate configuration file and the HM2 driver will detect the
encoder instances.

It sounds like Michael is helping you with an appropriate FPGA
configuration.

--
Charles Steinkuehler
cha...@steinkuehler.net

[mib.hol...@gmail.com]

About using internal pull-ups in the fpga:

https://electronics.stackexchange.com/questions/248248/altera-fpga-i-o-weak-pull-ups

The Cyclone V family only has a 25Kohm (weak) internal pull-up resistor that can be enabled:

https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/hb/cyclone-v/cv_51002.pdf

Not usable for this purpose I think.

[justin White]

OK, now I'm getting somewhere

The encoder core uses single ended inputs, differential encoder inputs I belive may be a built in HW feature on the Mesa boards.

It is, I just wasn't sure how it was setup in the bitfile. I looked at a bitfile  from mesa with 1x3 encoder inputs, so yeah, nothing changes there. I have a DIP package  differential line receiver that I breadboarded up with the nano and  the differential encoder and I'm able to get the encoder counting on the nano. I can't find my single ended cheapo encoder at the moment but that should be more straight forward anyway. I just realized the encoder you mentioned you ordered was the single ended version.

Currently I have found out that using 220 ohm pullups to 3.3V works just fine.

That seems like a rather strong pullup. I've been testing 4.7k pullups/pulldowns since it's a pretty typical value for microcontrollers and they seem to work fine. It's possible that 4.7k might be a bit sluggish but I won't know til later. I'm seeing that the HM2 GPIO  pins go true when pulled up and false when pulled down. The "not" pins are obviously there but it now seems a bit more intuitive to actually pull them down and use high logic to activate the inputs. I'm sure it's just the way hm2 is configured. Thoughts on that?

It may be easier to test the encoder function without a GUI, try running these commands from a linux console (copy paste):

Halrun/halcmd works but I find Halshow to be a bit more intuitive since it's graphical and I can just load up a watchlist. I tried loading halshow in basically the same way you mentioned with the separate terminal instance after loading the RT components and threads and I get a segfault. My programmer buddy might be able to look into that but halcmd will work for now. 

About using internal pull-ups in the fpga:

https://electronics.stackexchange.com/questions/248248/altera-fpga-i-o-weak-pull-ups

The Cyclone V family only has a 25Kohm (weak) internal pull-up resistor that can be enabled:

https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/hb/cyclone-v/cv_51002.pdf

Not usable for this purpose I think.

Yeah, being that weak they would be pretty sluggish I would think. They are likely just onboard to keep unused pins from floating. I would think in the case of something like this it's probably best they are left off since hm2 is reconfigurable. It is good to know the state though since they can cause issues with voltage dividers and such if not accounted for.

 

The VHD files are VHDL code describing the logic inside the FPGA. 
This code gets compiled by the vendor tool-chain and turned into a 
configuration file used to program the FPGA. 

You asked earlier about HM2 to support encoder interfaces.  The HM2 
driver already supports all the different types of logic currently 
implemented in the FPGA, including encoder, stepgen, pwm, smart 
serial, etc.  To get an encoder to show up, just program the FPGA with 
an appropriate configuration file and the HM2 driver will detect the 
encoder instances. 

Charles,

I haven't really done anything with Quartus yet so bear with me. Searching for this specific answer I haven't really found anything. 

The hm2 .vhd file (and presumeably other .vhd files) are part of building the .rbf file in Quartus correct? So if I wanted to apply a different pin configuration I would re-write this .vhd file and apply it in Quartus to build the new .rbf, is that correct?

I'll look into the specifics of doing it when the time comes, I'm just trying to get the gyst of how that works.

[Charles Steinkuehler]

On 5/4/2019 11:03 AM, justin White wrote:
>
> Charles,
> I haven't really done anything with Quartus yet so bear with me. Searching
> for this specific answer I haven't really found anything.
>
> The hm2 .vhd file (and presumeably other .vhd files) are part of building
> the .rbf file in Quartus correct? So if I wanted to apply a different pin
> configuration I would re-write this .vhd file and apply it in Quartus to
> build the new .rbf, is that correct?
>
> I'll look into the specifics of doing it when the time comes, I'm just
> trying to get the gyst of how that works.

Short answer...it's complicated. :)

This might help get you started, it's a presentation I gave at one of
the Machinekit meetups regarding the SoC+FPGA stuff:
https://www.youtube.com/watch?v=veM83KCytuQ

Basically, if you want to customize something, you need to create a
new config or modify an existing one. The existing configs are found
here:

https://github.com/machinekit/mksocfpga/tree/master/HW/hm2/config

...and the PIN_*.vhd file is where the "magic" happens. The rest of
the design will elaborate and instantiate the logic defined in the PIN
file. So you edit/create an appropriate PIN file, then make sure your
FPGA project uses *that* PIN file when building.

--
Charles Steinkuehler
cha...@steinkuehler.net

[mib.hol...@gmail.com]

On Saturday, 4 May 2019 18:03:51 UTC+2, justin White wrote:

OK, now I'm getting somewhere

The encoder core uses single ended inputs, differential encoder inputs I belive may be a built in HW feature on the Mesa boards.

It is, I just wasn't sure how it was setup in the bitfile. I looked at a bitfile  from mesa with 1x3 encoder inputs, so yeah, nothing changes there. I have a DIP package  differential line receiver that I breadboarded up with the nano and  the differential encoder and I'm able to get the encoder counting on the nano. I can't find my single ended cheapo encoder at the moment but that should be more straight forward anyway. I just realized the encoder you mentioned you ordered was the single ended version.

Wonder which human readable file you are refering to as the bitfiles are the binaries (*.rbf) generated by quartus from the *.vhd and *.sv, *.v source files...

 

Currently I have found out that using 220 ohm pullups to 3.3V works just fine.

That seems like a rather strong pullup. I've been testing 4.7k pullups/pulldowns since it's a pretty typical value for microcontrollers and they seem to work fine. It's possible that 4.7k might be a bit sluggish but I won't know til later. I'm seeing that the HM2 GPIO  pins go true when pulled up and false when pulled down. The "not" pins are obviously there but it now seems a bit more intuitive to actually pull them down and use high logic to activate the inputs. I'm sure it's just the way hm2 is configured. Thoughts on that?

I'm no electronics expert... The datasheet for my single ended encoder says max 30 mA, so I figured 220 ohm at 3.3volts gives max 15mA or so...

 

It may be easier to test the encoder function without a GUI, try running these commands from a linux console (copy paste):

Halrun/halcmd works but I find Halshow to be a bit more intuitive since it's graphical and I can just load up a watchlist. I tried loading halshow in basically the same way you mentioned with the separate terminal instance after loading the RT components and threads and I get a segfault. My programmer buddy might be able to look into that but halcmd will work for now. 

If your FULL error message is:

halshow
halsh: FATAL - 'MACHINEKIT_INI' missing in environment
Segmentation fault

then try doing:

export MACHINEKIT_INI=/etc/linuxcnc/machinekit.ini

I had to do some more to get it to run via a ssh -XY .... console, however I'm also running the newer

machinekit-hal-rt-preempt

machinekit-cnc-rt-preempt

 

packages

[justin White]

Wonder which human readable file you are refering to as the bitfiles are the binaries (*.rbf) generated by quartus from the *.vhd and *.sv, *.v source files...

Was talking about Mesa's .vhd files. 

 I'm no electronics expert... The datasheet for my single ended encoder says max 30 mA, so I figured 220 ohm at 3.3volts gives max 15mA or so...

That would be the current handling ability of the encoder's outputs, but all you have to do is drive an FPGA pin. That takes almost no current to do. Since you want to make sure that that FPGA pin has a defined state when it's not being driven you need to pull it toward one side with a resistor. If you use a strong pullup/down it requires more current to drive it toward the other side. The 15mA is being wasted through that resistor. 15mA isn't a big deal but if you have alot of I/O it'll add up.

If your FULL error message is:

 It literally just prints out "segmentation fault". I just tried it on one of my other Linuxcnc machines and if LinuxCNC is running, I can open a new terminal and cd to the halshow.tcl directory and ./ to execute it just as if I started it in the GUI. That doesn't work on this image even after using the export command you mentioned. I'll have to try updating the packages you mentioned and see if that helps.

I'm still trying to find some info on some of the "tags" used in the hm2 vhd files, I don't suppose this is documeted somewhere?

 I see the "capsense" tags but I'm not sure what that is, something Cramps related? 

Some of the Mesa PWM implementations are a 3 pin deal with an enable and direction pin. The MK configs only seem to use the "PWMAOutPin" per unit. Looking at a top level vhd file it appears that the PWMBDirPin, and PWMCEnaPin are there. I suppose it's just a matter of including these pins in that unit?

There is a NANOADCTag listed in the ModuleIDs but I haven't found any usage of it other than that. Is that just a placeholder or does it have an implementation?

[mib.hol...@gmail.com]

On Monday, 6 May 2019 19:32:47 UTC+2, justin White wrote:

Wonder which human readable file you are refering to as the bitfiles are the binaries (*.rbf) generated by quartus from the *.vhd and *.sv, *.v source files...

Was talking about Mesa's .vhd files. 

 I'm no electronics expert... The datasheet for my single ended encoder says max 30 mA, so I figured 220 ohm at 3.3volts gives max 15mA or so...

That would be the current handling ability of the encoder's outputs, but all you have to do is drive an FPGA pin. That takes almost no current to do. Since you want to make sure that that FPGA pin has a defined state when it's not being driven you need to pull it toward one side with a resistor. If you use a strong pullup/down it requires more current to drive it toward the other side. The 15mA is being wasted through that resistor. 15mA isn't a big deal but if you have alot of I/O it'll add up.

Sure the 220 ohms are just for initial test purposes and to make certain I dont pickup noise as I'm running a 2 meter cable from the encoder to the soc.

 

If your FULL error message is:

 It literally just prints out "segmentation fault". I just tried it on one of my other Linuxcnc machines and if LinuxCNC is running, I can open a new terminal and cd to the halshow.tcl directory and ./ to execute it just as if I started it in the GUI. That doesn't work on this image even after using the export command you mentioned. I'll have to try updating the packages you mentioned and see if that helps.

you cannot update directly to the -cnc -hal machinekit packages I think... best way is to remove the old packages with 

sudo apt purge  then

sudo apt autoremove

You may get some complaints (when installing the new packages) about yapps, when installing solution is to uninstall/purge that package also.

I'm still trying to find some info on some of the "tags" used in the hm2 vhd files, I don't suppose this is documeted somewhere?

Have you whached the presentation Charles linked to ?

 

 I see the "capsense" tags but I'm not sure what that is, something Cramps related?

Capsense is a new touch sensor core I have added not mesa related..(You can safely ignore that).

 

 

Some of the Mesa PWM implementations are a 3 pin deal with an enable and direction pin. The MK configs only seem to use the "PWMAOutPin" per unit. Looking at a top level vhd file it appears that the PWMBDirPin, and PWMCEnaPin are there. I suppose it's just a matter of including these pins in that unit?

As Charles stated earlier this is complicated stuff to understand and the options are vast.

You have to be more verbose as to what you are aiming to get up and running. I only have the info you have provided in this thread and I have no idea of what your goal is.

There is a NANOADCTag listed in the ModuleIDs but I haven't found any usage of it other than that. Is that just a placeholder or does it have an implementation?

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.

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.

Best wishes

Michael Brown 
 

[Charles Steinkuehler]

On 5/6/2019 4:42 PM, mib.hol...@gmail.com wrote:
> On Monday, 6 May 2019 19:32:47 UTC+2, justin White wrote:
>
> I'm still trying to find some info on some of the "tags" used in the hm2
>> vhd files, I don't suppose this is documeted somewhere?
>>
> Have you whached the presentation Charles linked to ?

In addition to the recorded presentation, you can get the slides I
used from github:

https://github.com/cdsteinkuehler/Presentations/tree/master/2017.04.29.Machinekit_Meetup

--
Charles Steinkuehler
cha...@steinkuehler.net

[justin White]

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.

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.

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.

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

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

[mib.hol...@gmail.com]

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:

Later you could possibly move the image detection into the fpga fabric:

https://rocketboards.org/foswiki/Projects/SoCLicensePlateRecognition

Just an example...

 

[justin White]

When you are laying out your own custom DExx interface board, you don't have to stay restricted to allready made pinouts.

Yeah that I know,  Like I said, I was mostly trying to determine how many pins each tag type used and it's actual usage. I was a bit hung up on the ADC thing because it didn't directly correspond with the pin tags but now I realize it's an SPI interface.

I'll have to come back to all of the above info once I try to create the new FPGA project files, for now I think I get the idea.

Purging the installed Machinekit packages and installing the new ones as you suggested got HALshow working right away. 

I've pretty much got my encoder interface and output hardware sorted, I use 24v I/0 but it should handle multiple voltages.

[Michael Brown]

Ok

Great to hear you have progress.

On a side note:

I managed to find the bug in the ADC system and the fix got out into the socfpga-rbf deb yesterday.... :-=)  

[justin White]

Got another silly question....

Is it possible to invert the default state of the GPIO pins? I've found that pulling them up will bring them true, Hardware wise the easiest way I've found to make the inputs capable of handling multiple input voltages will require them to be pulled down when activated, so I'd have to pull them up to a "false" state. This would only be something I need to do with the gpio inputs.

[Charles Steinkuehler]

hostmot2 has both in and in_not pins, just use the one appropriate for
your wiring. There is also an invert_output parameter if you need to
invert the output signal:

http://www.machinekit.io/docs/man/man9/hostmot2/#general-purpose-i-o

--
Charles Steinkuehler
cha...@steinkuehler.net

[justin White]

I'm aware of the "not" hal pins but I'm not really a huge fan of using them on the daughter card as it's not very intuitive. They're better for an end use case if there's an individual input that has an inverted logic. I was hoping this could be changed at the driver level.

[Michael Brown]

It sounds to me like you are takling about opendrain:

https://github.com/the-snowwhite/mksocfpga/blob/master/HW/QuartusProjects/Common/gpio_adr_decoder_reg.sv#L33

If you want this functionality for inputs you have to use the 

active high:

net limit-x-min <= hm2_[HOSTMOT2](BOARD).0.gpio.010.in

active low:

net limit-x-min <= hm2_[HOSTMOT2](BOARD).0.gpio.010.in_not

[justin White]

Put the Machinekit setup stuff to the side for a bit to get a PCB going. Got some boards getting fabbed and some components on the way.

[ce...@tuta.io]

Jun 11, 2019, 12:53 AM by blaz...@gmail.com:

> Put the Machinekit setup stuff to the side for a bit to get a PCB going. Got some boards getting fabbed and some components on the way.
>
>
>
>
>

Is some open-source project lurking in this image?

Cern.

>
> On Sunday, May 12, 2019 at 10:00:18 AM UTC-4, Michael Brown wrote:
>
>> It sounds to me like you are takling about opendrain:

>> https://github.com/the->> snowwhite/mksocfpga/blob/>> master/HW/QuartusProjects/>> Common/gpio_adr_decoder_reg.>> sv#L33 <https://github.com/the-snowwhite/mksocfpga/blob/master/HW/QuartusProjects/Common/gpio_adr_decoder_reg.sv#L33>

>>
>> If you want this functionality for inputs you have to use the 
>>
>> active high:
>>
>>
>>

>> net limit-x-min <= hm2_[HOSTMOT2](BOARD).>> 0.gpio.>> 010.in <http://0.gpio.010.in>

>> active low:
>>
>>
>>
>>
>> net limit-x-min <= hm2_[HOSTMOT2](BOARD).0.gpio.>> 010.in_not
>>
>>
>>
>> On Sunday, 12 May 2019 13:21:46 UTC+2, justin White wrote:
>>
>>> Got another silly question....
>>>
>>> Is it possible to invert the default state of the GPIO pins? I've found that pulling them up will bring them true, Hardware wise the easiest way I've found to make the inputs capable of handling multiple input voltages will require them to be pulled down when activated, so I'd have to pull them up to a "false" state. This would only be something I need to do with the gpio inputs.
>>>
>>> On Friday, May 10, 2019 at 6:40:30 PM UTC-4, Michael Brown wrote:
>>>
>>>> Ok
>>>> Great to hear you have progress.
>>>>
>>>> On a side note:
>>>> I managed to find the bug in the ADC system and the fix got out into the socfpga-rbf deb yesterday.... :-=)  
>>>>
>>>> On Friday, 10 May 2019 22:26:13 UTC+2, justin White wrote:
>>>>
>>>>>> When you are laying out your own custom DExx interface board, you don't have to stay restricted to allready made pinouts.
>>>>>>
>>>>> Yeah that I know,  Like I said, I was mostly trying to determine how many pins each tag type used and it's actual usage. I was a bit hung up on the ADC thing because it didn't directly correspond with the pin tags but now I realize it's an SPI interface.
>>>>>
>>>>> I'll have to come back to all of the above info once I try to create the new FPGA project files, for now I think I get the idea.
>>>>>
>>>>> Purging the installed Machinekit packages and installing the new ones as you suggested got HALshow working right away. 
>>>>>
>>>>> I've pretty much got my encoder interface and output hardware sorted, I use 24v I/0 but it should handle multiple voltages.
>>>>>
>
>
>

> --
> website: > http://www.machinekit.io <http://www.machinekit.io>> blog: > http://blog.machinekit.io <http://blog.machinekit.io>> github: > https://github.com/machinekit <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 > machinekit+...@googlegroups.com <mailto:machinekit+...@googlegroups.com>> .
> Visit this group at > https://groups.google.com/group/machinekit <https://groups.google.com/group/machinekit>> .
> To view this discussion on the web visit > https://groups.google.com/d/msgid/machinekit/a53d1e3f-7211-4380-9186-edfe806f2635%40googlegroups.com <https://groups.google.com/d/msgid/machinekit/a53d1e3f-7211-4380-9186-edfe806f2635%40googlegroups.com?utm_medium=email&utm_source=footer>> .
> For more options, visit > https://groups.google.com/d/optout <https://groups.google.com/d/optout>> .
>

[justin White]

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'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.

>  To unsubscribe from this group and stop receiving emails from it, send an email to > machi...@googlegroups.com <mailto:machinekit+unsub...@googlegroups.com>> .

[Bas de Bruijn]

> On 11 Jun 2019, at 01:25, justin White <blaz...@gmail.com> 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.

[justin White]

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.

[justin White]

No smoke yet.

[justin White]

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.

[Charles Steinkuehler]

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.

--
Charles Steinkuehler
cha...@steinkuehler.net

[Michael Brown]

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. 

[Michael Brown]

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

[Michael Brown]

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 (With your naming convention),

and customize it if you fell so inclined..... then it should build.

Best Wishes

Michael Brown

[justin White]

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

[Charles Steinkuehler]

On 6/16/2019 3:24 PM, 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!

This warning is benign and may be safely ignored.

--
Charles Steinkuehler
cha...@steinkuehler.net

[Charles Steinkuehler]

On 6/16/2019 11:31 AM, 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

Sorry...I was on vacation and very much off-line the last two weeks.

Merged.

--
Charles Steinkuehler
cha...@steinkuehler.net

[Michael Brown]

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 :-)

[Michael Brown]

I had a hunch being this time of year.. Thanks for your quick assesment

Best wishes Michael B.

 

[justin White]

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" 

[justin White]

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?

[Charles Steinkuehler]

If you want to create an overlay you need to use the -@ command line
switch with dtc.

>>>>> <http://www.google.com/url?q=http%3A%2F%2Fatlas_st_fpga_soc_dc1.sv&sa=D&sntz=1&usg=AFQjCNFaXzIhSaX4akk6lI9iwZh_k2ltVA>

--
Charles Steinkuehler
cha...@steinkuehler.net

[justin White]

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?

[Michael Brown]

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 ?

[justin White]

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?

[Michael Brown]

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 ?

[justin White]

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.

[justin White]

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.

 

[Michael Brown]

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...

[justin White]

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.

[Michael Brown]

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 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 

[justin White]

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?

[Michael Brown]

On Thursday, 4 July 2019 02:17:04 UTC+2, justin White wrote:

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?

Seems like all the infrastructure is in place, copy/overwrite the sserial tags into your pin custom file and compile the .rbf.

Looks like it will then auto probe the rs422 connected connected 8i20 on hm2 driver load.

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?

I have no experience with rs422 or rs485, but i guess yes....

[Charles Steinkuehler]

On 7/7/2019 4:29 AM, Michael Brown wrote:
> 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?
>
> I have no experience with rs422 or rs485, but i guess yes....

RS-422 is always differential. It may be full duplex (which only
requires TX and RX) or half duplex (which adds a TX-Enable signal).

The 7i76 daughtercard requires two SSERIAL channels, one for the 7i76
itself (for the Field I/O signals), and one which gets exported via
the TB3 connector.

Both buses are full duplex and do not require a TX-Enable signal.

The SSERIAL communication between the FPGA and the 7i76 is via
standard digital logic levels. The 7i76 provides an RS-422
transceiver for the SSERIAL bus on TB3.

--
Charles Steinkuehler
cha...@steinkuehler.net

[justin White]

On Sunday, July 7, 2019 at 5:29:40 AM UTC-4, Michael Brown wrote:

Seems like all the infrastructure is in place, copy/overwrite the sserial tags into your pin custom file and compile the .rbf.
Looks like it will then auto probe the rs422 connected connected 8i20 on hm2 driver load.

That's good to know. I'll give it a whirl on the next iteration.

On Sunday, July 7, 2019 at 7:50:21 AM UTC-4, Charles Steinkuehler wrote:

RS-422 is always differential.  It may be full duplex (which only 
requires TX and RX) or half duplex (which adds a TX-Enable signal). 
The 7i76 daughtercard requires two SSERIAL channels, one for the 7i76 
itself (for the Field I/O signals), and one which gets exported via 
the TB3 connector. 
Both buses are full duplex and do not require a TX-Enable signal. 
The SSERIAL communication between the FPGA and the 7i76 is via 
standard digital logic levels.  The 7i76 provides an RS-422 
transceiver for the SSERIAL bus on TB3. 

 I asked a similar question over on the LCNC forums and PCW confirmed it's just straight RS-422. The 7i76 was probably a bad example, the LBP section of the manual for the (e) version confirms what you said about it communicating with it's own I/O section over SSerial, I just want to slap the single SSerial channel on the board. Not sure about the termination resistor, I usually see it suggested on the Rx line but the datasheet for the transceiver I'm looking at suggests termination on the driver as well. Any thoughts on the attached drawing?

Thanks for the help guys.

 

[Charles Steinkuehler]

On 7/7/2019 12:22 PM, justin White wrote:
> I asked a similar question over on the LCNC forums and PCW confirmed it's
> just straight RS-422. The 7i76 was probably a bad example, the LBP section
> of the manual for the (e) version confirms what you said about it
> communicating with it's own I/O section over SSerial, I just want to slap
> the single SSerial channel on the board. Not sure about the termination
> resistor, I usually see it suggested on the Rx line but the datasheet for
> the transceiver I'm looking at suggests termination on the driver as well.
> Any thoughts on the attached drawing?

There's good info in the data sheet for that part:
http://www.ti.com/lit/gpn/thvd1451

...which is an RS-485 transceiver (RS-485 is the same electrically as
RS-422, but the driver can be switched off).

RS-485 is a "multi-drop" protocol, and supports multiple transceivers.
Typically, the end nodes will have termination resistors populated
and the devices in the middle on the cable will have the termination
disabled. See figure 32 (page 22) in the data sheet.

PCW said it's straight RS-422, not RS-485. That means you only have
two devices making each device an end point, so add termination to
both ends.

The ESD protection is application dependent, but you might also want
a small value series resistor between the THVD1451 and the cable (see
Figure 38, page 27 along with the recommend parts list) and see the
layout recommendations on page 29.

...but don't sweat the details too much. For a short range (a few
meters) point-to-point connection, the ESD and even the termination
resistors are not super important. I'd still add them (it's cheap
insurance!), but I don't expect you're designing for 1.5 km long
cables that need to withstand nearby lightning strikes. :)

That said, spindle motors can throw off enough ESD to cause problems
even with differential signals, which is why you want _something_.

--
Charles Steinkuehler
cha...@steinkuehler.net

[justin White]

On Sunday, July 7, 2019 at 2:16:22 PM UTC-4, Charles Steinkuehler wrote:
There's good info in the data sheet for that part: http://www.ti.com/lit/gpn/thvd1451 
...which is an RS-485 transceiver (RS-485 is the same electrically as 
RS-422, but the driver can be switched off). 
RS-485 is a "multi-drop" protocol, and supports multiple transceivers. 
Typically, the end nodes will have termination resistors populated 
and the devices in the middle on the cable will have the termination 
disabled.  See figure 32 (page 22) in the data sheet. 
PCW said it's straight RS-422, not RS-485.  That means you only have 
two devices making each device an end point, so add termination to 
both ends. 

That's kind of unfortunate because you'd need a separate channel for each device. Now my head is spinning again because my encoders and stepgens are differential recievers/drivers so I could technically pretty much just repurpose one of each and get a couple of channels out of one set of connectors. I didn't put any impedance control or TVS on them but now I'm thinking if I make some accommodations I can just sacrifice encoders and stepgens for serial channels.

The ESD protection is application dependent, but you might also want 
a small value series resistor between the THVD1451 and the cable (see 
Figure 38, page 27 along with the recommend parts list) and see the 
layout recommendations on page 29. 

 

...but don't sweat the details too much.  For a short range (a few 
meters) point-to-point connection, the ESD and even the termination 
resistors are not super important.  I'd still add them (it's cheap 
insurance!), but I don't expect you're designing for 1.5 km long 
cables that need to withstand nearby lightning strikes.  :) 
That said, spindle motors can throw off enough ESD to cause problems 
even with differential signals, which is why you want _something_. 

I just whipped the drawing up this morning, I was originally going to use a different chip and had a different drawing. Good to know it's on the right track though.

tvs and esd are somewhat of a concern since while I didn't really intend it, I can pretty much replace the x86 PC and 7i76e on my mill with this. In that case I use an 8i20 for my spindle with a power supply that consists of some big caps, a couple of SSRs and a bridge rectifier. There's 240v AC going into that box 320v DC coming out. While I shielded all cables, a little protection on the data lines is probably a good idea. Not sure of the performance of the DE10 Nano itself just yet since I just load up an Axis config and fire up halshow for the time being. Unless I converted my mill I probably wouldn't have an actual machine to run on this any time soon.

Every time I think I'm damn near done with it I come up with something else to complicate things lol.

[justin White]

So another thought is that since there is a Tx enable in the hm2 module it's obviously there for a reason. rs485 is always emphasized but rs485 is mentioned in alot of cases as well. In the case of an 8i20 it includes jumpers to enable bus termination resistors. So I'm wondering if using the Tx enable on the driver would technically make it rs485 so you could run multiple devices like 8i20s or smbl drives on one channel. There could be other considerations like latency issues or something, just curious if that would work.

[Michael Brown]

Well test it and commit you results back??? 

--
website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit
---
You received this message because you are subscribed to a topic in the Google Groups "Machinekit" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/machinekit/eVhvTnuhblE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to machinekit+...@googlegroups.com.
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/6df1fef2-f29b-4019-b58e-0b6492a07be5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Michael Brown]

Wondering about commenys

On Thu, 2 May 2019, 17.02 <mib.hol...@gmail.com> wrote:

Hi Justin

The DE10_Nano_FB_Cramps.3x24_cap.rbf bitfile is as the name implies designed to interface with a Cramps board and provide a framebuffer onthe hdmi pins of the DE10 Nano.

I have created an Interface board for interfacing the DExx Nano (soc) boards to the Cramps and

the design files are here: 

https://github.com/the-snowwhite/socfpga-kicad/tree/master/Cramps2nano-soc

https://github.com/the-snowwhite/socfpga-kicad/blob/master/Cramps2nano-soc/Cramps2Nano.pdf

This shows the pins of the DExx Gpio pins and can be easiely bread boarded.

The cap sensor is not part of Cramps functionality so these pins are not on that schematic...

--

About the  "SOC-no-fw-load" config method:

This makes Machinekit not reprogram the fpga when MACHINEKIT starts... correct

The  "fpgaload_on_boot 1" in u-boot makes u-boot program the fpga BEFORE linux starts up so that the Framebuffer then can be picked up,

Ensure that the right devicetree (the one with framebuffer enabled) is loaded by u-boot.

Really I'm just looking to breadboard an encoder interface and level shifting circuits and get some feedback from MK as to how the GPIO is responding at this point

 Coincendentially I have just purchased an encoder:

E6B2-CWZ6C

And will be doing the same exercise currently it seems... :-)

While it may be possible to hook up this encoder to some gpio pins and then run a "soft" encoder in the hal,

the Mesa Hostmot2 cores do provide Encoder cores that can be run in the fpga HW fabric, this meens a new config has to be added to the DE10_Nanoxxx_FBxxxx Quartus project in the Mksocfpga repo

http://www.machinekit.io/docs/drivers/hostmot2/#encoder

On Wednesday, 1 May 2019 04:33:52 UTC+2, justin White wrote:

So I picked up a DE10 Nano to do some testing on. As I explained in a previous thread, a remote GUI running on a different CPU is the intended goal with the DE10-Nano handling MK and the hardware headless as I'm sure most would intend it's use. I'm having all sorts of issues with just about everything MachineKit but this I got somewhere with.

I need to work on making an interface board to get useable I/O out of this thing for my intended purpose. I found the "DE10-Nano/mksocfpga_stretch_machinekit_4.9.76-2018-05-26-de10_nano_desktop_sd.img" and got that setup with HDMI support and LXqt. The thought is that If I can get a working GUI setup going with a more or less generic bitfile I can basically breadboard the DE10-Nano and use HalShow and a few other LinuxCNC tools to verify the circuits. I ran into a couple of issues and there's some things I'm unsure of....

I tried what sounded like a more ideal bitimage but the HDMI output was no good unless I used the /lib/firmware/socfpga/DE10_Nano_FB_Cramps.3x24_cap.rbf bitimage. I couldn't find info on what the pin designations for this image are, I'm not really up to snuff on the 3D-printer/CRAMPS thing. I'm not really sure of how to create my own bitfile either especially if it's tied to the HDMI out.

I did load MK and the only stock config I could get to load was the something "SOC-no-fw-load"  config. I assume this does not reprogram the FPGA on start since the "fpgaload_on_boot 1" variable is set to program the FPGA on boot? Since I have no hardware to attach I can't really say whether the I/O was actually doing anything although I guess I would expect following errors or something if it wasn't while I was jogging around. I also couldn't start Halshow from the Axis GUI, just didn't open. It'd be great if somebody could point me in the right direction as to how I can either setup my own hardware bitfile or use a rather generic one that I can reference pin designations too. Really I'm just looking to breadboard an encoder interface and level shifting circuits and get some feedback from MK as to how the GPIO is responding at this point. 

--
website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit
---
You received this message because you are subscribed to a topic in the Google Groups "Machinekit" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/machinekit/eVhvTnuhblE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to machinekit+...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.

[justin White]

I'm generating an rbf now for the lesser method of re-purposing a stepgen and encoder driver and reciever for RS422. Only testing method I have for this at the moment is to plug it into my mill's 8i20 and see if it auto discovers. I haven't gotten a board fabbed with a dedicated serial transceiver yet. PCW says the 8i20 (and I assume any fast SS device) dropped multidrop rs485 support and stuck with rs422 because of speed issues. I may still use an rs485 transceiver in my design because AFAIK smbl drives support rs485, not sure how well it works but I'm thinking about getting a few of those boards fabbed as well on the next order to play with.

So about all I'll know in short order is if SS works at all with rs422 on the DE10_Nano_FB config

On Saturday, July 13, 2019 at 10:52:00 AM UTC-4, Michael Brown wrote:

Wondering about commenys

To unsubscribe from this group and all its topics, send an email to machi...@googlegroups.com.

[justin White]

I can't get a working bitimage out of this .vhd, builds but fails to fully boot after setting the environment. Using the attached .vhd with the renamed "atlas_3x24_cap_enc.sv" with this, but I see it doesn't have any SS parameters.

BTW any way to recover from setting the firmware environment with a bad bitimage? I've just been restoring a backup image to the SD card, this is the first time I've had a bitimage fail like this.

[Michael Brown]

Ok :) 

To unsubscribe from this group and all its topics, send an email to machinekit+...@googlegroups.com.

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/8eef1882-e527-4ad8-a5df-54c6a53c0c10%40googlegroups.com.

[justin White]

Any insight on the issue with the rbf?

[justin White]

There was something wrong with my build environment, deleted it and I was able to get a good .rbf.

I wasn't able to get this working with my 8i20 though. I added "sserial_port_0=00xxxx" to the config line as in my other sserial configs.

I'll probably hold off on anymore testing until I get a board fabbed with dedicated serial hardware, but the firmware could probably use some looking into.

[justin White]

I used 2 instances of SSerial in the pinfile which was incorrect. I'm told 1 instance covers 8 SSerial channels. I built a new .rbf with 1 instance and still couldn't get it to work. PCW confirms that the encoder/stepgen thing should work just fine so I'm pretty much out of ideas.

On a side note, how might I go about changing the framebuffer resolution to the HDMI? Only certain monitors will display anything from the DE10 which makes it kind of a PIA to test this as I have to drag another monitor down to my mill since my mill's monitor wont display the Nano. The way it's achieving a resolution doesn't seem standard as no standard method of changing it from 1024x768 seems to work. 

[Charles Steinkuehler]

Got a link to your pin file for review?

--
Charles Steinkuehler
cha...@steinkuehler.net

[justin White]

Same as attached on july 13 except I changed SS numinst to 1.

[Charles Steinkuehler]

From what I know your pin file looks OK, but I'm not an expert on SSerial.

Can you need to expand a bit on "still couldn't get it to work". The
hm2 driver will automatically look for and create HAL pins for any
SSerial devices it finds, but the far end needs to be powered up and
responding to SSerial communication when the driver loads for this to
happen (eg: the field I/O on the 7i76).

So if the FPGA hardware is OK, you should see some communication on
the SSerial lines when the hm2 driver loads.

>> cha...@steinkuehler.net <javascript:>
>>
>


--
Charles Steinkuehler
cha...@steinkuehler.net

[justin White]

Charles, is there any way to see that SSerial is actually running? Typically when you start LinuxCNC from terminal Hm2 will print the sserial version running first. I can’t see this by starting a config with Machinekit. I tried launching a basic source file and manually loadrt from halrun but the differences are such that I couldn’t figure out how to loadrt hm2_soc_ol with any config options. I’m not sure if the “atlas_....sv” file needs a modification. For smart serial, like I said I’m just using the same renamed 3x24.sv I’ve been using.

By “not work” i mean when starting MK plugged into the 8i20 from my mill I get no hm2_5i25.0.8i20...... pins as I would with the 8i20 plugged into the 7i76e/x86 pc installed on the mill. I didn’t have any issues with the cable, connection I made for that and this is pretty much exactly the same.

I’ve checked all my connections but I certainly wouldn’t rule out that I missed something. It’d be great if I could find some evidence that either sserial is actually running or that the hardware isn’t communicating anything at all, like some sort of serial terminal where I could at least check for some sort of handshake process.

[Charles Steinkuehler]

I _think_ the debugging will get output to the log file if you launch
with something like DEBUG=5.

I don't think you need to pass any parameters to the hm2_soc_ol
driver, it's the hm2 module that takes things like the sserial= option.

IIRC, with full debugging turned on, you'll get a dump with quite a
bit of detail as the hm2 driver launches and starts auto-probing the
hardware to see what's configured.

--
Charles Steinkuehler
cha...@steinkuehler.net

[Michael Brown]

Monitor resolution is fixed. Changes are done in the qsys video frame buffer cores. 

--

website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit
---
You received this message because you are subscribed to a topic in the Google Groups "Machinekit" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/machinekit/eVhvTnuhblE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to machinekit+...@googlegroups.com.
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/a35860c4-494e-4daa-8d65-5ed926dbc0af%40googlegroups.com.

[Michael Brown]

Besides the 1024x768 (VESA) there are the HD,, (1920 x1080) configs. What missing screen resolution are you referring to?

[justin White]

On Sunday, July 21, 2019 at 2:27:10 PM UTC-4, Michael Brown wrote:

Besides the 1024x768 (VESA) there are the HD,, (1920 x1080) configs. What missing screen resolution are you referring to?

I  Haven't seen the 1920x1080 config, I've just been building out of the "DE10_Nano_FB_Cramps" project, with the "PIN_3x24_cap_enc.vhd" modified pinfile. 

1600x900 would allow me to test it out on my mill and I might have a use for 800x480. I didn't realize the resolution was fixed, my 1080P monitors don't have a problem displaying 1024x768, all my other monitors do. I suppose in a real usage scenario I'd have to look further into your previous reply and try to figure out how to set a resolution for whatever monitor I intended to use.

For the Sserial thing, I did eventually get MK to dump a logfile that showed HM2 come up. SSerial is being initiated as far as that goes, it does print the version. I tried rigging up a Serial cable and sniffing the transmit line but the 2.5m baud rate that sserial claims is too high for anything I'm using to catch. With a scope I can catch the transmit line get pulled low for a very short period. PCW did mention this:

I still suspect a wiring error as the most like cause of non-detection of SSerial remotes,
but another possibility is an incorrect CLKMED value in the firmware source
(The baud rate calculations that the SSerial processor does depend on this constant
matching the actual CLKMED clock rate)

I've checked the wiring, and double checked the PCB traces against the datasheets and continuity to every solder joint everything looks fine. Later in the week I'll be able to test a better circuit but I'm not sure what to do about checking the clock rate.

[Charles Steinkuehler]

On 7/22/2019 1:01 AM, justin White wrote:
>
> For the Sserial thing, I did eventually get MK to dump a logfile that
> showed HM2 come up. SSerial is being initiated as far as that goes, it does
> print the version. I tried rigging up a Serial cable and sniffing the
> transmit line but the 2.5m baud rate that sserial claims is too high for
> anything I'm using to catch. With a scope I can catch the transmit line get
> pulled low for a very short period. PCW did mention this:
>
> I still suspect a wiring error as the most like cause of non-detection of
>> SSerial remotes,
>> but another possibility is an incorrect CLKMED value in the firmware source
>> (The baud rate calculations that the SSerial processor does depend on this
>> constant
>> matching the actual CLKMED clock rate)
>
> I've checked the wiring, and double checked the PCB traces against the
> datasheets and continuity to every solder joint everything looks fine.
> Later in the week I'll be able to test a better circuit but I'm not sure
> what to do about checking the clock rate.

The sure way to check is capture a few bytes being sent over the
serial port when the driver starts up. That will tell you the *REAL*
baud rate.

The "medium" clock rate is typically defined in the "card" VHDL file.
I'm not sure if there's one specifically for the DE10 or if it uses
the one for the DE0_Nano:

https://github.com/machinekit/mksocfpga/blob/master/HW/hm2/config/DE0_Nano_SoC_DB25/DE0_Nano_SoC_DB25_card.vhd#L73

The clock source also needs to match the frequency specified in the
above file. For the DE0_Nano, the 100 MHz medium clock is generated
by an HPS PLL:

https://github.com/machinekit/mksocfpga/blob/master/HW/QuartusProjects/DE0_Nano_SoC_DB25/DE0_Nano_SoC_DB25.vhd#L277

--
Charles Steinkuehler
cha...@steinkuehler.net

[justin White]

Charles,

Does the Clock rate specified in the pinfile for the module instance relate to the clock rate as it's set in the "card" file? Like I said the example I came across in MKSOCFPGA specified "ClockLowTag" for SS so that is what I used. I later tried building it with ClockMedTag for giggles but it failed, I forget the error, something not found. The DE10 projects seem to be built with a different structure, I don't see a VHD that looks like the card file you linked to. There are SystemVerilog files that look like they pertain to the same things you are describing:

The "card" file?

https://github.com/machinekit/mksocfpga/blob/fdc9ddc3a42cc2b6f4a1302ef8e6ca8fc23a4bc0/HW/hm2/config/DExx_Nano_xxx_Cramps/atlas_3x24_cap_enc.sv#L7

Similar to the "HPS PLL"?

https://github.com/machinekit/mksocfpga/blob/fdc9ddc3a42cc2b6f4a1302ef8e6ca8fc23a4bc0/HW/QuartusProjects/DE10_Nano_FB_Cramps/DE10_Nano_FB_Cramps.sv#L297

The sure way to check is capture a few bytes being sent over the 
serial port when the driver starts up.  That will tell you the *REAL* 
baud rate.

That's what I was trying to do. I breadboarded a differential reciever IC and connected the input to a Tx driver on my board and the output to an RS232-USB adapter Rx pin. I used Moserial to try to capture a transmission when MK was starting up. I only got a hex value of all 0's at some random baud rate but the max baud rate in moserial is 2mbps. So I scoped the Tx+ line of the board and only found a single short pull down when starting MK  

[Charles Steinkuehler]

On 7/23/2019 11:28 PM, justin White wrote:
> Charles,
>
> Does the Clock rate specified in the pinfile for the module instance relate
> to the clock rate as it's set in the "card" file? Like I said the example I
> came across in MKSOCFPGA specified "ClockLowTag" for SS so that is what I
> used. I later tried building it with ClockMedTag for giggles but it failed,
> I forget the error, something not found. The DE10 projects seem to be built
> with a different structure, I don't see a VHD that looks like the card file
> you linked to. There are SystemVerilog files that look like they pertain to
> the same things you are describing:
>
> The "card" file?
> https://github.com/machinekit/mksocfpga/blob/fdc9ddc3a42cc2b6f4a1302ef8e6ca8fc23a4bc0/HW/hm2/config/DExx_Nano_xxx_Cramps/atlas_3x24_cap_enc.sv#L7

Seems likely, but I don't deal with system verilog much at all, and I
*REALLY* don't deal with instantiating VHDL entities with generics
(ie: the hostmot2 instance) via system verilog.

> Similar to the "HPS PLL"?
> https://github.com/machinekit/mksocfpga/blob/fdc9ddc3a42cc2b6f4a1302ef8e6ca8fc23a4bc0/HW/QuartusProjects/DE10_Nano_FB_Cramps/DE10_Nano_FB_Cramps.sv#L297

Yes, that matches up. Note you have to go into the qsys file defining
the hps (hard processor system) to determine what the PLL frequencies
are set to, which is why it's probably best to just try and measure
the baud rate.

> The sure way to check is capture a few bytes being sent over the
>> serial port when the driver starts up. That will tell you the *REAL*
>> baud rate.
>

> That's what I was trying to do. I breadboarded a differential reciever IC
> and connected the input to a Tx driver on my board and the output to an
> RS232-USB adapter Rx pin. I used Moserial to try to capture a transmission
> when MK was starting up. I only got a hex value of all 0's at some random
> baud rate but the max baud rate in moserial is 2mbps. So I scoped the Tx+
> line of the board and only found a single short pull down when starting MK

What do you get from the debug log when the hm2 driver loads?

Do you have a digital 'scope so you can capture the first few words of
the sserial communications?

IIRC, the sserial stuff works OK on the DE0-Nano, but it's been a
couple years since I messed with this and I'm not 100% sure if I had
my 7i76 (and it's sserial driven field IO pins) working with the DE0
or with a 7i92 (I was doing a lot of switching back and forth at the
time but I'm pretty sure the 7i76 was working properly with both).

--
Charles Steinkuehler
cha...@steinkuehler.net

[justin White]

I whipped up the board with the rs422 tranceiver and I'm getting somewhere I guess. I get a message transmitted at 115200 or best I can tell from the scope but I'm not sure, Serial Terminal gets printable results at 230400 8n1

115200 8n1 00000000 A9 AD A9 A9 AD E9                                  ......

230400 8n1 00000000 36 36 32 36 36 32 36 36   32                       662662662

From the Mesa manuals it says 115200 is setup mode or something. Scope picture doesn't look like it's saying much and no talking to the 8i20 yet. From /var/linuxcnc.log:

SS pins are 000 and 001

Jul 25 05:59:13 mksocfpga-nano-soc msgd:0: ØMQ=4.2.1 czmq=4.0.2 protobuf=3.0.0 atomics=gcc intrinsics    libwebsockets=2.0.3

Jul 25 05:59:13 mksocfpga-nano-soc msgd:0: configured: sha=58fe987

Jul 25 05:59:13 mksocfpga-nano-soc msgd:0: built:      Mar 23 2019 18:41:31 sha=58fe987

Jul 25 05:59:13 mksocfpga-nano-soc msgd:0: register_stuff: actual hostname as announced by avahi='mksocfpga-nano-soc.local'

Jul 25 05:59:13 mksocfpga-nano-soc msgd:0: zeroconf: registering: 'Log service on mksocfpga-nano-soc.local pid 2469'

Jul 25 05:59:14 mksocfpga-nano-soc msgd:0: hal_lib:2485:user iocontrol: machine: 'ST_FPGA_SOC_DC1_test2'  version 'unknown'

Jul 25 05:59:14 mksocfpga-nano-soc msgd:0: hal_lib:2475:rt hm2: loading Mesa HostMot2 driver version 0.15

Jul 25 05:59:14 mksocfpga-nano-soc msgd:0: hal_lib:2475:rt hm2_soc_ol: loading Mesa AnyIO HostMot2 socfpga overlay driver version 0.9

Jul 25 05:59:14 mksocfpga-nano-soc msgd:0: hal_lib:2475:rt hm2/hm2_5i25.0: Smart Serial Firmware Version 0

Jul 25 05:59:14 mksocfpga-nano-soc msgd:0: zeroconf: registered 'Log service on mksocfpga-nano-soc.local pid 2469' _machinekit._tcp 0 TXT "uuid=abc21811-1fb4-4ba9-98f3-6ca4138d9f21" "instance=5451ecc8-aea1-11e9-a89e-ba072231546c" "service=log" "dsn=ipc:///tmp/0.log.abc21811-1fb4-4ba9-98f3-6ca4138d9f21"

Jul 25 05:59:14 mksocfpga-nano-soc msgd:0: hal_lib:2475:rt hm2/hm2_5i25.0: 72 I/O Pins used:

Jul 25 05:59:14 mksocfpga-nano-soc msgd:0: hal_lib:2475:rt hm2/hm2_5i25.0:     IO Pin 000 (GPIO0.P0-01): IOPort

Jul 25 05:59:14 mksocfpga-nano-soc msgd:0: hal_lib:2475:rt hm2/hm2_5i25.0:     IO Pin 001 (GPIO0.P0-02): IOPort

Jul 25 05:59:14 mksocfpga-nano-soc msgd:0: hal_lib:2475:rt hm2/hm2_5i25.0:     IO Pin 002 (GPIO0.P0-03): IOPort

Jul 25 05:59:14 mksocfpga-nano-soc msgd:0: hal_lib:2475:rt hm2/hm2_5i25.0:     IO Pin 003 (GPIO0.P0-04): IOPort

Jul 25 05:59:14 mksocfpga-nano-soc msgd:0: hal_lib:2475:rt hm2/hm2_5i25.0:     IO Pin 004 (GPIO0.P0-05): IOPort

Jul 25 05:59:14 mksocfpga-nano-soc msgd:0: hal_lib:2475:rt hm2/hm2_5i25.0:     IO Pin 005 (GPIO0.P0-06): IOPort

Jul 25 05:59:14 mksocfpga-nano-soc msgd:0: hal_lib:2475:rt hm2/hm2_5i25.0:     IO Pin 006 (GPIO0.P0-07): IOPort

Jul 25 05:59:14 mksocfpga-nano-soc msgd:0: hal_lib:2475:rt hm2/hm2_5i25.0:     IO Pin 007 (GPIO0.P0-08): IOPort

Jul 25 05:59:14 mksocfpga-nano-soc msgd:0: hal_lib:2475:rt hm2/hm2_5i25.0:     IO Pin 008 (GPIO0.P0-09): IOPort

Jul 25 05:59:14 mksocfpga-nano-soc msgd:0: hal_lib:2475:rt hm2/hm2_5i25.0:     IO Pin 009 (GPIO0.P0-10): IOPort

Jul 25 05:59:14 mksocfpga-nano-soc msgd:0: hal_lib:2475:rt hm2/hm2_5i25.0:     IO Pin 010 (GPIO0.P0-11): IOPort

Jul 25 05:59:14 mksocfpga-nano-soc msgd:0: hal_lib:2475:rt hm2/hm2_5i25.0:     IO Pin 011 (GPIO0.P0-12): IOPort

Jul 25 05:59:14 mksocfpga-nano-soc msgd:0: hal_lib:2475:rt hm2/hm2_5i25.0:     IO Pin 012 (GPIO0.P0-13): IOPort

Jul 25 05:59:14 mksocfpga-nano-soc msgd:0: hal_lib:2475:rt hm2/hm2_5i25.0:     IO Pin 013 (GPIO0.P0-14): IOPort

Jul 25 05:59:14 mksocfpga-nano-soc msgd:0: hal_lib:2475:rt hm2/hm2_5i25.0:     IO Pin 014 (GPIO0.P0-15): IOPort

Jul 25 05:59:14 mksocfpga-nano-soc msgd:0: hal_lib:2475:rt hm2/hm2_5i25.0:     IO Pin 015 (GPIO0.P0-16): IOPort

Jul 25 05:59:14 mksocfpga-nano-soc msgd:0: hal_lib:2475:rt hm2/hm2_5i25.0:     IO Pin 016 (GPIO0.P0-17): Encoder #1, pin Index (Input)

Jul 25 05:59:14 mksocfpga-nano-soc msgd:0: hal_lib:2475:rt hm2/hm2_5i25.0:     IO Pin 017 (GPIO0.P0-18): Encoder #0, pin Index (Input)

Jul 25 05:59:14 mksocfpga-nano-soc msgd:0: hal_lib:2475:rt hm2/hm2_5i25.0:     IO Pin 018 (GPIO0.P0-19): Encoder #0, pin A (Input)

Jul 25 05:59:14 mksocfpga-nano-soc msgd:0: hal_lib:2475:rt hm2/hm2_5i25.0:     IO Pin 019 (GPIO0.P0-20): Encoder #2, pin Index (Input)

Jul 25 05:59:14 mksocfpga-nano-soc msgd:0: hal_lib:2475:rt hm2/hm2_5i25.0:     IO Pin 020 (GPIO0.P0-21): Encoder #2, pin A (Input)

Jul 25 05:59:14 mksocfpga-nano-soc msgd:0: hal_lib:2475:rt hm2/hm2_5i25.0:     IO Pin 021 (GPIO0.P0-22): Encoder #1, pin A (Input)

Jul 25 05:59:14 mksocfpga-nano-soc msgd:0: hal_lib:2475:rt hm2/hm2_5i25.0:     IO Pin 022 (GPIO0.P0-23): Encoder #1, pin B (Input)

Jul 25 05:59:14 mksocfpga-nano-soc msgd:0: hal_lib:2475:rt hm2/hm2_5i25.0:     IO Pin 023 (GPIO0.P0-24): Encoder #0, pin B (Input)

Jul 25 05:59:14 mksocfpga-nano-soc msgd:0: hal_lib:2475:rt hm2/hm2_5i25.0:     IO Pin 024 (GPIO0.P1-25): Encoder #3, pin Index (Input)

Jul 25 05:59:14 mksocfpga-nano-soc msgd:0: hal_lib:2475:rt hm2/hm2_5i25.0:     IO Pin 025 (GPIO0.P1-26): Encoder #2, pin B (Input)

Jul 25 05:59:14 mksocfpga-nano-soc msgd:0: hal_lib:2475:rt hm2/hm2_5i25.0:     IO Pin 026 (GPIO0.P1-27): Encoder #5, pin Index (Input)

Jul 25 05:59:14 mksocfpga-nano-soc msgd:0: hal_lib:2475:rt hm2/hm2_5i25.0:     IO Pin 027 (GPIO0.P1-28): Encoder #4, pin Index (Input)

Jul 25 05:59:14 mksocfpga-nano-soc msgd:0: hal_lib:2475:rt hm2/hm2_5i25.0:     IO Pin 028 (GPIO0.P1-29): Encoder #4, pin A (Input)

Jul 25 05:59:14 mksocfpga-nano-soc msgd:0: hal_lib:2475:rt hm2/hm2_5i25.0:     IO Pin 029 (GPIO0.P1-30): Encoder #3, pin A (Input)

Jul 25 05:59:14 mksocfpga-nano-soc msgd:0: hal_lib:2475:rt hm2/hm2_5i25.0:     IO Pin 030 (GPIO0.P1-31): Encoder #3, pin B (Input)

Jul 25 05:59:14 mksocfpga-nano-soc msgd:0: hal_lib:2475:rt hm2/hm2_5i25.0:     IO Pin 031 (GPIO0.P1-32): Encoder #5, pin A (Input)

Jul 25 05:59:14 mksocfpga-nano-soc msgd:0: hal_lib:2475:rt hm2/hm2_5i25.0:     IO Pin 032 (GPIO0.P1-33): Encoder #5, pin B (Input)

Jul 25 05:59:14 mksocfpga-nano-soc msgd:0: hal_lib:2475:rt hm2/hm2_5i25.0:     IO Pin 033 (GPIO0.P1-34): Encoder #4, pin B (Input)

Jul 25 05:59:14 mksocfpga-nano-soc msgd:0: hal_lib:2475:rt hm2/hm2_5i25.0:     IO Pin 034 (GPIO0.P1-35): IOPort

Jul 25 05:59:14 mksocfpga-nano-soc msgd:0: hal_lib:2475:rt hm2/hm2_5i25.0:     IO Pin 035 (GPIO0.P1-36): IOPort

Jul 25 05:59:14 mksocfpga-nano-soc msgd:0: hal_lib:2475:rt hm2/hm2_5i25.0:     IO Pin 036 (GPIO0.P1-37): IOPort

Jul 25 05:59:14 mksocfpga-nano-soc msgd:0: hal_lib:2475:rt hm2/hm2_5i25.0:     IO Pin 037 (GPIO0.P1-38): IOPort

Jul 25 05:59:14 mksocfpga-nano-soc msgd:0: hal_lib:2475:rt hm2/hm2_5i25.0:     IO Pin 038 (GPIO0.P1-39): StepGen #5, pin Step (Output)

Jul 25 05:59:14 mksocfpga-nano-soc msgd:0: hal_lib:2475:rt hm2/hm2_5i25.0:     IO Pin 039 (GPIO0.P1-40): StepGen #5, pin Direction (Output)

Jul 25 05:59:14 mksocfpga-nano-soc msgd:0: hal_lib:2475:rt hm2/hm2_5i25.0:     IO Pin 040 (GPIO0.P1-41): StepGen #4, pin Step (Output)

Jul 25 05:59:14 mksocfpga-nano-soc msgd:0: hal_lib:2475:rt hm2/hm2_5i25.0:     IO Pin 041 (GPIO0.P1-42): StepGen #4, pin Direction (Output)

Jul 25 05:59:14 mksocfpga-nano-soc msgd:0: hal_lib:2475:rt hm2/hm2_5i25.0:     IO Pin 042 (GPIO0.P1-43): StepGen #3, pin Step (Output)

Jul 25 05:59:14 mksocfpga-nano-soc msgd:0: hal_lib:2475:rt hm2/hm2_5i25.0:     IO Pin 043 (GPIO0.P1-44): StepGen #3, pin Direction (Output)

Jul 25 05:59:14 mksocfpga-nano-soc msgd:0: hal_lib:2475:rt hm2/hm2_5i25.0:     IO Pin 044 (GPIO0.P1-45): StepGen #2, pin Step (Output)

Jul 25 05:59:15 mksocfpga-nano-soc msgd:0: hal_lib:2475:rt hm2/hm2_5i25.0:     IO Pin 045 (GPIO0.P1-46): StepGen #2, pin Direction (Output)

Jul 25 05:59:15 mksocfpga-nano-soc msgd:0: hal_lib:2475:rt hm2/hm2_5i25.0:     IO Pin 046 (GPIO0.P1-47): StepGen #1, pin Step (Output)

Jul 25 05:59:15 mksocfpga-nano-soc msgd:0: hal_lib:2475:rt hm2/hm2_5i25.0:     IO Pin 047 (GPIO0.P1-48): StepGen #1, pin Direction (Output)

Jul 25 05:59:15 mksocfpga-nano-soc msgd:0: hal_lib:2475:rt hm2/hm2_5i25.0:     IO Pin 048 (GPIO0.P2-49): StepGen #0, pin Step (Output)

Jul 25 05:59:15 mksocfpga-nano-soc msgd:0: hal_lib:2475:rt hm2/hm2_5i25.0:     IO Pin 049 (GPIO0.P2-50): StepGen #0, pin Direction (Output)

Jul 25 05:59:15 mksocfpga-nano-soc msgd:0: hal_lib:2475:rt hm2/hm2_5i25.0:     IO Pin 050 (GPIO0.P2-51): IOPort

Jul 25 05:59:15 mksocfpga-nano-soc msgd:0: hal_lib:2475:rt hm2/hm2_5i25.0:     IO Pin 051 (GPIO0.P2-52): IOPort

Jul 25 05:59:15 mksocfpga-nano-soc msgd:0: hal_lib:2475:rt hm2/hm2_5i25.0:     IO Pin 052 (GPIO0.P2-53): IOPort

Jul 25 05:59:15 mksocfpga-nano-soc msgd:0: hal_lib:2475:rt hm2/hm2_5i25.0:     IO Pin 053 (GPIO0.P2-54): IOPort

Jul 25 05:59:15 mksocfpga-nano-soc msgd:0: hal_lib:2475:rt hm2/hm2_5i25.0:     IO Pin 054 (GPIO0.P2-55): IOPort

Jul 25 05:59:15 mksocfpga-nano-soc msgd:0: hal_lib:2475:rt hm2/hm2_5i25.0:     IO Pin 055 (GPIO0.P2-56): IOPort

Jul 25 05:59:15 mksocfpga-nano-soc msgd:0: hal_lib:2475:rt hm2/hm2_5i25.0:     IO Pin 056 (GPIO0.P2-57): IOPort

Jul 25 05:59:15 mksocfpga-nano-soc msgd:0: hal_lib:2475:rt hm2/hm2_5i25.0:     IO Pin 057 (GPIO0.P2-58): IOPort

Jul 25 05:59:15 mksocfpga-nano-soc msgd:0: hal_lib:2475:rt hm2/hm2_5i25.0:     IO Pin 058 (GPIO0.P2-59): IOPort

Jul 25 05:59:15 mksocfpga-nano-soc msgd:0: hal_lib:2475:rt hm2/hm2_5i25.0:     IO Pin 059 (GPIO0.P2-60): IOPort

Jul 25 05:59:15 mksocfpga-nano-soc msgd:0: hal_lib:2475:rt hm2/hm2_5i25.0:     IO Pin 060 (GPIO0.P2-61): IOPort

Jul 25 05:59:15 mksocfpga-nano-soc msgd:0: hal_lib:2475:rt hm2/hm2_5i25.0:     IO Pin 061 (GPIO0.P2-62): IOPort

Jul 25 05:59:15 mksocfpga-nano-soc msgd:0: hal_lib:2475:rt hm2/hm2_5i25.0:     IO Pin 062 (GPIO0.P2-63): IOPort

Jul 25 05:59:15 mksocfpga-nano-soc msgd:0: hal_lib:2475:rt hm2/hm2_5i25.0:     IO Pin 063 (GPIO0.P2-64): IOPort

Jul 25 05:59:15 mksocfpga-nano-soc msgd:0: hal_lib:2475:rt hm2/hm2_5i25.0:     IO Pin 064 (GPIO0.P2-65): IOPort

Jul 25 05:59:15 mksocfpga-nano-soc msgd:0: hal_lib:2475:rt hm2/hm2_5i25.0:     IO Pin 065 (GPIO0.P2-66): IOPort

Jul 25 05:59:15 mksocfpga-nano-soc msgd:0: hal_lib:2475:rt hm2/hm2_5i25.0:     IO Pin 066 (GPIO0.P2-67): IOPort

Jul 25 05:59:15 mksocfpga-nano-soc msgd:0: hal_lib:2475:rt hm2/hm2_5i25.0:     IO Pin 067 (GPIO0.P2-68): IOPort

Jul 25 05:59:15 mksocfpga-nano-soc msgd:0: hal_lib:2475:rt hm2/hm2_5i25.0:     IO Pin 068 (GPIO0.P2-69): IOPort

Jul 25 05:59:15 mksocfpga-nano-soc msgd:0: hal_lib:2475:rt hm2/hm2_5i25.0:     IO Pin 069 (GPIO0.P2-70): IOPort

Jul 25 05:59:15 mksocfpga-nano-soc msgd:0: hal_lib:2475:rt hm2/hm2_5i25.0:     IO Pin 070 (GPIO0.P2-71): IOPort

Jul 25 05:59:15 mksocfpga-nano-soc msgd:0: hal_lib:2475:rt hm2/hm2_5i25.0:     IO Pin 071 (GPIO0.P2-72): IOPort

Jul 25 05:59:15 mksocfpga-nano-soc msgd:0: hal_lib:2475:rt hm2/hm2_5i25.0: registered

Jul 25 05:59:15 mksocfpga-nano-soc msgd:0: hal_lib:2475:rt hm2_soc_ol: initialized AnyIO hm2_soc_ol_board hm2-socfpga0 on /dev/uio0

This is just the Tx line obviously.

[justin White]

BTW, when I try to build with SS "ClockMedTag" in the pinfile I get:

 

Error (10482): VHDL error at PIN_st_fpga_soc_dc1f.vhd(80): object "ClockMedTag" is used but not declared File: /work/HW/hm2/config/DExx_Nano_xxx_Cramps/PIN_st_fpga_soc_dc1f.vhd Line: 80

Warning (10236): Verilog HDL Implicit Net warning at top_io_modules.sv(39): created implicit net for "hps_reset_req" File: /work/HW/QuartusProjects/Common/top_io_modules.sv Line: 39

Warning (10236): Verilog HDL Implicit Net warning at altera_edge_detector.v(21): created implicit net for "reset_qual_n" File: /work/HW/cv-ip/edge_detect/altera_edge_detector.v Line: 21

Warning (10236): Verilog HDL Implicit Net warning at hps_sdram_pll.sv(168): created implicit net for "pll_dr_clk" File: /work/HW/QuartusProjects/DE10_Nano_FB_Cramps/soc_system/synthesis/submodules/hps_sdram_pll.sv Line: 168

Warning (10236): Verilog HDL Implicit Net warning at alt_vipvfr131_prc.v(142): created implicit net for "master_clock" File: /work/HW/QuartusProjects/DE10_Nano_FB_Cramps/soc_system/synthesis/submodules/alt_vipvfr131_prc.v Line: 142

Warning (10236): Verilog HDL Implicit Net warning at alt_vipvfr131_prc.v(143): created implicit net for "master_reset" File: /work/HW/QuartusProjects/DE10_Nano_FB_Cramps/soc_system/synthesis/submodules/alt_vipvfr131_prc.v Line: 143

Info (144001): Generated suppressed messages file /work/HW/QuartusProjects/DE10_Nano_FB_Cramps/output_files/DE10_Nano_FB_Cramps.map.smsg

Error: Quartus Prime Analysis & Synthesis was unsuccessful. 1 error, 8 warnings

    Error: Peak virtual memory: 1288 megabytes

    Error: Processing ended: Thu Jul 25 00:43:19 2019

    Error: Elapsed time: 00:03:22

    Error: Total CPU time (on all processors): 00:03:37

[Michael Brown]

I can perhaps look it up later today but clock low is 50mhz clk medium is 100 MHz and clock high should be 200 mhz as far as I can recall. 

--
website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit
---
You received this message because you are subscribed to a topic in the Google Groups "Machinekit" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/machinekit/eVhvTnuhblE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to machinekit+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/f7972613-5bbe-423c-ab84-2c3c936a62c3%40googlegroups.com.

[justin White]

IIRC those are the frequencies listed in the .sv file. It seems from what PCW said I should be specifying ClockMed in the pin file, problem is that when I do I cannot build the firmware. The above error is thrown.

[Michael Brown]

Ok well I cannot cope with the stress of starting up my workstation this week and I didn't catch any quartus log in your former post?

MiB

On Fri, 26 Jul 2019, 19.07 justin White <blaz...@gmail.com> wrote:

IIRC those are the frequencies listed in the .sv file. It seems from what PCW said I should be specifying ClockMed in the pin file, problem is that when I do I cannot build the firmware. The above error is thrown.

--
website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit
---
You received this message because you are subscribed to a topic in the Google Groups "Machinekit" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/machinekit/eVhvTnuhblE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to machinekit+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/29f2fb1a-ed2a-49f0-9f58-63e6c65dc9f5%40googlegroups.com.

[justin White]

Ok well I cannot cope with the stress of starting up my workstation this week and I didn't catch any quartus log in your former post?

MiB

Lol, rough week eh?

Post directly after has the quartus snippet with the error, re-ran it,full terminal print attached. Again, only happens if in pinfile:

(SSerialTag,    x"00",  ClockMedTag,    x"01",  SSerialCommandAddr&PadT,    SSerialNumRegs,     x"10",  SSerialMPBitMask),

if:

(SSerialTag,    x"00",  ClockLowTag,    x"01",  SSerialCommandAddr&PadT,    SSerialNumRegs,     x"10",  SSerialMPBitMask),

it will build fine, but SS does not work.

 

[Charles Steinkuehler]

The problem is it doesn't look like ClockMedTag is declared in the
IDROMConst.vhd file, just ClockLowTag and ClockHighTag:

https://github.com/machinekit/mksocfpga/blob/master/HW/hm2/config/IDROMConst.vhd#L402-L404

...causing the Quartus error:

Error (10482): VHDL error at PIN_st_fpga_soc_dc1f.vhd(80): object
"ClockMedTag" is used but not declared File:
/work/HW/hm2/config/DExx_Nano_xxx_Cramps/PIN_st_fpga_soc_dc1f.vhd Line: 80

The configs I have that use SSerial are using ClockLowTag and IIRC
they worked OK. You might check and see if Peter has updated the
IDROMConst.vhd file, the one in the Machinekit repo might be fairly
dated. But I think it ought to work when using ClockLowTag, so there
may be some other weirdness going on.

--
Charles Steinkuehler
cha...@steinkuehler.net

[justin White]

The pinfile examples I come across are as you say using the ClockLowTag, looking at the sserialwa.vhd file in mksocfpga "clockmed" is referenced all over the place, but I'm not the guy to be trying to figure out what's what in any type of code unless it's hal or it's obvious. I DL'd the 5i25 source zip from mesanet (I assume this started with the 5i25 sources), i diff'd the idromconst.vhd's and the only SS related changes I see are the additions of  a "SSerialNTXEn0Pin" pintype. sserialwa.vhd seems to have changed this

port map(

addra => regaddr, 

addrb => ioradd(log2(InterfaceRegs) +1 downto 2),

clk  => clk,

dina  => ibus,

-- douta => 

doutb => libus32_3,

wea => hloadregs3

);

 

makeUARTRs: for i in 0 to Ports -1 generate

auarrx: entity work.uartr8

port map (

clk => clkmed,

ibus => mobus,

obus => iodata,

popfifo => readrxdata(i),

loadbitratel => loadrxbitratel(i),

loadbitratem => loadrxbitratem(i),

loadbitrateh => loadrxbitrateh(i),

readbitratel => '0',

readbitratem => '0',

readbitrateh => '0',

clrfifo => clearrxfifo(i),

readfifocount => readrxfifocount(i),

loadmode => loadrxmode(i),

readmode => readrxmode(i),

fifohasdata => rxfifohasdata(i),

rxmask => drven(i), -- for half duplex rx mask

rxdata => rxdata(i)

         );

end generate;

to this (generic map)

port map(

addra => regaddr, 

addrb => ioradd(log2(InterfaceRegs) +1 downto 2),

clk  => clk,

dina  => ibus,

-- douta => 

doutb => libus32_3,

wea => hloadregs3

);

 

makeUARTRs: for i in 0 to Ports -1 generate

auarrx: entity work.uartr8

generic map (

Clock => BaseClock

)

port map (

clk => clkmed,

ibus => mobus,

obus => iodata,

popfifo => readrxdata(i),

loadbitratel => loadrxbitratel(i),

loadbitratem => loadrxbitratem(i),

loadbitrateh => loadrxbitrateh(i),

readbitratel => '0',

readbitratem => '0',

readbitrateh => '0',

clrfifo => clearrxfifo(i),

readfifocount => readrxfifocount(i),

loadmode => loadrxmode(i),

readmode => readrxmode(i),

loadfilter => loadrxfilter(i),

fifohasdata => rxfifohasdata(i),

rxmask => drven(i), -- for half duplex rx mask

rxdata => rxdata(i)

         );

end generate;

Other than that it's just some lines for filters and the addition of the ntxenable stuff. I noticed MKSOCFPGA is missing sserialremote.vhd's. Other than that I have no idea.

mesa sources

[justin White]

From PCW:

The fact that it reads 0 as a version number means there is likely something wrong with the firmware source.
That is, the driver cannot communicate with the embedded CPU that manages he communications.
There never was a released version 0. I would expect version 43 if the source is less than 5
or so years old.

The initial baud rate should be 2.5 MBaud (400 ns per bit) I suspect something wrong with the clock
generation (the actual hardware clock does not match the CLKMED constant)

  

The version numbers in the pinout file are hardware versions of the individual modules.
The sserial version that the driver reads out is the software version (of the code that runs on the sserial interface CPU) This should be 43 decimal, reading 0 probably means that the CPU is not responding or some other bitfile /firmware issue

[Michael Brown]

Yup still on the edge of understanding. dk beyond reason. I'm still on 1/2 gear and you do know that mksocfpga only has an accelerated frame buffer and still no real unlicenced GPU. 

--

website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit
---
You received this message because you are subscribed to a topic in the Google Groups "Machinekit" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/machinekit/eVhvTnuhblE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to machinekit+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/09220b16-ba90-4f24-b5fb-787c2f95ab35%40googlegroups.com.

[justin White]

Yup still on the edge of understanding. dk beyond reason. I'm still on 1/2 gear .........

That's OK, at the moment I'm just trying to make sure the hardware works OK for smart serial and maybe get you a little insight of the issue when you get around to looking at it. From what I gather ClockLowTag is what should be specified in the pinfile and ClockMed is I guess used internally to determine SS baud rate. Seems that somewhere in the firmware SS is not "connected", as in it should print "SmartSerial version 43" when instantiated rather that version 0 as does when I build with it. That's just the way I understand it so take it with a grain of salt.

and you do know that mksocfpga only has an accelerated frame buffer and still no real unlicenced GPU. 

Yeah I know, I'm not trying to run 3D acceleration or anything, it's just since the FB is fixed the monitor must either display 1024x768 natively or scale it. Alot of smaller or obscure monitors don't seem to negotiate resolutions well or at all so the server side must do it, in this case it can't so I suppose the firmware needs to be built for whatever resolution is needed. If you can point me in the right direction I can try to build it myself......In the meantime I scooped up an older 4:3 LCD so I don't have to drag a monitor I use over to my mill when I need to try something. 

I had some time so I made up a standalone test GUI. I did sort out the ADC conversion stuff in hardware and HAL. Resistor dividers actually do work well, I initially didn't use correct values. I used the method I mentioned previously to scrub the 32bit integer and scale it to a useable voltage with hal components. It actually works very well this way but has a bit of noise. I gave a friend of mine some guidance on writing a single HAL component that can handle the conversion as well as digitally filter the output. I'll see how well that works before I go back and add more passives to try to filter the noise.

 

  

[Michael Brown]

Not very easy from my cell phone here however:

In qsys there are 2 instances where you set up the timings for the screen monitor. There should be some saved setups HD etc. Lastly you need to place the correct screen settings in the device tree there is a HD example there too. 1920 x1080. Sorry for not being online atm... 

--

website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit
---
You received this message because you are subscribed to a topic in the Google Groups "Machinekit" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/machinekit/eVhvTnuhblE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to machinekit+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/dfe26639-27a7-4ba6-b9bf-344bd1d0da9e%40googlegroups.com.

[justin White]

On Tuesday, August 6, 2019 at 1:07:38 PM UTC-4, Michael Brown wrote:

Not very easy from my cell phone here however:

In qsys there are 2 instances where you set up the timings for the screen monitor. There should be some saved setups HD etc. Lastly you need to place the correct screen settings in the device tree there is a HD example there too. 1920 x1080. Sorry for not being online atm... 

Gonna Give this a try soon as I get a chance. Waiting for my friend to correct a minor issue with the time based filter in the RT hal component he whipped up for me for the ADC then I'll post it up here. Maybe you can include it in your project if you think it's useful. It certainly is for someone like me who only works with hal.

[Michael Brown]

OK back to being able to be online with my workstation:

I have allways had a fight setting up proper display resolutions on the altera soc's however I can give you some key notes:

In qsys there are 3 cores to consider:

For display timing settings:

alt_vip_vfr_hdmi   (framereader)

alt_vip_itc_0      (Clocked video output)

The display core clock itself:

pll_lcd            --> lcd_clk

 

1600x900 would allow me to test it out on my mill and I might have a use for 800x480. I didn't realize the resolution was fixed, my 1080P monitors don't have a problem displaying 1024x768, all my other monitors do. I suppose in a real usage scenario I'd have to look further into your previous reply and try to figure out how to set a resolution for whatever monitor I intended to use.

Sadly there are currently no presets for these 2 resolutions for the framebuffer related cores (presets are found in qsys view menu), as I havent had use of these resolutions myself (in newer time).

And I also have no (qsys) formula other than intuitive guess work.....

Last there is the Devicetree entry this is the current one:

https://github.com/the-snowwhite/soc-image-buildscripts/blob/master/SD-Image-Gen/patches/4.9.76-ltsi-rt/current/0012-Added-DE-10-Nano-with-uio-with-without-framebuffer-1.patch#L291

This entry:

vip@0x100031000 {

compatible = "altr,vip-frame-reader-1.0", "ALTR,vip-frame-reader-9.1";

reg = <0x00000001 0x00031000 0x00000080>;

max-width = <1024>;

max-height = <768>;

bits-per-color = <0x8>;

colors-per-beat = <0x4>;

beats-per-pixel = <0x1>;

mem-word-width = <0x80>;

};

Well It would be nice with a hal rt component for calculating temperature readings based on ntc probes instead of the python user component hal_temp_atlas I derived from the hal_temp_bbb .... :-)

 

[justin White]

The hal component did work fine then my friend "cleaned it up" and it acts weird when you enable the filter. Could just remove the filter pin and post it but it is rather handy.

I've been tracking down an issue with the stepgens and depending on what the issue is it may be part of the smart serial issue. I have 4 out of 6 stepgens that work, on my 5th stepgen only the direction pin works, not the step pin. Neither work on the 6th stepgen.  I disabled SS for the time being but it was using consecutive pins with the 5th and 6th stepgens. It was difficult to see what was going on until I got my GUI setup. Now I can see that in hal it is actually working and I'm getting feedback to the PID loop but the pins of the Nano itself do not electrically do anything, I can verify that with my scope. Thinking maybe I damaged the GPIO pins  from all the hardware swapping I've been doing, I picked up another DE10 Nano and the same thing happens. I tried swapping stepgen instance 0,1 for 4,5 in the .vhd and rebuilt the firmware without changing any hal configuration and stepgens 4 and 5 work fine if they are controlling different GPIO pins without making any hal changes. I jumped the GPIO pins for a working stepgen to the PCB pins I use for 4 and 5 and the interface hardware works fine that way.

So the conclusion I'm drawing is that there's an issue with the firmware that's getting built. hm2 thinks all 6 stepgens are there but there is only 4 1/2 stepgens actually working. I seem to recall there is a parameter that has to change to add a certain amount of certain pin types, but I didn't think it applied in this case and I'm not sure what it is. 

My current VHD with SS disabled attached

[Michael Brown]

I have an older config that has worked with 8 stepgens:

hm2_soc_ol config line here:

Have you tried with:

  num_stepgens=6  in the hm2_soc_ol config line ?

Also You can look in the Compiled (Or after analysis & elaboration) Quartus project and see how many stepgens are elaborated like in below pic:

[Michael Brown]

Quartus Update:
After compiling (the default DE10_Nano_FB_Cramps project) Notice that all 9 (0-8) stepgens instansiated in the pin file have a (not null) sized SRL16E:\steptable:0:asr16e instance:

[justin White]

On Monday, 19 August 2019 13:24:22 UTC+2, Michael Brown wrote:

I have an older config that has worked with 8 stepgens:

hm2_soc_ol config line here:

Have you tried with:

  num_stepgens=6  in the hm2_soc_ol config line ?

Yes, my  config line is:

[HOSTMOT2]

DRIVER=hm2_soc_ol

BOARD=5i25

CONFIG="num_encoders=6 num_stepgens=6" "enable_adc=1"

DEVNAME=hm2-socfpga0 already_programmed=1

If the stepgens=6 wasn't there hm2 wouldn't instantiate them in HAL. They are actually completely visible and HAL seems to think they're working. I dug up one of my first test hal files and #4 did in fact work with that but I had much less else going on.

I'm not terribly familiar with Quartus. I usually just do as in the readme https://github.com/the-snowwhite/mksocfpga to build the firmware. I did have an issue before where it was building firmware that wouldn't boot, deleting mksocfpga and pulling it again fixed that. That may even have had something to do with trying to open the project previously. Ill try re-pulling it and see what happens.

I ran the analysis in in QP and this is what  I'm seeing with the stepgens:

[justin White]

One thing I noticed, I recall seeing this the first time I started messing with the .vhd's. All of the pinfiles in the DExx_Nano_xxx_Cramps config use this line for stepgens

(StepGenTag,    x"02",  ClockLowTag,    x"0A",  StepGenRateAddr&PadT,       StepGenNumRegs,     x"00",  StepGenMPBitMask),

The NumInst being "0A" looked a little strange to me so I changed it to the actual number (06) for every pinfile I've been working with. Could that be causing an issue?

[Michael Brown]

No changing numinst should work just fine

[Michael Brown]

I never got the hang of Quartus reporting..... :)

After a full compilation Drag the line between the project navigator .. hieracy window and the Compilation report (table of contents ), to the right

to expand the project navigator to show/see the LMN's needed info ..etc like in my pic above 

[Charles Steinkuehler]

Actually, the NumInstances field of the ModuleRecord is defined as an
8 bit std_logic_vector:

https://github.com/machinekit/mksocfpga/blob/master/HW/hm2/config/IDROMConst.vhd#L839

In VHDL, it should throw an error if you use 06 for this value (VHDL
won't convert an integer value into a std_logic_vector without some
sort of type conversion).

If you meant that you are using x"06" (an 8-bit hexadecimal value),
that should work fine, but you will only get 6 stepgens instead of the
10 you'd get with x"0A".

On 8/19/2019 3:19 PM, Michael Brown wrote:
> No changing numinst should work just fine
>
> On Monday, 19 August 2019 18:05:28 UTC+2, justin White wrote:
>>
>> One thing I noticed, I recall seeing this the first time I started messing
>> with the .vhd's. All of the pinfiles in the DExx_Nano_xxx_Cramps config use
>> this line for stepgens
>>
>> (StepGenTag, x"02", ClockLowTag, x"0A", StepGenRateAddr&
>> PadT, StepGenNumRegs, x"00", StepGenMPBitMask),
>>
>> The NumInst being "0A" looked a little strange to me so I changed it to
>> the actual number (06) for every pinfile I've been working with. Could that
>> be causing an issue?
>>
>> On Monday, August 19, 2019 at 11:33:29 AM UTC-4, justin White wrote:
>>>
>>> On Monday, 19 August 2019 13:24:22 UTC+2, Michael Brown wrote:
>>>>>
>>>>> I have an older config that has worked with 8 stepgens:
>>>>> hm2_soc_ol config line here:

>>>>> <https://github.com/the-snowwhite/Hm2-soc_FDM/blob/master/Cramps/PY/Mibrap-X_hm3_fdm-soc/fdm/config/motion.py#L15>

>>>>> <https://github.com/the-snowwhite/Hm2-soc_FDM/blob/master/Cramps/PY/Mibrap-X_hm3_fdm-soc/fdm/config/motion.py#L15>

--
Charles Steinkuehler
cha...@steinkuehler.net