Re: [Machinekit] Re: DE10 Nano suggested development environment?

[cern via Machinekit]

Hi,

Feb 26, 2020, 16:02 by blazin...@gmail.com:

> Yes the mesa firmware has been around for quite some time but only in this 
> project has it been this configurable. 
>
> Putting an fpga on a pcb isn't super easy for novices, while Mesa is 
> fantastic you are buying a board with the fpga's i/o hardware is set in 
> stone. You can reconfigure stepgens for PWM and such only because the 
> external hardware is the same. If I want to use a 7i76e but I need 6 
> stepgens,  well now I need to add a card. None of that is a major issue it's 
> good stuff but that's how it is.
>
> Couple that with the fact that there is a low end cpu attached directly to 
> that fpga and you have an all in one hmi type device that's completely 
> reconfigurable. The daughter card I made was built with the intention of 
> cramming as much stuff as possible, I now use it for prototyping everything 
> because it is literally as simple as writing a hal file and possibly making a 
> simple GUI.
>
> I can run just about any machine from my board, albeit a mill lathe, 
> whatever. My biggest issue is actually MK itself, it's too far behind 
> linuxcnc in key areas like joints+axis and since you mentioned mesa, well 
> that's rather far behind too. I wouldn't have a problem deploying mksocfpga 
> if I didn't have a problem deploying MK itself.
>
Currently, the machinekit/machinekit-cnc@master cannot be build on top of 
machnekit/machinekit-hal@master due to merge in of the so-called 
"single-module-dir" branch. I am planning to have a look at it in due time, but 
it would be helpful if someone else wanted to take a look at this.

Or do the LinuxCNC port. I, too, have been thinking about some kind of LinuxCNC 
jail where only the most trusted prisoners would be allowed access to the 
Machinekit-HAL. However, I didn't spend any significant time on this. I think 
Zultron or ArcEye did something, so maybe have a peek in theirs repositories.

Cern.

>
> On Wed, Feb 26, 2020, 4:41 AM Bas de Bruijn <> b...@basdebruijn.com> > wrote:
>
>>
>>
>> > On 26 Feb 2020, at 01:34, justin White <>> blazin...@gmail.com>> > wrote:
>>  > 
>>  > Its amazing that mksocfpga doesn't get more interest/support, I dont 
>> think people realize how powerful the idea is.
>>  
>>  Do you mean the reconfigurability? If not, the Mesa FPGA is around already 
>> for a long time, and it is great that the FPGA runs on such a small platform 
>> too.
>>  
>>  The reason I think it is not used very much is that for real use, in a 
>> production/manufacturing  environment, there is no hardware that one can 
>> “just buy and works”.
>>  
>>  If I want to use this in a customer project, from an integrator point of 
>> view, my concerns are about longtime availability of the hardware. I do not 
>> want to buy components, solder etc. I just want to open the box, attach 
>> wires to terminals and configure the machine.
>>  
>>  If something breaks or need to make another machine then I want to order 
>> the _exact_ same hardware, use the same code/version of the original and it 
>> should just work.
>>  
>>  This holds for BBB’s too btw. For customers I only use pc’s with the Mesa 
>> cards. There are other considerations than just the cost price of the board. 
>> Development time, hardware availability and support far outweigh the cost of 
>> the board.
>>  
>>  Just my 2 ct.
>>  
>>  
>>  
>>
>
>
>
> --
>  website: > http://www.machinekit.io>  blog: > http://blog.machinekit.io>  
> github: > https://github.com/machinekit
>  --- 
>  You received this message because you are subscribed to the Google Groups 
> "Machinekit" group.
>  To unsubscribe from this group and stop receiving emails from it, send an 
> email to > machinekit+unsubscr...@googlegroups.com> .
>  To view this discussion on the web visit > 
> https://groups.google.com/d/msgid/machinekit/CA%2BQ02MN0Uiof8LE7m%2BWxx%2BPLKonQfug3GbixdXd6ZqzN3bDFTg%40mail.gmail.com
>  
> >
>  .
>

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/machinekit/M1IRL95--3-2%40tuta.io.

Re: [Machinekit] Re: DE10 Nano suggested development environment?

[Bas de Bruijn]

> On 26 Feb 2020, at 16:03, justin White  wrote:
> 
> My biggest issue is actually MK itself, it's too far behind linuxcnc in key 
> areas like joints+axis and since you mentioned mesa, well that's rather far 
> behind too. I wouldn't have a problem deploying mksocfpga if I didn't have a 
> problem deploying MK itself.

My personal interest is the HAL part of Machinekit. Over time people have 
focused on that part. The CNC stack is stale, and I personally do not give it 
much hope that it ever will be updated.
Best hope is that somebody will build LCNC with machinekit-hal. Have both of 
best worlds.

PR’s to Mesa drivers are always welcome.

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/machinekit/37D77E7F-2B25-4FFF-8572-AB0E62DB2107%40basdebruijn.com.

Re: [Machinekit] Re: DE10 Nano suggested development environment?

[justin White]

Yes the mesa firmware has been around for quite some time but only in this
project has it been this configurable.

Putting an fpga on a pcb isn't super easy for novices, while Mesa is
fantastic you are buying a board with the fpga's i/o hardware is set in
stone. You can reconfigure stepgens for PWM and such only because the
external hardware is the same. If I want to use a 7i76e but I need 6
stepgens,  well now I need to add a card. None of that is a major issue
it's good stuff but that's how it is.

Couple that with the fact that there is a low end cpu attached directly to
that fpga and you have an all in one hmi type device that's completely
reconfigurable. The daughter card I made was built with the intention of
cramming as much stuff as possible, I now use it for prototyping everything
because it is literally as simple as writing a hal file and possibly making
a simple GUI.

I can run just about any machine from my board, albeit a mill lathe,
whatever. My biggest issue is actually MK itself, it's too far behind
linuxcnc in key areas like joints+axis and since you mentioned mesa, well
that's rather far behind too. I wouldn't have a problem deploying mksocfpga
if I didn't have a problem deploying MK itself.

On Wed, Feb 26, 2020, 4:41 AM Bas de Bruijn  wrote:

>
>
> > On 26 Feb 2020, at 01:34, justin White  wrote:
> >
> > Its amazing that mksocfpga doesn't get more interest/support, I dont
> think people realize how powerful the idea is.
>
> Do you mean the reconfigurability? If not, the Mesa FPGA is around already
> for a long time, and it is great that the FPGA runs on such a small
> platform too.
>
> The reason I think it is not used very much is that for real use, in a
> production/manufacturing  environment, there is no hardware that one can
> “just buy and works”.
>
> If I want to use this in a customer project, from an integrator point of
> view, my concerns are about longtime availability of the hardware. I do not
> want to buy components, solder etc. I just want to open the box, attach
> wires to terminals and configure the machine.
>
> If something breaks or need to make another machine then I want to order
> the _exact_ same hardware, use the same code/version of the original and it
> should just work.
>
> This holds for BBB’s too btw. For customers I only use pc’s with the Mesa
> cards. There are other considerations than just the cost price of the
> board. Development time, hardware availability and support far outweigh the
> cost of the board.
>
> Just my 2 ct.
>
>
>
>

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/machinekit/CA%2BQ02MN0Uiof8LE7m%2BWxx%2BPLKonQfug3GbixdXd6ZqzN3bDFTg%40mail.gmail.com.

Re: [Machinekit] Re: DE10 Nano suggested development environment?

[Bas de Bruijn]

> On 26 Feb 2020, at 01:34, justin White  wrote:
> 
> Its amazing that mksocfpga doesn't get more interest/support, I dont think 
> people realize how powerful the idea is.

Do you mean the reconfigurability? If not, the Mesa FPGA is around already for 
a long time, and it is great that the FPGA runs on such a small platform too.

The reason I think it is not used very much is that for real use, in a 
production/manufacturing  environment, there is no hardware that one can “just 
buy and works”.

If I want to use this in a customer project, from an integrator point of view, 
my concerns are about longtime availability of the hardware. I do not want to 
buy components, solder etc. I just want to open the box, attach wires to 
terminals and configure the machine.

If something breaks or need to make another machine then I want to order the 
_exact_ same hardware, use the same code/version of the original and it should 
just work.

This holds for BBB’s too btw. For customers I only use pc’s with the Mesa 
cards. There are other considerations than just the cost price of the board. 
Development time, hardware availability and support far outweigh the cost of 
the board.

Just my 2 ct.



-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/machinekit/2FAAD5EE-00AE-4884-974E-AF6041FA96F3%40basdebruijn.com.

Re: [Machinekit] Re: DE10 Nano suggested development environment?

[justin White]

I'd certainly help if I could but I'm not the guy for that.

Its amazing that mksocfpga doesn't get more interest/support, I dont think
people realize how powerful the idea is.

On Tue, Feb 25, 2020, 3:21 AM Michael Brown 
wrote:

>
>
>
> I can only put up this proposal:
> Generally speaking I would be nice to be able to change screen resolutions
> at runtime on the de10_nano board,
> instead of having to generate a custom quartus hdmi bitfile and dtb for
> each resolution(screen) needed.
>
> I once found a different de10 nano project on github that seemed to have
> this exact functionality:
> https://github.com/MiSTer-devel
>
> However at the time I investigated this project I was unable to nail down
> the exact commits/additions needed to port
> the change screen resolution functionality from the mister quartus project
> and the linux framebuffer driver. --> mksocfpga
>
> perhaps with some helping hands this functionality can be ported over from
> the mister emulator.
>
>
> On Saturday, February 22, 2020 at 9:58:21 PM UTC+1, justin White wrote:
>
> Any plans to add this to the build script? Playing with Quartus isn't
>> something I generally love to do.
>>
>
> If some sort of group effort can be put into porting the resolution change
> mechanism from the mister project,
> this will then result in an updated de10 mksocfpga project (with screen
> resolution change bitfiles) and also
> an updated framebuffer driver (which goes into the kernel part of the
> buildscript)
>
>
>
>>
>> On Tuesday, February 18, 2020 at 5:44:32 AM UTC-5, Michael Brown wrote:
>>
>>
>>
>> On Tue, 18 Feb 2020, 11.39 Michael Brown  wrote:
>>
>> BTW the newest de10 SD images are around here:
>> https://github.com/the-snowwhite/soc-image-buildscripts
>>
>>
>> Look for binary releases
>>
>> Sorry for the messy mails but I'm currently in hospital attempting to get
>> thru via my phone...
>>
>>
>>
>> On Tue, 18 Feb 2020, 11.26 Michael Brown  wrote:
>>
>> It's unfortunately not as simple as the frame buffer is hardwired to the
>> display parameters in quartus. Resolution change requires changing the FB
>> parameters in quartus... Generating a new bit file and then generating an
>> altered device tree with the new display parameters.
>> Michael B.
>>
>> On Tue, 18 Feb 2020, 01.22 justin White  wrote:
>>
>> I know I've seen some resolution numbers in the quartus files so I
>> assumed this was using part of the FPGA to do a framebuffer or something
>> and it was actually part of the Quartus project. I thought the BBB actually
>> had a GPU unlike the nano. I'll definitely try it when I get a chance, the
>> 800x480 monitor looks like trash, even being small.hoping to pick up
>> and get this going on a 1024x600 version.
>>
>> I believe the de10-nano image here is the one I used
>> https://drive.google.com/drive/folders/1THXnrnt-v7iNownBqmdOQrJ-i8EVAsSZ
>>
>>
>>
>> On Monday, February 17, 2020 at 5:34:07 PM UTC-5, Charles Steinkuehler
>> wrote:
>>
>> I don't currently have a DE10-Nano running, but I reviewed the code and
>> it looks like you should be able to set the resolution the same as you
>> would for any other embedded display (by passing some kernel
>> parameters).  Refer to:
>>
>> * The modedb documentation:
>>
>> https://www.kernel.org/doc/Documentation/fb/modedb.txt
>>
>> * My posts on setting resolutions on the BBB:
>>
>>
>> http://blog.machinekit.io/2013/06/force-beaglebone-black-hdmi-resolution.html
>>
>> http://blog.machinekit.io/2013/07/custom
>> 
>>
>> ...
>
> --
> website: http://www.machinekit.io blog: http://blog.machinekit.io github:
> https://github.com/machinekit
> ---
> You received this message because you are subscribed to the Google Groups
> "Machinekit" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to machinekit+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/machinekit/ed43e04a-3763-43fe-afec-729f70f66203%40googlegroups.com
> 
> .
>

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/machinekit/CA%2BQ02MPdPOb5NTUXZp0qzoYq_uewcy3AtfyAyy0BuMoBw%3D2aSQ%40mail.gmail.com.

Re: [Machinekit] Re: DE10 Nano suggested development environment?

[Michael Brown]

I can only put up this proposal:
Generally speaking I would be nice to be able to change screen resolutions 
at runtime on the de10_nano board,
instead of having to generate a custom quartus hdmi bitfile and dtb for 
each resolution(screen) needed.

I once found a different de10 nano project on github that seemed to have 
this exact functionality:
https://github.com/MiSTer-devel

However at the time I investigated this project I was unable to nail down 
the exact commits/additions needed to port 
the change screen resolution functionality from the mister quartus project 
and the linux framebuffer driver. --> mksocfpga

perhaps with some helping hands this functionality can be ported over from 
the mister emulator.


On Saturday, February 22, 2020 at 9:58:21 PM UTC+1, justin White wrote:

Any plans to add this to the build script? Playing with Quartus isn't 
> something I generally love to do.
>

If some sort of group effort can be put into porting the resolution change 
mechanism from the mister project,
this will then result in an updated de10 mksocfpga project (with screen 
resolution change bitfiles) and also
an updated framebuffer driver (which goes into the kernel part of the 
buildscript)

 

>
> On Tuesday, February 18, 2020 at 5:44:32 AM UTC-5, Michael Brown wrote:
>
>
>
> On Tue, 18 Feb 2020, 11.39 Michael Brown  wrote:
>
> BTW the newest de10 SD images are around here: 
> https://github.com/the-snowwhite/soc-image-buildscripts
>
>
> Look for binary releases 
>
> Sorry for the messy mails but I'm currently in hospital attempting to get 
> thru via my phone... 
>
>
>
> On Tue, 18 Feb 2020, 11.26 Michael Brown  wrote:
>
> It's unfortunately not as simple as the frame buffer is hardwired to the 
> display parameters in quartus. Resolution change requires changing the FB 
> parameters in quartus... Generating a new bit file and then generating an 
> altered device tree with the new display parameters.
> Michael B. 
>
> On Tue, 18 Feb 2020, 01.22 justin White  wrote:
>
> I know I've seen some resolution numbers in the quartus files so I assumed 
> this was using part of the FPGA to do a framebuffer or something and it was 
> actually part of the Quartus project. I thought the BBB actually had a GPU 
> unlike the nano. I'll definitely try it when I get a chance, the 800x480 
> monitor looks like trash, even being small.hoping to pick up and get 
> this going on a 1024x600 version.
>
> I believe the de10-nano image here is the one I used
> https://drive.google.com/drive/folders/1THXnrnt-v7iNownBqmdOQrJ-i8EVAsSZ
>
>
>
> On Monday, February 17, 2020 at 5:34:07 PM UTC-5, Charles Steinkuehler 
> wrote:
>
> I don't currently have a DE10-Nano running, but I reviewed the code and 
> it looks like you should be able to set the resolution the same as you 
> would for any other embedded display (by passing some kernel 
> parameters).  Refer to: 
>
> * The modedb documentation: 
>
> https://www.kernel.org/doc/Documentation/fb/modedb.txt 
>
> * My posts on setting resolutions on the BBB: 
>
>
> http://blog.machinekit.io/2013/06/force-beaglebone-black-hdmi-resolution.html 
>
> http://blog.machinekit.io/2013/07/custom 
> 
>
> ...

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/machinekit/ed43e04a-3763-43fe-afec-729f70f66203%40googlegroups.com.

Re: [Machinekit] Re: DE10 Nano suggested development environment?

[justin White]

Any plans to add this to the build script? Playing with Quartus isn't 
something I generally love to do.

On Tuesday, February 18, 2020 at 5:44:32 AM UTC-5, Michael Brown wrote:
>
>
>
> On Tue, 18 Feb 2020, 11.39 Michael Brown  > wrote:
>
> BTW the newest de10 SD images are around here: 
> https://github.com/the-snowwhite/soc-image-buildscripts
>
>
> Look for binary releases 
>
> Sorry for the messy mails but I'm currently in hospital attempting to get 
> thru via my phone... 
>
>
>
> On Tue, 18 Feb 2020, 11.26 Michael Brown  > wrote:
>
> It's unfortunately not as simple as the frame buffer is hardwired to the 
> display parameters in quartus. Resolution change requires changing the FB 
> parameters in quartus... Generating a new bit file and then generating an 
> altered device tree with the new display parameters.
> Michael B. 
>
> On Tue, 18 Feb 2020, 01.22 justin White > 
> wrote:
>
> I know I've seen some resolution numbers in the quartus files so I assumed 
> this was using part of the FPGA to do a framebuffer or something and it was 
> actually part of the Quartus project. I thought the BBB actually had a GPU 
> unlike the nano. I'll definitely try it when I get a chance, the 800x480 
> monitor looks like trash, even being small.hoping to pick up and get 
> this going on a 1024x600 version.
>
> I believe the de10-nano image here is the one I used
> https://drive.google.com/drive/folders/1THXnrnt-v7iNownBqmdOQrJ-i8EVAsSZ
>
>
>
> On Monday, February 17, 2020 at 5:34:07 PM UTC-5, Charles Steinkuehler 
> wrote:
>
> I don't currently have a DE10-Nano running, but I reviewed the code and 
> it looks like you should be able to set the resolution the same as you 
> would for any other embedded display (by passing some kernel 
> parameters).  Refer to: 
>
> * The modedb documentation: 
>
> https://www.kernel.org/doc/Documentation/fb/modedb.txt 
>
> * My posts on setting resolutions on the BBB: 
>
>
> http://blog.machinekit.io/2013/06/force-beaglebone-black-hdmi-resolution.html 
>
> http://blog.machinekit.io/2013/07/custom-hdmi-resolution.html 
>
> I think you just need an entry similar to the following in your kernel 
> command line: 
>
>video=800x480M@60 
>
> Are you using an available uSD card image?  If so, I can pop it into my 
> DE10 and try to get it working with one of my small HDMI based LCD 
> screens if the above doesn't work for you. 
>
> On 2/16/2020 7:46 PM, justin White wrote: 
> > Been away from this project for a short bit but I had a pretty good use 
> > come up for it recently. Main thing I'm having a problem with is the FB 
> > resolution that was configured, 1024x768 is a dead resolution. Only old 
> > monitors natively support it and nothing with HDMI does. Larger HDMI 
> > monitors can handle it but nothing in the 7-9" range can display it 
> through 
> > HDMI. That's unfortunate because the main reason for FB use with this 
> thing 
> > is for an HMI all in one type device. Is there any chance more monitor 
> > resolutions can be supported? 
> > 
> > I asked this before and MB responded, but unfortunately this is over my 
> head 
> > 
> >> 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,
>
> ...

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/machinekit/873084cc-b4f3-450c-bc80-1434c138f8cb%40googlegroups.com.

Re: [Machinekit] Re: DE10 Nano suggested development environment?

[Michael Brown]

On Tue, 18 Feb 2020, 11.39 Michael Brown  wrote:

> BTW the newest de10 SD images are around here:
> https://github.com/the-snowwhite/soc-image-buildscripts
>
>>
>> Look for binary releases

Sorry for the messy mails but I'm currently in hospital attempting to get
thru via my phone...

>
>>
On Tue, 18 Feb 2020, 11.26 Michael Brown  wrote:
>
>> It's unfortunately not as simple as the frame buffer is hardwired to the
>> display parameters in quartus. Resolution change requires changing the FB
>> parameters in quartus... Generating a new bit file and then generating an
>> altered device tree with the new display parameters.
>> Michael B.
>>
>> On Tue, 18 Feb 2020, 01.22 justin White  wrote:
>>
>>> I know I've seen some resolution numbers in the quartus files so I
>>> assumed this was using part of the FPGA to do a framebuffer or something
>>> and it was actually part of the Quartus project. I thought the BBB actually
>>> had a GPU unlike the nano. I'll definitely try it when I get a chance, the
>>> 800x480 monitor looks like trash, even being small.hoping to pick up
>>> and get this going on a 1024x600 version.
>>>
>>> I believe the de10-nano image here is the one I used
>>> https://drive.google.com/drive/folders/1THXnrnt-v7iNownBqmdOQrJ-i8EVAsSZ
>>>
>>>
>>>
>>> On Monday, February 17, 2020 at 5:34:07 PM UTC-5, Charles Steinkuehler
>>> wrote:

 I don't currently have a DE10-Nano running, but I reviewed the code and
 it looks like you should be able to set the resolution the same as you
 would for any other embedded display (by passing some kernel
 parameters).  Refer to:

 * The modedb documentation:

 https://www.kernel.org/doc/Documentation/fb/modedb.txt

 * My posts on setting resolutions on the BBB:


 http://blog.machinekit.io/2013/06/force-beaglebone-black-hdmi-resolution.html

 http://blog.machinekit.io/2013/07/custom-hdmi-resolution.html

 I think you just need an entry similar to the following in your kernel
 command line:

video=800x480M@60

 Are you using an available uSD card image?  If so, I can pop it into my
 DE10 and try to get it working with one of my small HDMI based LCD
 screens if the above doesn't work for you.

 On 2/16/2020 7:46 PM, justin White wrote:
 > Been away from this project for a short bit but I had a pretty good
 use
 > come up for it recently. Main thing I'm having a problem with is the
 FB
 > resolution that was configured, 1024x768 is a dead resolution. Only
 old
 > monitors natively support it and nothing with HDMI does. Larger HDMI
 > monitors can handle it but nothing in the 7-9" range can display it
 through
 > HDMI. That's unfortunate because the main reason for FB use with this
 thing
 > is for an HMI all in one type device. Is there any chance more
 monitor
 > resolutions can be supported?
 >
 > I asked this before and MB responded, but unfortunately this is over
 my head
 >
 >> 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 m...
>>>
>>> --
>>> 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+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/machinekit/ad920189-10a0-4850-82f8-4436d5c20364%40googlegroups.com
>>> 
>>> .
>>>
>>

-- 

Re: [Machinekit] Re: DE10 Nano suggested development environment?

[Michael Brown]

BTW the newest de10 SD images are around here:
https://github.com/the-snowwhite/soc-image-buildscripts

On Tue, 18 Feb 2020, 11.26 Michael Brown  wrote:

> It's unfortunately not as simple as the frame buffer is hardwired to the
> display parameters in quartus. Resolution change requires changing the FB
> parameters in quartus... Generating a new bit file and then generating an
> altered device tree with the new display parameters.
> Michael B.
>
> On Tue, 18 Feb 2020, 01.22 justin White  wrote:
>
>> I know I've seen some resolution numbers in the quartus files so I
>> assumed this was using part of the FPGA to do a framebuffer or something
>> and it was actually part of the Quartus project. I thought the BBB actually
>> had a GPU unlike the nano. I'll definitely try it when I get a chance, the
>> 800x480 monitor looks like trash, even being small.hoping to pick up
>> and get this going on a 1024x600 version.
>>
>> I believe the de10-nano image here is the one I used
>> https://drive.google.com/drive/folders/1THXnrnt-v7iNownBqmdOQrJ-i8EVAsSZ
>>
>>
>>
>> On Monday, February 17, 2020 at 5:34:07 PM UTC-5, Charles Steinkuehler
>> wrote:
>>>
>>> I don't currently have a DE10-Nano running, but I reviewed the code and
>>> it looks like you should be able to set the resolution the same as you
>>> would for any other embedded display (by passing some kernel
>>> parameters).  Refer to:
>>>
>>> * The modedb documentation:
>>>
>>> https://www.kernel.org/doc/Documentation/fb/modedb.txt
>>>
>>> * My posts on setting resolutions on the BBB:
>>>
>>>
>>> http://blog.machinekit.io/2013/06/force-beaglebone-black-hdmi-resolution.html
>>>
>>> http://blog.machinekit.io/2013/07/custom-hdmi-resolution.html
>>>
>>> I think you just need an entry similar to the following in your kernel
>>> command line:
>>>
>>>video=800x480M@60
>>>
>>> Are you using an available uSD card image?  If so, I can pop it into my
>>> DE10 and try to get it working with one of my small HDMI based LCD
>>> screens if the above doesn't work for you.
>>>
>>> On 2/16/2020 7:46 PM, justin White wrote:
>>> > Been away from this project for a short bit but I had a pretty good
>>> use
>>> > come up for it recently. Main thing I'm having a problem with is the
>>> FB
>>> > resolution that was configured, 1024x768 is a dead resolution. Only
>>> old
>>> > monitors natively support it and nothing with HDMI does. Larger HDMI
>>> > monitors can handle it but nothing in the 7-9" range can display it
>>> through
>>> > HDMI. That's unfortunate because the main reason for FB use with this
>>> thing
>>> > is for an HMI all in one type device. Is there any chance more monitor
>>> > resolutions can be supported?
>>> >
>>> > I asked this before and MB responded, but unfortunately this is over
>>> my head
>>> >
>>> >> 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 m...
>>
>> --
>> 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+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/machinekit/ad920189-10a0-4850-82f8-4436d5c20364%40googlegroups.com
>> 
>> .
>>
>

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 

Re: [Machinekit] Re: DE10 Nano suggested development environment?

[Michael Brown]

It's unfortunately not as simple as the frame buffer is hardwired to the
display parameters in quartus. Resolution change requires changing the FB
parameters in quartus... Generating a new bit file and then generating an
altered device tree with the new display parameters.
Michael B.

On Tue, 18 Feb 2020, 01.22 justin White  wrote:

> I know I've seen some resolution numbers in the quartus files so I assumed
> this was using part of the FPGA to do a framebuffer or something and it was
> actually part of the Quartus project. I thought the BBB actually had a GPU
> unlike the nano. I'll definitely try it when I get a chance, the 800x480
> monitor looks like trash, even being small.hoping to pick up and get
> this going on a 1024x600 version.
>
> I believe the de10-nano image here is the one I used
> https://drive.google.com/drive/folders/1THXnrnt-v7iNownBqmdOQrJ-i8EVAsSZ
>
>
>
> On Monday, February 17, 2020 at 5:34:07 PM UTC-5, Charles Steinkuehler
> wrote:
>>
>> I don't currently have a DE10-Nano running, but I reviewed the code and
>> it looks like you should be able to set the resolution the same as you
>> would for any other embedded display (by passing some kernel
>> parameters).  Refer to:
>>
>> * The modedb documentation:
>>
>> https://www.kernel.org/doc/Documentation/fb/modedb.txt
>>
>> * My posts on setting resolutions on the BBB:
>>
>>
>> http://blog.machinekit.io/2013/06/force-beaglebone-black-hdmi-resolution.html
>>
>> http://blog.machinekit.io/2013/07/custom-hdmi-resolution.html
>>
>> I think you just need an entry similar to the following in your kernel
>> command line:
>>
>>video=800x480M@60
>>
>> Are you using an available uSD card image?  If so, I can pop it into my
>> DE10 and try to get it working with one of my small HDMI based LCD
>> screens if the above doesn't work for you.
>>
>> On 2/16/2020 7:46 PM, justin White wrote:
>> > Been away from this project for a short bit but I had a pretty good use
>> > come up for it recently. Main thing I'm having a problem with is the FB
>> > resolution that was configured, 1024x768 is a dead resolution. Only old
>> > monitors natively support it and nothing with HDMI does. Larger HDMI
>> > monitors can handle it but nothing in the 7-9" range can display it
>> through
>> > HDMI. That's unfortunate because the main reason for FB use with this
>> thing
>> > is for an HMI all in one type device. Is there any chance more monitor
>> > resolutions can be supported?
>> >
>> > I asked this before and MB responded, but unfortunately this is over my
>> head
>> >
>> >> 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 m...
>
> --
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/machinekit/ad920189-10a0-4850-82f8-4436d5c20364%40googlegroups.com
> 
> .
>

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/machinekit/CAGKWNWOqfEdkwJZW%3DMgACBt-K%2B_eubXt_2EKsH00dEyTenHmxw%40mail.gmail.com.

Re: [Machinekit] Re: DE10 Nano suggested development environment?

[justin White]

I know I've seen some resolution numbers in the quartus files so I assumed 
this was using part of the FPGA to do a framebuffer or something and it was 
actually part of the Quartus project. I thought the BBB actually had a GPU 
unlike the nano. I'll definitely try it when I get a chance, the 800x480 
monitor looks like trash, even being small.hoping to pick up and get 
this going on a 1024x600 version.

I believe the de10-nano image here is the one I used
https://drive.google.com/drive/folders/1THXnrnt-v7iNownBqmdOQrJ-i8EVAsSZ



On Monday, February 17, 2020 at 5:34:07 PM UTC-5, Charles Steinkuehler 
wrote:
>
> I don't currently have a DE10-Nano running, but I reviewed the code and 
> it looks like you should be able to set the resolution the same as you 
> would for any other embedded display (by passing some kernel 
> parameters).  Refer to: 
>
> * The modedb documentation: 
>
> https://www.kernel.org/doc/Documentation/fb/modedb.txt 
>
> * My posts on setting resolutions on the BBB: 
>
>
> http://blog.machinekit.io/2013/06/force-beaglebone-black-hdmi-resolution.html 
>
> http://blog.machinekit.io/2013/07/custom-hdmi-resolution.html 
>
> I think you just need an entry similar to the following in your kernel 
> command line: 
>
>video=800x480M@60 
>
> Are you using an available uSD card image?  If so, I can pop it into my 
> DE10 and try to get it working with one of my small HDMI based LCD 
> screens if the above doesn't work for you. 
>
> On 2/16/2020 7:46 PM, justin White wrote: 
> > Been away from this project for a short bit but I had a pretty good use 
> > come up for it recently. Main thing I'm having a problem with is the FB 
> > resolution that was configured, 1024x768 is a dead resolution. Only old 
> > monitors natively support it and nothing with HDMI does. Larger HDMI 
> > monitors can handle it but nothing in the 7-9" range can display it 
> through 
> > HDMI. That's unfortunate because the main reason for FB use with this 
> thing 
> > is for an HMI all in one type device. Is there any chance more monitor 
> > resolutions can be supported? 
> > 
> > I asked this before and MB responded, but unfortunately this is over my 
> head 
> > 
> >> 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 m...

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/machinekit/ad920189-10a0-4850-82f8-4436d5c20364%40googlegroups.com.

Re: [Machinekit] Re: DE10 Nano suggested development environment?

[Charles Steinkuehler]

I don't currently have a DE10-Nano running, but I reviewed the code and 
it looks like you should be able to set the resolution the same as you 
would for any other embedded display (by passing some kernel 
parameters).  Refer to:


* The modedb documentation:

https://www.kernel.org/doc/Documentation/fb/modedb.txt

* My posts on setting resolutions on the BBB:

http://blog.machinekit.io/2013/06/force-beaglebone-black-hdmi-resolution.html

http://blog.machinekit.io/2013/07/custom-hdmi-resolution.html

I think you just need an entry similar to the following in your kernel 
command line:


  video=800x480M@60

Are you using an available uSD card image?  If so, I can pop it into my 
DE10 and try to get it working with one of my small HDMI based LCD 
screens if the above doesn't work for you.


On 2/16/2020 7:46 PM, justin White wrote:

Been away from this project for a short bit but I had a pretty good use
come up for it recently. Main thing I'm having a problem with is the FB
resolution that was configured, 1024x768 is a dead resolution. Only old
monitors natively support it and nothing with HDMI does. Larger HDMI
monitors can handle it but nothing in the 7-9" range can display it through
HDMI. That's unfortunate because the main reason for FB use with this thing
is for an HMI all in one type device. Is there any chance more monitor
resolutions can be supported?

I asked this before and MB responded, but unfortunately this is over my head


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 = <0x0001 0x00031000 0x0080>;
max-width = <1024>;
max-height = <768>;
bits-per-color = <0x8>;
colors-per-beat = <0x4>;
beats-per-pixel = <0x1>;
mem-word-width = <0x80>;
};




--
Charles Steinkuehler
char...@steinkuehler.net

--
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups "Machinekit" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/machinekit/44b54b20-97af-8ed7-5a7c-56321da87915%40steinkuehler.net.

Re: [Machinekit] Re: DE10 Nano suggested development environment?

[justin White]

Been away from this project for a short bit but I had a pretty good use 
come up for it recently. Main thing I'm having a problem with is the FB 
resolution that was configured, 1024x768 is a dead resolution. Only old 
monitors natively support it and nothing with HDMI does. Larger HDMI 
monitors can handle it but nothing in the 7-9" range can display it through 
HDMI. That's unfortunate because the main reason for FB use with this thing 
is for an HMI all in one type device. Is there any chance more monitor 
resolutions can be supported?

I asked this before and MB responded, but unfortunately this is over my head

> 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 = <0x0001 0x00031000 0x0080>;
> max-width = <1024>;
> max-height = <768>;
> bits-per-color = <0x8>;
> colors-per-beat = <0x4>;
> beats-per-pixel = <0x1>;
> mem-word-width = <0x80>;
> };

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/machinekit/6cf3c076-6dd7-4d2a-a4f1-9ce9bc5d27d5%40googlegroups.com.

Re: [Machinekit] Re: DE10 Nano suggested development environment?

[Michael Brown]

@Justin
Ups 
I have been far away in Xilinx ultra96 land, and butchered the sys 
partition of my kde neon install in the process 
(installing debian Buster to what I thought was a spare/empty ssd ..)
Luckly the full Home partition was/is safe and I've just installed kdeneon 
again on a brand new samsunc evo 970 plus (2TB),
so I expect getting around to compiling your bitfile tomorrow...


On Thursday, 5 September 2019 07:45:45 UTC+2, justin White wrote:
>
> I had to make some changes to the pin routing of my board for the 
> encoders. I assume the quartus config changes haven't been applied to the 
> docker environment yet? 
>
> @ Michael, if not can you build firmware with this .vhd file?
>
>
>
> On Friday, August 30, 2019 at 12:12:02 AM UTC-4, justin White wrote:
>
> I haven't gotten to an Open source derivative just yet. 
>
> When I do it'll be in Kicad  that's what I use.
>
>  
> On Thursday, August 29, 2019 at 6:57:15 PM UTC-4, Michael Brown wrote:
>
> Perhaps even kicad compatible...
>
> On Friday, 30 August 2019 00:56:03 UTC+2, Michael Brown wrote:
>
> A board schematic (with pins connectors wires components etc...) ?
> preferably open source...
>
>
> On Thursday, 29 August 2019 23:42:04 UTC+2, justin White wrote:
>
> What are you looking for?
>
>
> On Thursday, August 29, 2019 at 1:00:54 PM UTC-4, Michael Brown wrote:
>
> @Justin
> Do you have a schematic available for your board ?
>
> On Wednesday, 28 August 2019 20:53:41 UTC+2, Michael Brown wrote:
>
> Yes
> It would certainly help my debug efforts here to have the physical 
> board(s) on hand. :-)
>
> I can PM you my street address when you have it build t and ready...
>
> On Wednesday, 2
>
> ...

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/machinekit/b2019943-46fa-4c24-aef1-921a71552185%40googlegroups.com.

Re: [Machinekit] Re: DE10 Nano suggested development environment?

[justin White]

I had to make some changes to the pin routing of my board for the encoders. 
I assume the quartus config changes haven't been applied to the docker 
environment yet? 

@ Michael, if not can you build firmware with this .vhd file?



On Friday, August 30, 2019 at 12:12:02 AM UTC-4, justin White wrote:
>
> I haven't gotten to an Open source derivative just yet. 
>
> When I do it'll be in Kicad  that's what I use.
>
>  
> On Thursday, August 29, 2019 at 6:57:15 PM UTC-4, Michael Brown wrote:
>
> Perhaps even kicad compatible...
>
> On Friday, 30 August 2019 00:56:03 UTC+2, Michael Brown wrote:
>
> A board schematic (with pins connectors wires components etc...) ?
> preferably open source...
>
>
> On Thursday, 29 August 2019 23:42:04 UTC+2, justin White wrote:
>
> What are you looking for?
>
>
> On Thursday, August 29, 2019 at 1:00:54 PM UTC-4, Michael Brown wrote:
>
> @Justin
> Do you have a schematic available for your board ?
>
> On Wednesday, 28 August 2019 20:53:41 UTC+2, Michael Brown wrote:
>
> Yes
> It would certainly help my debug efforts here to have the physical 
> board(s) on hand. :-)
>
> I can PM you my street address when you have it build t and ready...
>
> On Wednesday, 28 August 2019 03:54:49 UTC+2, justin White wrote:
>
> After looking at it I wonder if it is not just the 8i20 portion of SSerial 
> code has issues. I'm sort of at a loss as I'm not really sure what I'm 
> seeing. Like I said, if you want I can whip you up a board and send it to 
> you on the next run if you want 
>
> ...

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/machinekit/68b57455-6662-458b-a511-e3dddbe7371c%40googlegroups.com.


PIN_st_fpga_soc_dc1G_ss.vhd
Description: Binary data

Re: [Machinekit] Re: DE10 Nano suggested development environment?

[justin White]

I haven't gotten to an Open source derivative just yet. 

When I do it'll be in Kicad  that's what I use.

 
On Thursday, August 29, 2019 at 6:57:15 PM UTC-4, Michael Brown wrote:

> Perhaps even kicad compatible...
>
> On Friday, 30 August 2019 00:56:03 UTC+2, Michael Brown wrote:
>
> A board schematic (with pins connectors wires components etc...) ?
> preferably open source...
>
>
> On Thursday, 29 August 2019 23:42:04 UTC+2, justin White wrote:
>
> What are you looking for?
>
>
> On Thursday, August 29, 2019 at 1:00:54 PM UTC-4, Michael Brown wrote:
>
> @Justin
> Do you have a schematic available for your board ?
>
> On Wednesday, 28 August 2019 20:53:41 UTC+2, Michael Brown wrote:
>
> Yes
> It would certainly help my debug efforts here to have the physical 
> board(s) on hand. :-)
>
> I can PM you my street address when you have it build t and ready...
>
> On Wednesday, 28 August 2019 03:54:49 UTC+2, justin White wrote:
>
> After looking at it I wonder if it is not just the 8i20 portion of SSerial 
> code has issues. I'm sort of at a loss as I'm not really sure what I'm 
> seeing. Like I said, if you want I can whip you up a board and send it to 
> you on the next run if you want to debug this further. I just don't want to 
> give you bad info  since I'm not totally sure I understand why I'm getting 
> the results I'm getting.
>
>
> On Tuesday, August 27, 2019 at 8:26:00 PM UTC-4, justin White wrote:
>
> New deb is still not working for SS although the
>
> ...

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/machinekit/b33aed69-097a-4496-95c7-409d7fd69406%40googlegroups.com.

Re: [Machinekit] Re: DE10 Nano suggested development environment?

[Michael Brown]

Perhaps even kicad compatible...

On Friday, 30 August 2019 00:56:03 UTC+2, Michael Brown wrote:
>
> A board schematic (with pins connectors wires components etc...) ?
> preferably open source...
>
>
> On Thursday, 29 August 2019 23:42:04 UTC+2, justin White wrote:
>>
>> What are you looking for?
>>
>>
>> On Thursday, August 29, 2019 at 1:00:54 PM UTC-4, Michael Brown wrote:
>>>
>>> @Justin
>>> Do you have a schematic available for your board ?
>>>
>>> On Wednesday, 28 August 2019 20:53:41 UTC+2, Michael Brown wrote:
>>>
>>> Yes
>>> It would certainly help my debug efforts here to have the physical 
>>> board(s) on hand. :-)
>>>
>>> I can PM you my street address when you have it build t and ready...
>>>
>>> On Wednesday, 28 August 2019 03:54:49 UTC+2, justin White wrote:
>>>
>>> After looking at it I wonder if it is not just the 8i20 portion of 
>>> SSerial code has issues. I'm sort of at a loss as I'm not really sure what 
>>> I'm seeing. Like I said, if you want I can whip you up a board and send it 
>>> to you on the next run if you want to debug this further. I just don't want 
>>> to give you bad info  since I'm not totally sure I understand why I'm 
>>> getting the results I'm getting.
>>>
>>>
>>> On Tuesday, August 27, 2019 at 8:26:00 PM UTC-4, justin White wrote:
>>>
>>> New deb is still not working for SS although there is a minor change 
>>> that I did not see before. the card status light will blink once, then 
>>> fault, then status will blink again and fault. Previously the status light 
>>> only lit one time.
>>>
>>> On Tuesday, August 27, 2019 at 7:31:34 PM UTC-4, justin White wrote:
>>>
>>> It would certainly be nice to build firmware with docker  wi
>>>
>>> ...
>>
>>

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/machinekit/ec78cc47-8d23-4d14-8d51-82eebe5906a6%40googlegroups.com.

Re: [Machinekit] Re: DE10 Nano suggested development environment?

[Michael Brown]

A board schematic (with pins connectors wires components etc...) ?
preferably open source...


On Thursday, 29 August 2019 23:42:04 UTC+2, justin White wrote:
>
> What are you looking for?
>
>
> On Thursday, August 29, 2019 at 1:00:54 PM UTC-4, Michael Brown wrote:
>>
>> @Justin
>> Do you have a schematic available for your board ?
>>
>> On Wednesday, 28 August 2019 20:53:41 UTC+2, Michael Brown wrote:
>>
>> Yes
>> It would certainly help my debug efforts here to have the physical 
>> board(s) on hand. :-)
>>
>> I can PM you my street address when you have it build t and ready...
>>
>> On Wednesday, 28 August 2019 03:54:49 UTC+2, justin White wrote:
>>
>> After looking at it I wonder if it is not just the 8i20 portion of 
>> SSerial code has issues. I'm sort of at a loss as I'm not really sure what 
>> I'm seeing. Like I said, if you want I can whip you up a board and send it 
>> to you on the next run if you want to debug this further. I just don't want 
>> to give you bad info  since I'm not totally sure I understand why I'm 
>> getting the results I'm getting.
>>
>>
>> On Tuesday, August 27, 2019 at 8:26:00 PM UTC-4, justin White wrote:
>>
>> New deb is still not working for SS although there is a minor change that 
>> I did not see before. the card status light will blink once, then fault, 
>> then status will blink again and fault. Previously the status light only 
>> lit one time.
>>
>> On Tuesday, August 27, 2019 at 7:31:34 PM UTC-4, justin White wrote:
>>
>> It would certainly be nice to build firmware with docker  wi
>>
>> ...
>
>

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/machinekit/80aca0b7-d192-47f8-a0ef-b1ac1261b5b9%40googlegroups.com.

Re: [Machinekit] Re: DE10 Nano suggested development environment?

[justin White]

What are you looking for?


On Thursday, August 29, 2019 at 1:00:54 PM UTC-4, Michael Brown wrote:
>
> @Justin
> Do you have a schematic available for your board ?
>
> On Wednesday, 28 August 2019 20:53:41 UTC+2, Michael Brown wrote:
>
> Yes
> It would certainly help my debug efforts here to have the physical 
> board(s) on hand. :-)
>
> I can PM you my street address when you have it build t and ready...
>
> On Wednesday, 28 August 2019 03:54:49 UTC+2, justin White wrote:
>
> After looking at it I wonder if it is not just the 8i20 portion of SSerial 
> code has issues. I'm sort of at a loss as I'm not really sure what I'm 
> seeing. Like I said, if you want I can whip you up a board and send it to 
> you on the next run if you want to debug this further. I just don't want to 
> give you bad info  since I'm not totally sure I understand why I'm getting 
> the results I'm getting.
>
>
> On Tuesday, August 27, 2019 at 8:26:00 PM UTC-4, justin White wrote:
>
> New deb is still not working for SS although there is a minor change that 
> I did not see before. the card status light will blink once, then fault, 
> then status will blink again and fault. Previously the status light only 
> lit one time.
>
> On Tuesday, August 27, 2019 at 7:31:34 PM UTC-4, justin White wrote:
>
> It would certainly be nice to build firmware with docker  wi
>
> ...

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/machinekit/a0600341-877a-419d-b3db-a59f3f167f4b%40googlegroups.com.

Re: [Machinekit] Re: DE10 Nano suggested development environment?

[Michael Brown]

@Justin
Do you have a schematic available for your board ?

On Wednesday, 28 August 2019 20:53:41 UTC+2, Michael Brown wrote:
>
> Yes
> It would certainly help my debug efforts here to have the physical 
> board(s) on hand. :-)
>
> I can PM you my street address when you have it build t and ready...
>
> On Wednesday, 28 August 2019 03:54:49 UTC+2, justin White wrote:
>
> After looking at it I wonder if it is not just the 8i20 portion of SSerial 
> code has issues. I'm sort of at a loss as I'm not really sure what I'm 
> seeing. Like I said, if you want I can whip you up a board and send it to 
> you on the next run if you want to debug this further. I just don't want to 
> give you bad info  since I'm not totally sure I understand why I'm getting 
> the results I'm getting.
>
>
> On Tuesday, August 27, 2019 at 8:26:00 PM UTC-4, justin White wrote:
>
> New deb is still not working for SS although there is a minor change that 
> I did not see before. the card status light will blink once, then fault, 
> then status will blink again and fault. Previously the status light only 
> lit one time.
>
> On Tuesday, August 27, 2019 at 7:31:34 PM UTC-4, justin White wrote:
>
> It would certainly be nice to build firmware with docker  with the Quartus 
> fixes you've made to the DExx_cramps config, in case I come up with some 
> other hardware.
>
> On Tuesday, August 27, 2019 at 5:41:28 AM UTC-4, Michael Brown wrote:
>
> That PR is waiting for the finalizing your pin file:
>
> ...

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/machinekit/0f364457-56d4-4655-9f9b-91712292ea25%40googlegroups.com.

Re: [Machinekit] Re: DE10 Nano suggested development environment?

[Michael Brown]

Yes
It would certainly help my debug efforts here to have the physical board(s) 
on hand. :-)

I can PM you my street address when you have it build t and ready...

On Wednesday, 28 August 2019 03:54:49 UTC+2, justin White wrote:
>
> After looking at it I wonder if it is not just the 8i20 portion of SSerial 
> code has issues. I'm sort of at a loss as I'm not really sure what I'm 
> seeing. Like I said, if you want I can whip you up a board and send it to 
> you on the next run if you want to debug this further. I just don't want to 
> give you bad info  since I'm not totally sure I understand why I'm getting 
> the results I'm getting.
>
>
> On Tuesday, August 27, 2019 at 8:26:00 PM UTC-4, justin White wrote:
>
> New deb is still not working for SS although there is a minor change that 
> I did not see before. the card status light will blink once, then fault, 
> then status will blink again and fault. Previously the status light only 
> lit one time.
>
> On Tuesday, August 27, 2019 at 7:31:34 PM UTC-4, justin White wrote:
>
> It would certainly be nice to build firmware with docker  with the Quartus 
> fixes you've made to the DExx_cramps config, in case I come up with some 
> other hardware.
>
> On Tuesday, August 27, 2019 at 5:41:28 AM UTC-4, Michael Brown wrote:
>
> That PR is waiting for the finalizing your pin file:
> https://github.com/the-snowwhite/mksocfpga/blob/sserial-work/HW/hm2/ 
> 
>
> ...

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/machinekit/c0fc5719-fecb-4904-a4ac-ac3f813a5808%40googlegroups.com.

Re: [Machinekit] Re: DE10 Nano suggested development environment?

[justin White]

After looking at it I wonder if it is not just the 8i20 portion of SSerial 
code has issues. I'm sort of at a loss as I'm not really sure what I'm 
seeing. Like I said, if you want I can whip you up a board and send it to 
you on the next run if you want to debug this further. I just don't want to 
give you bad info  since I'm not totally sure I understand why I'm getting 
the results I'm getting.


On Tuesday, August 27, 2019 at 8:26:00 PM UTC-4, justin White wrote:
>
> New deb is still not working for SS although there is a minor change that 
> I did not see before. the card status light will blink once, then fault, 
> then status will blink again and fault. Previously the status light only 
> lit one time.
>
> On Tuesday, August 27, 2019 at 7:31:34 PM UTC-4, justin White wrote:
>
> It would certainly be nice to build firmware with docker  with the Quartus 
> fixes you've made to the DExx_cramps config, in case I come up with some 
> other hardware.
>
> On Tuesday, August 27, 2019 at 5:41:28 AM UTC-4, Michael Brown wrote:
>
> That PR is waiting for the finalizing your pin file:
>
> https://github.com/the-snowwhite/mksocfpga/blob/sserial-work/HW/hm2/config/DExx_Nano_xxx_Cramps/PIN_st_fpga_soc_dc1f_ss.vhd
>
>
> after the PR is then commited and approved:
> When the MKSocfpga changes are merged the changes will show up in the mk 
> deb (socfpga-rbf) packages,
> then you don't have to build yourself.
>
>
>
>
> On Tuesday, 27 August 2019 00:51:56 UTC+2, justin White wrote:
>
> BTW, have the 
>
> ...

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/machinekit/d65ef8ba-0d7e-410f-a03b-455aec6f937d%40googlegroups.com.

Re: [Machinekit] Re: DE10 Nano suggested development environment?

[justin White]

It would certainly be nice to build firmware with docker  with the Quartus 
fixes you've made to the DExx_cramps config, in case I come up with some 
other hardware.

On Tuesday, August 27, 2019 at 5:41:28 AM UTC-4, Michael Brown wrote:
>
> That PR is waiting for the finalizing your pin file:
>
> https://github.com/the-snowwhite/mksocfpga/blob/sserial-work/HW/hm2/config/DExx_Nano_xxx_Cramps/PIN_st_fpga_soc_dc1f_ss.vhd
>
>
> after the PR is then commited and approved:
> When the MKSocfpga changes are merged the changes will show up in the mk 
> deb (socfpga-rbf) packages,
> then you don't have to build yourself.
>
>
>
>
> On Tuesday, 27 August 2019 00:51:56 UTC+2, justin White wrote:
>>
>> BTW, have the DExx-cramps changes been merged in a way that I can do a 
>> docker build on my end yet?
>>
>> On Monday, August 26, 2019 at 6:49:23 PM UTC-4, justin White wrote:
>>>
>>> There are comm errors thrown after discovery as mentioned on git, trying 
>>> to determine if its the hardware or MK's hm2 driver ATM,  Still a bit 
>>> difficult to determine without a verifiable working instance of SS in 
>>> current MK systems.
>>>
>>>

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/machinekit/a5eb5f58-37b7-4114-af42-a8d8dcd80c96%40googlegroups.com.

Re: [Machinekit] Re: DE10 Nano suggested development environment?

[Michael Brown]

That PR is waiting for the finalizing your pin file:
https://github.com/the-snowwhite/mksocfpga/blob/sserial-work/HW/hm2/config/DExx_Nano_xxx_Cramps/PIN_st_fpga_soc_dc1f_ss.vhd


after the PR is then commited and approved:
When the MKSocfpga changes are merged the changes will show up in the mk 
deb (socfpga-rbf) packages,
then you don't have to build yourself.




On Tuesday, 27 August 2019 00:51:56 UTC+2, justin White wrote:
>
> BTW, have the DExx-cramps changes been merged in a way that I can do a 
> docker build on my end yet?
>
> On Monday, August 26, 2019 at 6:49:23 PM UTC-4, justin White wrote:
>>
>> There are comm errors thrown after discovery as mentioned on git, trying 
>> to determine if its the hardware or MK's hm2 driver ATM,  Still a bit 
>> difficult to determine without a verifiable working instance of SS in 
>> current MK systems.
>>
>>

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/machinekit/adcf4609-5ccb-429d-92af-112a75fb43a1%40googlegroups.com.

Re: [Machinekit] Re: DE10 Nano suggested development environment?

[justin White]

BTW, have the DExx-cramps changes been merged in a way that I can do a 
docker build on my end yet?

On Monday, August 26, 2019 at 6:49:23 PM UTC-4, justin White wrote:
>
> There are comm errors thrown after discovery as mentioned on git, trying 
> to determine if its the hardware or MK's hm2 driver ATM,  Still a bit 
> difficult to determine without a verifiable working instance of SS in 
> current MK systems.
>
>

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/machinekit/7ee3d35c-bdf4-42e2-9de4-be1253325d4f%40googlegroups.com.

Re: [Machinekit] Re: DE10 Nano suggested development environment?

[justin White]

There are comm errors thrown after discovery as mentioned on git, trying to 
determine if its the hardware or MK's hm2 driver ATM,  Still a bit 
difficult to determine without a verifiable working instance of SS in 
current MK systems.

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/machinekit/fc955b72-3b27-4f26-9b53-f2f076ee2c04%40googlegroups.com.

Re: [Machinekit] Re: DE10 Nano suggested development environment?

[justin White]

Holy 

machinekit@mksocfpga-nano-soc:~$ halrun
msgd:0 running
rtapi:0 running
halrun: Realtime already running.  Use 'halrun -U' to stop existing
realtime session.
machinekit@mksocfpga-nano-soc:~$ halrun -U
machinekit@mksocfpga-nano-soc:~$ halrun
msgd:0 stopped
rtapi:0 stopped
rtapi_msgd command:  /usr/libexec/linuxcnc/rtapi_msgd --instance=0
--rtmsglevel=1 --usrmsglevel=1 --halsize=524288
rtapi_app command:  /usr/libexec/linuxcnc/rtapi_app_rt-preempt --instance=0
halcmd: source ~/Desktop/SS_Test_MK.halrun
halcmd: show pin *8i20*
Component Pins:
  Comp   Inst Type  Dir Value  Name
   Epsilon Flags  linked to:
   517519 float IN  0  hm2_5i25.0.8i20.0.0.angle
  0.10--l-
   517519 float OUT 0  hm2_5i25.0.8i20.0.0.bus-voltage
  0.10--l-
   517519 float OUT 0  hm2_5i25.0.8i20.0.0.card-temp
  0.10--l-
   517519 float IN  0  hm2_5i25.0.8i20.0.0.current
  0.10--l-
   517519 bit   OUT FALSE  hm2_5i25.0.8i20.0.0.fault.U-current
  --l-
   517519 bit   OUT FALSE
 hm2_5i25.0.8i20.0.0.fault.U-current-not   --l-
   517519 bit   OUT FALSE  hm2_5i25.0.8i20.0.0.fault.V-current
  --l-
   517519 bit   OUT FALSE
 hm2_5i25.0.8i20.0.0.fault.V-current-not   --l-
   517519 bit   OUT FALSE  hm2_5i25.0.8i20.0.0.fault.W-current
  --l-
   517519 bit   OUT FALSE
 hm2_5i25.0.8i20.0.0.fault.W-current-not   --l-
   517519 bit   OUT FALSE  hm2_5i25.0.8i20.0.0.fault.bus-high
 --l-
   517519 bit   OUT FALSE
 hm2_5i25.0.8i20.0.0.fault.bus-high-not--l-
   517519 bit   OUT FALSE  hm2_5i25.0.8i20.0.0.fault.bus-overv
  --l-
   517519 bit   OUT FALSE
 hm2_5i25.0.8i20.0.0.fault.bus-overv-not   --l-
   517519 bit   OUT FALSE  hm2_5i25.0.8i20.0.0.fault.bus-underv
 --l-
   517519 bit   OUT FALSE
 hm2_5i25.0.8i20.0.0.fault.bus-underv-not  --l-
   517519 bit   OUT FALSE  hm2_5i25.0.8i20.0.0.fault.framingr
 --l-
   517519 bit   OUT FALSE
 hm2_5i25.0.8i20.0.0.fault.framingr-not--l-
   517519 bit   OUT FALSE  hm2_5i25.0.8i20.0.0.fault.module
 --l-
   517519 bit   OUT FALSE  hm2_5i25.0.8i20.0.0.fault.module-not
 --l-
   517519 bit   OUT FALSE  hm2_5i25.0.8i20.0.0.fault.no-enable
  --l-
   517519 bit   OUT FALSE
 hm2_5i25.0.8i20.0.0.fault.no-enable-not   --l-
   517519 bit   OUT FALSE
 hm2_5i25.0.8i20.0.0.fault.overcurrent --l-
   517519 bit   OUT FALSE
 hm2_5i25.0.8i20.0.0.fault.overcurrent-no  --l-
   517519 bit   OUT FALSE  hm2_5i25.0.8i20.0.0.fault.overrun
  --l-
   517519 bit   OUT FALSE
 hm2_5i25.0.8i20.0.0.fault.overrun-not --l-
   517519 bit   OUT FALSE  hm2_5i25.0.8i20.0.0.fault.overtemp
 --l-
   517519 bit   OUT FALSE
 hm2_5i25.0.8i20.0.0.fault.overtemp-not--l-
   517519 bit   OUT FALSE  hm2_5i25.0.8i20.0.0.fault.watchdog
 --l-
   517519 bit   OUT FALSE
 hm2_5i25.0.8i20.0.0.fault.watchdog-not--l-
   517519 bit   OUT FALSE  hm2_5i25.0.8i20.0.0.status.brake-old
 --l-
   517519 bit   OUT FALSE
 hm2_5i25.0.8i20.0.0.status.brake-old-not  --l-
   517519 bit   OUT FALSE  hm2_5i25.0.8i20.0.0.status.brake-on
  --l-
   517519 bit   OUT FALSE
 hm2_5i25.0.8i20.0.0.status.brake-on-not   --l-
   517519 bit   OUT FALSE
 hm2_5i25.0.8i20.0.0.status.bus-underv --l-
   517519 bit   OUT FALSE
 hm2_5i25.0.8i20.0.0.status.bus-underv-no  --l-
   517519 bit   OUT FALSE
 hm2_5i25.0.8i20.0.0.status.current-lim--l-
   517519 bit   OUT FALSE
 hm2_5i25.0.8i20.0.0.status.current-lim-n  --l-
   517519 bit   OUT FALSE  hm2_5i25.0.8i20.0.0.status.ext-reset
 --l-
   517519 bit   OUT FALSE
 hm2_5i25.0.8i20.0.0.status.ext-reset-not  --l-
   517519 bit   OUT FALSE  hm2_5i25.0.8i20.0.0.status.no-enable
 --l-
   517519 bit   OUT FALSE
 hm2_5i25.0.8i20.0.0.status.no-enable-not  --l-
   517519 bit   OUT FALSE  hm2_5i25.0.8i20.0.0.status.pid-on
  --l-
   517519 bit   OUT FALSE
 hm2_5i25.0.8i20.0.0.status.pid-on-not --l-
   517519 bit   OUT FALSE  hm2_5i25.0.8i20.0.0.status.sw-reset
  --l-
   517519 bit   OUT FALSE
 hm2_5i25.0.8i20.0.0.status.sw-reset-not   --l-
   517519 bit   OUT FALSE  

Re: [Machinekit] Re: DE10 Nano suggested development environment?

[Michael Brown]

mk-hal deb for test with sserial parse only mod.
Due to the number of changes I choose to creative a conservative change 
only modding the:
hm2_sserial_parse_md() function, this is what does the intial probing and 
pin setting..
The file you should use I think is:
 machinekit-hal-rt-preempt_0.2.1566764039.gitf3af8e09e-1~stretch_armhf.deb

I added the other one just in case...

On Saturday, 24 August 2019 20:19:36 UTC+2, Michael Brown wrote:
>
> Got some scope results:
> https://github.com/machinekit/mksocfpga/issues/107#issuecomment-524570613
>
>
> On Saturday, 24 August 2019 19:31:04 UTC+2, justin White wrote:
>
> @Michael, if ya need any info from my LCNC machine let me know. It's not 
> MK but it does have a working SS setup that's easy to check.
>
> Also, if it makes it any easier for you to test anything I'm about to 
> order what's hopefully my final board rev. I can whip you one up and send 
> it your way, might be useful if you get an SS remote on hand.
>
> On Saturday, August 24, 2019 at 1:20:09 PM UTC-4, justin White wrote:
>
> I'm not sure if this helps you but SS pins always look like normal I/O if 
> they don't detect a remote on the channel after coming up. Since I have it 
> out I connected the 8i20 to my project machine's 7i96 that I don't 
> typically use SS with. This is LinuxCNC 2.8pre1
>
> No 8i20 connected, note IO pins 30 and 31:
> shade@Viewer:~$ halrun
> halcmd: source /home/shade/linuxcnc/SS_Test.halrun 
> Note: Using POSIX realtime
> hm2: loading Mesa HostMot2 driver version 0.15
> hm2_eth: loading Mesa AnyIO HostMot2 ethernet driver version 0.2
> hm2_eth: 10.10.10.10: Hardware address: 00:60:1b:16:00:21
> hm2_eth: discovered 7I96
> hm2/hm2_7i96.0: Smart Serial Firmware Version 43
> hm2/hm2_7i96.0: 51 I/O Pins used:
> hm2/hm2_7i96.0: IO Pin 000 (TB3-01): IOPort
> hm2/hm2_7i96.0: IO Pin 001 (TB3-02): IOPort
> hm2/hm2_7i96.0: IO Pin 002 (TB3-03): IOPort
> hm2/hm2_7i96.0: IO Pin 003 (TB3-04): IOPort
> hm2/hm2_7i96.0: IO Pin 004 (TB3-05): IOPort
> hm2/hm2_7i96.0: IO Pin 005 (TB3-06): IOPort
> hm2/hm2_7i96.0: IO Pin 006 (TB3-07): IOPort
> hm2/hm2_7i96.0: IO Pin 007 (TB3-08): IOPort
> hm2/hm2_7i96.0: IO Pin 008 (TB3-09): IOPort
> hm2/hm2_7i96.0: IO Pin 009 (TB3-10): IOPort
> hm2/hm2_7i96.0: IO Pin 010 (TB3-11): IOPort
> hm2/hm2_7i96.0: IO Pin 011 (TB3-13/TB3-14): SSR #0, pin Out-00 (Output)
> hm2/hm2_7i96.0: IO Pin 012 (TB3-15/TB3-16): SSR #0, pin Out-01 (Output)
> hm2/hm2_7i96.0: IO Pin 013 (TB3-17/TB3-18): SSR #0, pin Out-02 (Output)
> hm2/hm2_7i96.0: IO Pin 014 (TB3-19/TB3-20): SSR #0, pin Out-03 (Output)
> hm2/hm2_7i96.0: IO Pin 015 (TB3-21/TB3-22): SSR #0, pin Out-04 (Output)
> hm2/hm2_7i96.0: IO Pin 016 (TB3-23/TB3-24): SSR #0, pin Out-05 (Output)
> hm2/hm2_7i96.0: IO Pin 017 (TB1-02/TB1-03): StepGen #0, pin Step 
> (Output)
> hm2/hm2_7i96.0: IO Pin 018 (TB1-04/TB1-05): StepGen #0, pin Direction 
> (Output)
> hm2/hm2_7i96.0: IO Pin 019 (TB1-08/TB1-09): StepGen #1, pin Step 
> (Output)
> hm2/hm2_7i96.0: IO Pin 020 (TB1-10/TB1-11): StepGen #1, pin Direction 
> (Output)
> hm2/hm2_7i96.0: IO Pin 021 (TB1-14/TB1-15): StepGen #2, pin Step 
> (Output)
> hm2/hm2_7i96.0: IO Pin 022 (TB1-16/TB1-17): StepGen #2, pin Direction 
> (Output)
> hm2/hm2_7i96.0: IO Pin 023 (TB1-20/TB1-21): StepGen #3, pin Step 
> (Output)
> hm2/hm2_7i96.0: IO Pin 024 (TB1-22-TB1-23): StepGen #3, pin Direction 
> (Output)
> hm2/hm2_7i96.0: IO Pin 025 (TB2-01/TB2-03): StepGen #4, pin Step 
> (Output)
> hm2/hm2_7i96.0: IO Pin 026 (TB2-04/TB2-05): StepGen #4, pin Direction 
> (Output)
> hm2/hm2_7i96.0: IO Pin 027 (TB2-07/TB2-08): Encoder #0, pin A (Input)
> hm2/hm2_7i96.0: IO Pin 028 (TB2-10/TB2-11): Encoder #0, pin B (Input)
> hm2/hm2_7i96.0: IO Pin 029 (TB2-13/TB2-14): Encoder #0, pin Index 
> (Input)
> hm2/hm2_7i96.0: IO Pin 030 (TB2-16/TB2-17): IOPort
> hm2/hm2_7i96.0: IO Pin 031 (TB2-18/TB2-19): IOPort
> hm2/hm2_7i96.0: IO Pin 032 (internal): IOPort
> hm2/hm2_7i96.0: IO Pin 033 (internal): SSR #0, pin AC Ref (internal) 
> (Output)
> hm2/hm2_7i96.0: IO Pin 034 (P1-01): IOPort
> hm2/hm2_7i96.0: IO Pin 035 (P1-02): IOPort
> hm2/hm2_7i96.0: IO Pin 036 (P1-03): IOPort
> hm2/hm2_7i96.0: IO Pin 037 (P1-04): IOPort
> hm2/hm2_7i96.0: IO Pin 038 (P1-05): IOPort
> hm2/hm2_7i96.0: IO Pin 039 (P1-06): IOPort
> hm2/hm2_7i96.0: IO Pin 040 (P1-07): IOPort
> hm2/hm2_7i96.0: IO Pin 041 (P1-08): IOPort
> hm2/hm2_7i96.0: IO Pin 042 (P1-09): IOPort
> hm2/hm2_7i96.0: IO Pin 043 (P1-11): IOPort
> hm2/hm2_7i96.0: IO Pin 044 (P1-13): IOPort
> hm2/hm2_7i96.0: IO Pin 045 (P1-15): IOPort
> hm2/hm2_7i96.0: IO Pin 046 (P1-17): IOPort
> hm2/hm2_7i96.0: IO Pin 047 (P1-19): IOPort
> hm2/hm2_7i96.0: IO Pin 048 (P1-21): IOPort
> hm2/hm2_7i96.0: IO Pin 049 (P1-23): IOPort
> hm2/hm2_7i96.0: IO Pin 050 (P1-25): IOPort
> hm2/hm2_7i96.0: registered
>
>

Re: [Machinekit] Re: DE10 Nano suggested development environment?

[Michael Brown]

On Saturday, 24 August 2019 21:00:26 UTC+2, Michael Brown wrote:
>
>
>
> On Saturday, 24 August 2019 20:59:01 UTC+2, Michael Brown wrote:
>>
>> This is my second Picoscope and I'm very content both with the Linux 
>> software, eventhough it still (last time I looked) has beta status... and 
>> the HW off course :-)
>>
>> On Saturday, 24 August 2019 20:44:38 UTC+2, justin White wrote:
>>>
>>> How do you like that scope? I had my Owon 1022I running on my last Linux 
>>> install with hacked up windows/Java software. Can't get it working on the 
>>> new system and I'd rather have something that had native Linux software, or 
>>> just a normal scope.
>>>
>>>
> Currently running it on KDENeon 18.04
>
Sorry for the typo above its a:
Picoscope 3206D MSO 
https://www.picotech.com/oscilloscope/3000/usb3-oscilloscope-logic-analyzer

 
>

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/machinekit/04f61517-ea82-402c-978c-ef3ba6ab3ca3%40googlegroups.com.

Re: [Machinekit] Re: DE10 Nano suggested development environment?

[Michael Brown]

On Saturday, 24 August 2019 20:59:01 UTC+2, Michael Brown wrote:
>
> This is my second Picoscope and I'm very content both with the Linux 
> software, eventhough it still (last time I looked) has beta status... and 
> the HW off course :-)
>
> On Saturday, 24 August 2019 20:44:38 UTC+2, justin White wrote:
>>
>> How do you like that scope? I had my Owon 1022I running on my last Linux 
>> install with hacked up windows/Java software. Can't get it working on the 
>> new system and I'd rather have something that had native Linux software, or 
>> just a normal scope.
>>
>>
Currently running it on KDENeon 18.04 

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/machinekit/a907054d-f0b0-417a-8fe1-52039afec53c%40googlegroups.com.

Re: [Machinekit] Re: DE10 Nano suggested development environment?

[justin White]

How do you like that scope? I had my Owon 1022I running on my last Linux
install with hacked up windows/Java software. Can't get it working on the
new system and I'd rather have something that had native Linux software, or
just a normal scope.

On Sat, Aug 24, 2019 at 2:19 PM Michael Brown 
wrote:

> Got some scope results:
> https://github.com/machinekit/mksocfpga/issues/107#issuecomment-524570613
>
>
> On Saturday, 24 August 2019 19:31:04 UTC+2, justin White wrote:
>>
>> @Michael, if ya need any info from my LCNC machine let me know. It's not
>> MK but it does have a working SS setup that's easy to check.
>>
>> Also, if it makes it any easier for you to test anything I'm about to
>> order what's hopefully my final board rev. I can whip you one up and send
>> it your way, might be useful if you get an SS remote on hand.
>>
>> On Saturday, August 24, 2019 at 1:20:09 PM UTC-4, justin White wrote:
>>>
>>> I'm not sure if this helps you but SS pins always look like normal I/O
>>> if they don't detect a remote on the channel after coming up. Since I have
>>> it out I connected the 8i20 to my project machine's 7i96 that I don't
>>> typically use SS with. This is LinuxCNC 2.8pre1
>>>
>>> No 8i20 connected, note IO pins 30 and 31:
>>> shade@Viewer:~$ halrun
>>> halcmd: source /home/shade/linuxcnc/SS_Test.halrun
>>> Note: Using POSIX realtime
>>> hm2: loading Mesa HostMot2 driver version 0.15
>>> hm2_eth: loading Mesa AnyIO HostMot2 ethernet driver version 0.2
>>> hm2_eth: 10.10.10.10: Hardware address: 00:60:1b:16:00:21
>>> hm2_eth: discovered 7I96
>>> hm2/hm2_7i96.0: Smart Serial Firmware Version 43
>>> hm2/hm2_7i96.0: 51 I/O Pins used:
>>> hm2/hm2_7i96.0: IO Pin 000 (TB3-01): IOPort
>>> hm2/hm2_7i96.0: IO Pin 001 (TB3-02): IOPort
>>> hm2/hm2_7i96.0: IO Pin 002 (TB3-03): IOPort
>>> hm2/hm2_7i96.0: IO Pin 003 (TB3-04): IOPort
>>> hm2/hm2_7i96.0: IO Pin 004 (TB3-05): IOPort
>>> hm2/hm2_7i96.0: IO Pin 005 (TB3-06): IOPort
>>> hm2/hm2_7i96.0: IO Pin 006 (TB3-07): IOPort
>>> hm2/hm2_7i96.0: IO Pin 007 (TB3-08): IOPort
>>> hm2/hm2_7i96.0: IO Pin 008 (TB3-09): IOPort
>>> hm2/hm2_7i96.0: IO Pin 009 (TB3-10): IOPort
>>> hm2/hm2_7i96.0: IO Pin 010 (TB3-11): IOPort
>>> hm2/hm2_7i96.0: IO Pin 011 (TB3-13/TB3-14): SSR #0, pin Out-00
>>> (Output)
>>> hm2/hm2_7i96.0: IO Pin 012 (TB3-15/TB3-16): SSR #0, pin Out-01
>>> (Output)
>>> hm2/hm2_7i96.0: IO Pin 013 (TB3-17/TB3-18): SSR #0, pin Out-02
>>> (Output)
>>> hm2/hm2_7i96.0: IO Pin 014 (TB3-19/TB3-20): SSR #0, pin Out-03
>>> (Output)
>>> hm2/hm2_7i96.0: IO Pin 015 (TB3-21/TB3-22): SSR #0, pin Out-04
>>> (Output)
>>> hm2/hm2_7i96.0: IO Pin 016 (TB3-23/TB3-24): SSR #0, pin Out-05
>>> (Output)
>>> hm2/hm2_7i96.0: IO Pin 017 (TB1-02/TB1-03): StepGen #0, pin Step
>>> (Output)
>>> hm2/hm2_7i96.0: IO Pin 018 (TB1-04/TB1-05): StepGen #0, pin
>>> Direction (Output)
>>> hm2/hm2_7i96.0: IO Pin 019 (TB1-08/TB1-09): StepGen #1, pin Step
>>> (Output)
>>> hm2/hm2_7i96.0: IO Pin 020 (TB1-10/TB1-11): StepGen #1, pin
>>> Direction (Output)
>>> hm2/hm2_7i96.0: IO Pin 021 (TB1-14/TB1-15): StepGen #2, pin Step
>>> (Output)
>>> hm2/hm2_7i96.0: IO Pin 022 (TB1-16/TB1-17): StepGen #2, pin
>>> Direction (Output)
>>> hm2/hm2_7i96.0: IO Pin 023 (TB1-20/TB1-21): StepGen #3, pin Step
>>> (Output)
>>> hm2/hm2_7i96.0: IO Pin 024 (TB1-22-TB1-23): StepGen #3, pin
>>> Direction (Output)
>>> hm2/hm2_7i96.0: IO Pin 025 (TB2-01/TB2-03): StepGen #4, pin Step
>>> (Output)
>>> hm2/hm2_7i96.0: IO Pin 026 (TB2-04/TB2-05): StepGen #4, pin
>>> Direction (Output)
>>> hm2/hm2_7i96.0: IO Pin 027 (TB2-07/TB2-08): Encoder #0, pin A (Input)
>>> hm2/hm2_7i96.0: IO Pin 028 (TB2-10/TB2-11): Encoder #0, pin B (Input)
>>> hm2/hm2_7i96.0: IO Pin 029 (TB2-13/TB2-14): Encoder #0, pin Index
>>> (Input)
>>> hm2/hm2_7i96.0: IO Pin 030 (TB2-16/TB2-17): IOPort
>>> hm2/hm2_7i96.0: IO Pin 031 (TB2-18/TB2-19): IOPort
>>> hm2/hm2_7i96.0: IO Pin 032 (internal): IOPort
>>> hm2/hm2_7i96.0: IO Pin 033 (internal): SSR #0, pin AC Ref (internal)
>>> (Output)
>>> hm2/hm2_7i96.0: IO Pin 034 (P1-01): IOPort
>>> hm2/hm2_7i96.0: IO Pin 035 (P1-02): IOPort
>>> hm2/hm2_7i96.0: IO Pin 036 (P1-03): IOPort
>>> hm2/hm2_7i96.0: IO Pin 037 (P1-04): IOPort
>>> hm2/hm2_7i96.0: IO Pin 038 (P1-05): IOPort
>>> hm2/hm2_7i96.0: IO Pin 039 (P1-06): IOPort
>>> hm2/hm2_7i96.0: IO Pin 040 (P1-07): IOPort
>>> hm2/hm2_7i96.0: IO Pin 041 (P1-08): IOPort
>>> hm2/hm2_7i96.0: IO Pin 042 (P1-09): IOPort
>>> hm2/hm2_7i96.0: IO Pin 043 (P1-11): IOPort
>>> hm2/hm2_7i96.0: IO Pin 044 (P1-13): IOPort
>>> hm2/hm2_7i96.0: IO Pin 045 (P1-15): IOPort
>>> hm2/hm2_7i96.0: IO Pin 046 (P1-17): IOPort
>>> hm2/hm2_7i96.0: IO Pin 047 (P1-19): IOPort
>>> hm2/hm2_7i96.0: IO Pin 048 (P1-21): IOPort
>>> hm2/hm2_7i96.0: IO Pin 049 (P1-23): IOPort
>>> hm2/hm2_7i96.0: IO Pin 050 (P1-25): IOPort
>>> 

Re: [Machinekit] Re: DE10 Nano suggested development environment?

[Michael Brown]

Got some scope results:
https://github.com/machinekit/mksocfpga/issues/107#issuecomment-524570613


On Saturday, 24 August 2019 19:31:04 UTC+2, justin White wrote:
>
> @Michael, if ya need any info from my LCNC machine let me know. It's not 
> MK but it does have a working SS setup that's easy to check.
>
> Also, if it makes it any easier for you to test anything I'm about to 
> order what's hopefully my final board rev. I can whip you one up and send 
> it your way, might be useful if you get an SS remote on hand.
>
> On Saturday, August 24, 2019 at 1:20:09 PM UTC-4, justin White wrote:
>>
>> I'm not sure if this helps you but SS pins always look like normal I/O if 
>> they don't detect a remote on the channel after coming up. Since I have it 
>> out I connected the 8i20 to my project machine's 7i96 that I don't 
>> typically use SS with. This is LinuxCNC 2.8pre1
>>
>> No 8i20 connected, note IO pins 30 and 31:
>> shade@Viewer:~$ halrun
>> halcmd: source /home/shade/linuxcnc/SS_Test.halrun 
>> Note: Using POSIX realtime
>> hm2: loading Mesa HostMot2 driver version 0.15
>> hm2_eth: loading Mesa AnyIO HostMot2 ethernet driver version 0.2
>> hm2_eth: 10.10.10.10: Hardware address: 00:60:1b:16:00:21
>> hm2_eth: discovered 7I96
>> hm2/hm2_7i96.0: Smart Serial Firmware Version 43
>> hm2/hm2_7i96.0: 51 I/O Pins used:
>> hm2/hm2_7i96.0: IO Pin 000 (TB3-01): IOPort
>> hm2/hm2_7i96.0: IO Pin 001 (TB3-02): IOPort
>> hm2/hm2_7i96.0: IO Pin 002 (TB3-03): IOPort
>> hm2/hm2_7i96.0: IO Pin 003 (TB3-04): IOPort
>> hm2/hm2_7i96.0: IO Pin 004 (TB3-05): IOPort
>> hm2/hm2_7i96.0: IO Pin 005 (TB3-06): IOPort
>> hm2/hm2_7i96.0: IO Pin 006 (TB3-07): IOPort
>> hm2/hm2_7i96.0: IO Pin 007 (TB3-08): IOPort
>> hm2/hm2_7i96.0: IO Pin 008 (TB3-09): IOPort
>> hm2/hm2_7i96.0: IO Pin 009 (TB3-10): IOPort
>> hm2/hm2_7i96.0: IO Pin 010 (TB3-11): IOPort
>> hm2/hm2_7i96.0: IO Pin 011 (TB3-13/TB3-14): SSR #0, pin Out-00 
>> (Output)
>> hm2/hm2_7i96.0: IO Pin 012 (TB3-15/TB3-16): SSR #0, pin Out-01 
>> (Output)
>> hm2/hm2_7i96.0: IO Pin 013 (TB3-17/TB3-18): SSR #0, pin Out-02 
>> (Output)
>> hm2/hm2_7i96.0: IO Pin 014 (TB3-19/TB3-20): SSR #0, pin Out-03 
>> (Output)
>> hm2/hm2_7i96.0: IO Pin 015 (TB3-21/TB3-22): SSR #0, pin Out-04 
>> (Output)
>> hm2/hm2_7i96.0: IO Pin 016 (TB3-23/TB3-24): SSR #0, pin Out-05 
>> (Output)
>> hm2/hm2_7i96.0: IO Pin 017 (TB1-02/TB1-03): StepGen #0, pin Step 
>> (Output)
>> hm2/hm2_7i96.0: IO Pin 018 (TB1-04/TB1-05): StepGen #0, pin Direction 
>> (Output)
>> hm2/hm2_7i96.0: IO Pin 019 (TB1-08/TB1-09): StepGen #1, pin Step 
>> (Output)
>> hm2/hm2_7i96.0: IO Pin 020 (TB1-10/TB1-11): StepGen #1, pin Direction 
>> (Output)
>> hm2/hm2_7i96.0: IO Pin 021 (TB1-14/TB1-15): StepGen #2, pin Step 
>> (Output)
>> hm2/hm2_7i96.0: IO Pin 022 (TB1-16/TB1-17): StepGen #2, pin Direction 
>> (Output)
>> hm2/hm2_7i96.0: IO Pin 023 (TB1-20/TB1-21): StepGen #3, pin Step 
>> (Output)
>> hm2/hm2_7i96.0: IO Pin 024 (TB1-22-TB1-23): StepGen #3, pin Direction 
>> (Output)
>> hm2/hm2_7i96.0: IO Pin 025 (TB2-01/TB2-03): StepGen #4, pin Step 
>> (Output)
>> hm2/hm2_7i96.0: IO Pin 026 (TB2-04/TB2-05): StepGen #4, pin Direction 
>> (Output)
>> hm2/hm2_7i96.0: IO Pin 027 (TB2-07/TB2-08): Encoder #0, pin A (Input)
>> hm2/hm2_7i96.0: IO Pin 028 (TB2-10/TB2-11): Encoder #0, pin B (Input)
>> hm2/hm2_7i96.0: IO Pin 029 (TB2-13/TB2-14): Encoder #0, pin Index 
>> (Input)
>> hm2/hm2_7i96.0: IO Pin 030 (TB2-16/TB2-17): IOPort
>> hm2/hm2_7i96.0: IO Pin 031 (TB2-18/TB2-19): IOPort
>> hm2/hm2_7i96.0: IO Pin 032 (internal): IOPort
>> hm2/hm2_7i96.0: IO Pin 033 (internal): SSR #0, pin AC Ref (internal) 
>> (Output)
>> hm2/hm2_7i96.0: IO Pin 034 (P1-01): IOPort
>> hm2/hm2_7i96.0: IO Pin 035 (P1-02): IOPort
>> hm2/hm2_7i96.0: IO Pin 036 (P1-03): IOPort
>> hm2/hm2_7i96.0: IO Pin 037 (P1-04): IOPort
>> hm2/hm2_7i96.0: IO Pin 038 (P1-05): IOPort
>> hm2/hm2_7i96.0: IO Pin 039 (P1-06): IOPort
>> hm2/hm2_7i96.0: IO Pin 040 (P1-07): IOPort
>> hm2/hm2_7i96.0: IO Pin 041 (P1-08): IOPort
>> hm2/hm2_7i96.0: IO Pin 042 (P1-09): IOPort
>> hm2/hm2_7i96.0: IO Pin 043 (P1-11): IOPort
>> hm2/hm2_7i96.0: IO Pin 044 (P1-13): IOPort
>> hm2/hm2_7i96.0: IO Pin 045 (P1-15): IOPort
>> hm2/hm2_7i96.0: IO Pin 046 (P1-17): IOPort
>> hm2/hm2_7i96.0: IO Pin 047 (P1-19): IOPort
>> hm2/hm2_7i96.0: IO Pin 048 (P1-21): IOPort
>> hm2/hm2_7i96.0: IO Pin 049 (P1-23): IOPort
>> hm2/hm2_7i96.0: IO Pin 050 (P1-25): IOPort
>> hm2/hm2_7i96.0: registered
>>
>>
>> With the 8i20 connected and the same source file:
>> shade@Viewer:~$ halrun
>> halcmd: source /home/shade/linuxcnc/SS_Test.halrun 
>> Note: Using POSIX realtime
>> hm2: loading Mesa HostMot2 driver version 0.15
>> hm2_eth: loading Mesa AnyIO HostMot2 ethernet driver version 0.2
>> hm2_eth: 10.10.10.10: Hardware address: 00:60:1b:16:00:21
>> 

Re: [Machinekit] Re: DE10 Nano suggested development environment?

[justin White]

@Michael, if ya need any info from my LCNC machine let me know. It's not MK 
but it does have a working SS setup that's easy to check.

Also, if it makes it any easier for you to test anything I'm about to order 
what's hopefully my final board rev. I can whip you one up and send it your 
way, might be useful if you get an SS remote on hand.

On Saturday, August 24, 2019 at 1:20:09 PM UTC-4, justin White wrote:
>
> I'm not sure if this helps you but SS pins always look like normal I/O if 
> they don't detect a remote on the channel after coming up. Since I have it 
> out I connected the 8i20 to my project machine's 7i96 that I don't 
> typically use SS with. This is LinuxCNC 2.8pre1
>
> No 8i20 connected, note IO pins 30 and 31:
> shade@Viewer:~$ halrun
> halcmd: source /home/shade/linuxcnc/SS_Test.halrun 
> Note: Using POSIX realtime
> hm2: loading Mesa HostMot2 driver version 0.15
> hm2_eth: loading Mesa AnyIO HostMot2 ethernet driver version 0.2
> hm2_eth: 10.10.10.10: Hardware address: 00:60:1b:16:00:21
> hm2_eth: discovered 7I96
> hm2/hm2_7i96.0: Smart Serial Firmware Version 43
> hm2/hm2_7i96.0: 51 I/O Pins used:
> hm2/hm2_7i96.0: IO Pin 000 (TB3-01): IOPort
> hm2/hm2_7i96.0: IO Pin 001 (TB3-02): IOPort
> hm2/hm2_7i96.0: IO Pin 002 (TB3-03): IOPort
> hm2/hm2_7i96.0: IO Pin 003 (TB3-04): IOPort
> hm2/hm2_7i96.0: IO Pin 004 (TB3-05): IOPort
> hm2/hm2_7i96.0: IO Pin 005 (TB3-06): IOPort
> hm2/hm2_7i96.0: IO Pin 006 (TB3-07): IOPort
> hm2/hm2_7i96.0: IO Pin 007 (TB3-08): IOPort
> hm2/hm2_7i96.0: IO Pin 008 (TB3-09): IOPort
> hm2/hm2_7i96.0: IO Pin 009 (TB3-10): IOPort
> hm2/hm2_7i96.0: IO Pin 010 (TB3-11): IOPort
> hm2/hm2_7i96.0: IO Pin 011 (TB3-13/TB3-14): SSR #0, pin Out-00 (Output)
> hm2/hm2_7i96.0: IO Pin 012 (TB3-15/TB3-16): SSR #0, pin Out-01 (Output)
> hm2/hm2_7i96.0: IO Pin 013 (TB3-17/TB3-18): SSR #0, pin Out-02 (Output)
> hm2/hm2_7i96.0: IO Pin 014 (TB3-19/TB3-20): SSR #0, pin Out-03 (Output)
> hm2/hm2_7i96.0: IO Pin 015 (TB3-21/TB3-22): SSR #0, pin Out-04 (Output)
> hm2/hm2_7i96.0: IO Pin 016 (TB3-23/TB3-24): SSR #0, pin Out-05 (Output)
> hm2/hm2_7i96.0: IO Pin 017 (TB1-02/TB1-03): StepGen #0, pin Step 
> (Output)
> hm2/hm2_7i96.0: IO Pin 018 (TB1-04/TB1-05): StepGen #0, pin Direction 
> (Output)
> hm2/hm2_7i96.0: IO Pin 019 (TB1-08/TB1-09): StepGen #1, pin Step 
> (Output)
> hm2/hm2_7i96.0: IO Pin 020 (TB1-10/TB1-11): StepGen #1, pin Direction 
> (Output)
> hm2/hm2_7i96.0: IO Pin 021 (TB1-14/TB1-15): StepGen #2, pin Step 
> (Output)
> hm2/hm2_7i96.0: IO Pin 022 (TB1-16/TB1-17): StepGen #2, pin Direction 
> (Output)
> hm2/hm2_7i96.0: IO Pin 023 (TB1-20/TB1-21): StepGen #3, pin Step 
> (Output)
> hm2/hm2_7i96.0: IO Pin 024 (TB1-22-TB1-23): StepGen #3, pin Direction 
> (Output)
> hm2/hm2_7i96.0: IO Pin 025 (TB2-01/TB2-03): StepGen #4, pin Step 
> (Output)
> hm2/hm2_7i96.0: IO Pin 026 (TB2-04/TB2-05): StepGen #4, pin Direction 
> (Output)
> hm2/hm2_7i96.0: IO Pin 027 (TB2-07/TB2-08): Encoder #0, pin A (Input)
> hm2/hm2_7i96.0: IO Pin 028 (TB2-10/TB2-11): Encoder #0, pin B (Input)
> hm2/hm2_7i96.0: IO Pin 029 (TB2-13/TB2-14): Encoder #0, pin Index 
> (Input)
> hm2/hm2_7i96.0: IO Pin 030 (TB2-16/TB2-17): IOPort
> hm2/hm2_7i96.0: IO Pin 031 (TB2-18/TB2-19): IOPort
> hm2/hm2_7i96.0: IO Pin 032 (internal): IOPort
> hm2/hm2_7i96.0: IO Pin 033 (internal): SSR #0, pin AC Ref (internal) 
> (Output)
> hm2/hm2_7i96.0: IO Pin 034 (P1-01): IOPort
> hm2/hm2_7i96.0: IO Pin 035 (P1-02): IOPort
> hm2/hm2_7i96.0: IO Pin 036 (P1-03): IOPort
> hm2/hm2_7i96.0: IO Pin 037 (P1-04): IOPort
> hm2/hm2_7i96.0: IO Pin 038 (P1-05): IOPort
> hm2/hm2_7i96.0: IO Pin 039 (P1-06): IOPort
> hm2/hm2_7i96.0: IO Pin 040 (P1-07): IOPort
> hm2/hm2_7i96.0: IO Pin 041 (P1-08): IOPort
> hm2/hm2_7i96.0: IO Pin 042 (P1-09): IOPort
> hm2/hm2_7i96.0: IO Pin 043 (P1-11): IOPort
> hm2/hm2_7i96.0: IO Pin 044 (P1-13): IOPort
> hm2/hm2_7i96.0: IO Pin 045 (P1-15): IOPort
> hm2/hm2_7i96.0: IO Pin 046 (P1-17): IOPort
> hm2/hm2_7i96.0: IO Pin 047 (P1-19): IOPort
> hm2/hm2_7i96.0: IO Pin 048 (P1-21): IOPort
> hm2/hm2_7i96.0: IO Pin 049 (P1-23): IOPort
> hm2/hm2_7i96.0: IO Pin 050 (P1-25): IOPort
> hm2/hm2_7i96.0: registered
>
>
> With the 8i20 connected and the same source file:
> shade@Viewer:~$ halrun
> halcmd: source /home/shade/linuxcnc/SS_Test.halrun 
> Note: Using POSIX realtime
> hm2: loading Mesa HostMot2 driver version 0.15
> hm2_eth: loading Mesa AnyIO HostMot2 ethernet driver version 0.2
> hm2_eth: 10.10.10.10: Hardware address: 00:60:1b:16:00:21
> hm2_eth: discovered 7I96
> hm2/hm2_7i96.0: Smart Serial Firmware Version 43
> hm2/hm2_7i96.0: 51 I/O Pins used:
> hm2/hm2_7i96.0: IO Pin 000 (TB3-01): IOPort
> hm2/hm2_7i96.0: IO Pin 001 (TB3-02): IOPort
> hm2/hm2_7i96.0: IO Pin 002 (TB3-03): IOPort
> hm2/hm2_7i96.0: IO Pin 003 

Re: [Machinekit] Re: DE10 Nano suggested development environment?

[justin White]

I'm not sure if this helps you but SS pins always look like normal I/O if 
they don't detect a remote on the channel after coming up. Since I have it 
out I connected the 8i20 to my project machine's 7i96 that I don't 
typically use SS with. This is LinuxCNC 2.8pre1

No 8i20 connected, note IO pins 30 and 31:
shade@Viewer:~$ halrun
halcmd: source /home/shade/linuxcnc/SS_Test.halrun 
Note: Using POSIX realtime
hm2: loading Mesa HostMot2 driver version 0.15
hm2_eth: loading Mesa AnyIO HostMot2 ethernet driver version 0.2
hm2_eth: 10.10.10.10: Hardware address: 00:60:1b:16:00:21
hm2_eth: discovered 7I96
hm2/hm2_7i96.0: Smart Serial Firmware Version 43
hm2/hm2_7i96.0: 51 I/O Pins used:
hm2/hm2_7i96.0: IO Pin 000 (TB3-01): IOPort
hm2/hm2_7i96.0: IO Pin 001 (TB3-02): IOPort
hm2/hm2_7i96.0: IO Pin 002 (TB3-03): IOPort
hm2/hm2_7i96.0: IO Pin 003 (TB3-04): IOPort
hm2/hm2_7i96.0: IO Pin 004 (TB3-05): IOPort
hm2/hm2_7i96.0: IO Pin 005 (TB3-06): IOPort
hm2/hm2_7i96.0: IO Pin 006 (TB3-07): IOPort
hm2/hm2_7i96.0: IO Pin 007 (TB3-08): IOPort
hm2/hm2_7i96.0: IO Pin 008 (TB3-09): IOPort
hm2/hm2_7i96.0: IO Pin 009 (TB3-10): IOPort
hm2/hm2_7i96.0: IO Pin 010 (TB3-11): IOPort
hm2/hm2_7i96.0: IO Pin 011 (TB3-13/TB3-14): SSR #0, pin Out-00 (Output)
hm2/hm2_7i96.0: IO Pin 012 (TB3-15/TB3-16): SSR #0, pin Out-01 (Output)
hm2/hm2_7i96.0: IO Pin 013 (TB3-17/TB3-18): SSR #0, pin Out-02 (Output)
hm2/hm2_7i96.0: IO Pin 014 (TB3-19/TB3-20): SSR #0, pin Out-03 (Output)
hm2/hm2_7i96.0: IO Pin 015 (TB3-21/TB3-22): SSR #0, pin Out-04 (Output)
hm2/hm2_7i96.0: IO Pin 016 (TB3-23/TB3-24): SSR #0, pin Out-05 (Output)
hm2/hm2_7i96.0: IO Pin 017 (TB1-02/TB1-03): StepGen #0, pin Step 
(Output)
hm2/hm2_7i96.0: IO Pin 018 (TB1-04/TB1-05): StepGen #0, pin Direction 
(Output)
hm2/hm2_7i96.0: IO Pin 019 (TB1-08/TB1-09): StepGen #1, pin Step 
(Output)
hm2/hm2_7i96.0: IO Pin 020 (TB1-10/TB1-11): StepGen #1, pin Direction 
(Output)
hm2/hm2_7i96.0: IO Pin 021 (TB1-14/TB1-15): StepGen #2, pin Step 
(Output)
hm2/hm2_7i96.0: IO Pin 022 (TB1-16/TB1-17): StepGen #2, pin Direction 
(Output)
hm2/hm2_7i96.0: IO Pin 023 (TB1-20/TB1-21): StepGen #3, pin Step 
(Output)
hm2/hm2_7i96.0: IO Pin 024 (TB1-22-TB1-23): StepGen #3, pin Direction 
(Output)
hm2/hm2_7i96.0: IO Pin 025 (TB2-01/TB2-03): StepGen #4, pin Step 
(Output)
hm2/hm2_7i96.0: IO Pin 026 (TB2-04/TB2-05): StepGen #4, pin Direction 
(Output)
hm2/hm2_7i96.0: IO Pin 027 (TB2-07/TB2-08): Encoder #0, pin A (Input)
hm2/hm2_7i96.0: IO Pin 028 (TB2-10/TB2-11): Encoder #0, pin B (Input)
hm2/hm2_7i96.0: IO Pin 029 (TB2-13/TB2-14): Encoder #0, pin Index 
(Input)
hm2/hm2_7i96.0: IO Pin 030 (TB2-16/TB2-17): IOPort
hm2/hm2_7i96.0: IO Pin 031 (TB2-18/TB2-19): IOPort
hm2/hm2_7i96.0: IO Pin 032 (internal): IOPort
hm2/hm2_7i96.0: IO Pin 033 (internal): SSR #0, pin AC Ref (internal) 
(Output)
hm2/hm2_7i96.0: IO Pin 034 (P1-01): IOPort
hm2/hm2_7i96.0: IO Pin 035 (P1-02): IOPort
hm2/hm2_7i96.0: IO Pin 036 (P1-03): IOPort
hm2/hm2_7i96.0: IO Pin 037 (P1-04): IOPort
hm2/hm2_7i96.0: IO Pin 038 (P1-05): IOPort
hm2/hm2_7i96.0: IO Pin 039 (P1-06): IOPort
hm2/hm2_7i96.0: IO Pin 040 (P1-07): IOPort
hm2/hm2_7i96.0: IO Pin 041 (P1-08): IOPort
hm2/hm2_7i96.0: IO Pin 042 (P1-09): IOPort
hm2/hm2_7i96.0: IO Pin 043 (P1-11): IOPort
hm2/hm2_7i96.0: IO Pin 044 (P1-13): IOPort
hm2/hm2_7i96.0: IO Pin 045 (P1-15): IOPort
hm2/hm2_7i96.0: IO Pin 046 (P1-17): IOPort
hm2/hm2_7i96.0: IO Pin 047 (P1-19): IOPort
hm2/hm2_7i96.0: IO Pin 048 (P1-21): IOPort
hm2/hm2_7i96.0: IO Pin 049 (P1-23): IOPort
hm2/hm2_7i96.0: IO Pin 050 (P1-25): IOPort
hm2/hm2_7i96.0: registered


With the 8i20 connected and the same source file:
shade@Viewer:~$ halrun
halcmd: source /home/shade/linuxcnc/SS_Test.halrun 
Note: Using POSIX realtime
hm2: loading Mesa HostMot2 driver version 0.15
hm2_eth: loading Mesa AnyIO HostMot2 ethernet driver version 0.2
hm2_eth: 10.10.10.10: Hardware address: 00:60:1b:16:00:21
hm2_eth: discovered 7I96
hm2/hm2_7i96.0: Smart Serial Firmware Version 43
hm2/hm2_7i96.0: 51 I/O Pins used:
hm2/hm2_7i96.0: IO Pin 000 (TB3-01): IOPort
hm2/hm2_7i96.0: IO Pin 001 (TB3-02): IOPort
hm2/hm2_7i96.0: IO Pin 002 (TB3-03): IOPort
hm2/hm2_7i96.0: IO Pin 003 (TB3-04): IOPort
hm2/hm2_7i96.0: IO Pin 004 (TB3-05): IOPort
hm2/hm2_7i96.0: IO Pin 005 (TB3-06): IOPort
hm2/hm2_7i96.0: IO Pin 006 (TB3-07): IOPort
hm2/hm2_7i96.0: IO Pin 007 (TB3-08): IOPort
hm2/hm2_7i96.0: IO Pin 008 (TB3-09): IOPort
hm2/hm2_7i96.0: IO Pin 009 (TB3-10): IOPort
hm2/hm2_7i96.0: IO Pin 010 (TB3-11): IOPort
hm2/hm2_7i96.0: IO Pin 011 (TB3-13/TB3-14): SSR #0, pin Out-00 (Output)
hm2/hm2_7i96.0: IO Pin 012 (TB3-15/TB3-16): SSR #0, pin Out-01 (Output)
hm2/hm2_7i96.0: IO Pin 013 (TB3-17/TB3-18): SSR #0, pin Out-02 (Output)
hm2/hm2_7i96.0: IO 

Re: [Machinekit] Re: DE10 Nano suggested development environment?

[Michael Brown]

@Charles
@Justin
I suggest we take the SSerial debug issue here as this seems to apply 
Globally to all the Mksocfpga project's

https://github.com/machinekit/mksocfpga/issues/107#issuecomment-524558425

What I have found is that SSerial pins are configured as ordinary I/O's so 
..:
I'm currently quite convinced SSerial never has worked in Mksocfpga or has 
been broken by a commit if someone has ever had it to work on the soc's 
.

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/machinekit/5c470702-c220-4599-a12b-1619211a5e0b%40googlegroups.com.

Re: [Machinekit] Re: DE10 Nano suggested development environment?

[justin White]

SSerial doesn't take any commands directly as far as I'm aware, the host 
card initiates a handshake then treats it as an extension of it's own hal 
instance once it's identified. Just needs a config line like this:
CONFIG="num_encoders=6 num_stepgens=6 enable_adc=1 *sserial_port_0=00xx*"

The only thing you should see is on start of MK, the Tx line should throw a 
0xDF with a cyclic redundancy check, then the remote will respond with 
whatever it's programmed to respond with, in this case you obviously won't 
get a response. Not 100% sure what that's supposed to look like but attempt 
at communication on the line should be obvious. 

Once the SSerial Remote is found it becomes part of the host instance i.e., 
there will be hal pins like "hm2_5i25.0.8i20.0.1.current-maxlim"



On Saturday, August 24, 2019 at 4:17:14 AM UTC-4, Michael Brown wrote:
>
> Can you post the exact hal commands for probing the tx line here ?
> I have a Pisoscope 3206D MSO, so I can test that on my (Dev) DE10_Nano
>
>
> On Friday, 23 August 2019 23:53:58 UTC+2, justin White wrote:
>
> Still no go for SS on the 8i20. Can anyone confirm that SS actually works 
> in MK or any of these DExx configs, like has anyone been able to connect a 
> SS remote board? The only hal configuration I needed was a config line of 
> "sserial_port_0=00". Other than that I see that hm2 has to be brought 
> up with "newinst". I assume there's not much difference being compiled as 
> instcomp rather than legacy?
>
> From what I understand right now, the SS host is supposed to send a 0xDF 
> and recieve a 0xAA from the 8i20 in return for the handshake. If I could 
> get my scope going and see 1101 directly on the Tx pin I could verify 
> that the SS host is doing it's job.
>
> On Fri, Aug 23, 2019 at 5:21 PM justin White  wrote:
>
> The last one I tested was still a no go, tried to get the USB scope 
> working but having software issues in the new PC. I did yank the 8i20 out 
> of the mill to make it easier to test.
>
> I'll try this one and see how it goes
>
> On Fri, Aug 23, 2019 at 4:59 PM Michael Brown  wrote:
>
> So ... Latest and great .. (for)test...
> Everything tested (on all my current MK setups)and working here... :-)
>
> Hope This config gets the SSerial working @your end .
>
>
> On Friday, 23 August 2019 17:06:21 UTC+2, Michael Brown wrote:
>
> Ok 
> Here:
> Everything worked execpt the capsensot (tested on my ob-ox router running 
> on a DE0_), so
> reverted the CapSense pin commit (seems like I have perhaps loaded the pin 
> array backwards)
>
> On Friday, 23 August 2019 16:18:41 UTC+2, Michael Brown wrote:
>
> OK found the flaw in that commit (leading to currupt io), and was able to 
> fix it.
> Expect a new bit file in about 2 docker compile times :-), 1/2 hour or 
> so...
>
> On Friday, 23 August 2019 15:56:59 UTC+2, justin White wrote:
>
> lol thanks, I do appreciate it
>
>
> On Fri, Aug 23, 2019 at 8:56 AM Michael Brown  wrote:
>
> Ups Looked like I messed up testing one of my commits: (by copying the 
> wrong .rbf file)
> And that that commit (the one for configuring CapSense pins) was faulty
>
> rebasing .. compiling ... and re-testing now  AArrrghh
>
>
> On Friday, 23 August 2019 13:35:22 UTC+2, Michael Brown wrote:
>
> Looked at the manual for the 8i20 you mentioned:
> http://www.mesanet.com/pdf/motion/8i20man.pdf
>
> Page 5 specifies 2 rx and 2 tx channels  ?
>
>
> On Friday, 23 August 2019 13:16:41 UTC+2, Michael Brown wrote:
>
> You forgot the reply all so I repost here:
>
> I tried it with the first .rbf you posted and still didn't get it to 
> communicate. I'll try the 2nd one tomorrow.
> The problem at the moment is that I haven't seen my setup work with a 
> known good SS config and the DE10-Nano config hasn't worked with known good 
> hardware. I can't think of an easy way to test the hardware other than to 
> scope it which I'll do if you can't find the firmware issue easily.
>
>
> I thought Charles Mentioned a working setup above so I looked thru the 
> thread:
> (Thinking you could test with that DE10_..._DB25 config)
> REcap:
>
> Charles
> Re: [Machinekit] Re: DE10 Nano suggested development environment?
> 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, b

Re: [Machinekit] Re: DE10 Nano suggested development environment?

[Michael Brown]

Can you post the exact hal commands for probing the tx line here ?
I have a Pisoscope 3206D MSO, so I can test that on my (Dev) DE10_Nano


On Friday, 23 August 2019 23:53:58 UTC+2, justin White wrote:
>
> Still no go for SS on the 8i20. Can anyone confirm that SS actually works 
> in MK or any of these DExx configs, like has anyone been able to connect a 
> SS remote board? The only hal configuration I needed was a config line of 
> "sserial_port_0=00". Other than that I see that hm2 has to be brought 
> up with "newinst". I assume there's not much difference being compiled as 
> instcomp rather than legacy?
>
> From what I understand right now, the SS host is supposed to send a 0xDF 
> and recieve a 0xAA from the 8i20 in return for the handshake. If I could 
> get my scope going and see 1101 directly on the Tx pin I could verify 
> that the SS host is doing it's job.
>
> On Fri, Aug 23, 2019 at 5:21 PM justin White  > wrote:
>
> The last one I tested was still a no go, tried to get the USB scope 
> working but having software issues in the new PC. I did yank the 8i20 out 
> of the mill to make it easier to test.
>
> I'll try this one and see how it goes
>
> On Fri, Aug 23, 2019 at 4:59 PM Michael Brown  > wrote:
>
> So ... Latest and great .. (for)test...
> Everything tested (on all my current MK setups)and working here... :-)
>
> Hope This config gets the SSerial working @your end .
>
>
> On Friday, 23 August 2019 17:06:21 UTC+2, Michael Brown wrote:
>
> Ok 
> Here:
> Everything worked execpt the capsensot (tested on my ob-ox router running 
> on a DE0_), so
> reverted the CapSense pin commit (seems like I have perhaps loaded the pin 
> array backwards)
>
> On Friday, 23 August 2019 16:18:41 UTC+2, Michael Brown wrote:
>
> OK found the flaw in that commit (leading to currupt io), and was able to 
> fix it.
> Expect a new bit file in about 2 docker compile times :-), 1/2 hour or 
> so...
>
> On Friday, 23 August 2019 15:56:59 UTC+2, justin White wrote:
>
> lol thanks, I do appreciate it
>
>
> On Fri, Aug 23, 2019 at 8:56 AM Michael Brown  wrote:
>
> Ups Looked like I messed up testing one of my commits: (by copying the 
> wrong .rbf file)
> And that that commit (the one for configuring CapSense pins) was faulty
>
> rebasing .. compiling ... and re-testing now  AArrrghh
>
>
> On Friday, 23 August 2019 13:35:22 UTC+2, Michael Brown wrote:
>
> Looked at the manual for the 8i20 you mentioned:
> http://www.mesanet.com/pdf/motion/8i20man.pdf
>
> Page 5 specifies 2 rx and 2 tx channels  ?
>
>
> On Friday, 23 August 2019 13:16:41 UTC+2, Michael Brown wrote:
>
> You forgot the reply all so I repost here:
>
> I tried it with the first .rbf you posted and still didn't get it to 
> communicate. I'll try the 2nd one tomorrow.
> The problem at the moment is that I haven't seen my setup work with a 
> known good SS config and the DE10-Nano config hasn't worked with known good 
> hardware. I can't think of an easy way to test the hardware other than to 
> scope it which I'll do if you can't find the firmware issue easily.
>
>
> I thought Charles Mentioned a working setup above so I looked thru the 
> thread:
> (Thinking you could test with that DE10_..._DB25 config)
> REcap:
>
> Charles
> Re: [Machinekit] Re: DE10 Nano suggested development environment?
> 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. 
>
>
> So seems like you are missing the 2'nd SSerial in your pin config / Hw 
> setup ?
>
>
>
> On Thursday, 22 August 2019 22:36:35 UTC+2, Michael Brown wrote:
>
> I just ran a docker compilation and attach that file here.(functionality 
> should be the same as the for

Re: [Machinekit] Re: DE10 Nano suggested development environment?

[justin White]

The last one I tested was still a no go, tried to get the USB scope working
but having software issues in the new PC. I did yank the 8i20 out of the
mill to make it easier to test.

I'll try this one and see how it goes

On Fri, Aug 23, 2019 at 4:59 PM Michael Brown 
wrote:

> So ... Latest and great .. (for)test...
> Everything tested (on all my current MK setups)and working here... :-)
>
> Hope This config gets the SSerial working @your end .
>
>
> On Friday, 23 August 2019 17:06:21 UTC+2, Michael Brown wrote:
>>
>> Ok
>> Here:
>> Everything worked execpt the capsensot (tested on my ob-ox router running
>> on a DE0_), so
>> reverted the CapSense pin commit (seems like I have perhaps loaded the
>> pin array backwards)
>>
>> On Friday, 23 August 2019 16:18:41 UTC+2, Michael Brown wrote:
>>
>> OK found the flaw in that commit (leading to currupt io), and was able to
>> fix it.
>> Expect a new bit file in about 2 docker compile times :-), 1/2 hour
>> or so...
>>
>> On Friday, 23 August 2019 15:56:59 UTC+2, justin White wrote:
>>
>> lol thanks, I do appreciate it
>>
>>
>> On Fri, Aug 23, 2019 at 8:56 AM Michael Brown 
>> wrote:
>>
>> Ups Looked like I messed up testing one of my commits: (by copying the
>> wrong .rbf file)
>> And that that commit (the one for configuring CapSense pins) was
>> faulty
>>
>> rebasing .. compiling ... and re-testing now  AArrrghh
>>
>>
>> On Friday, 23 August 2019 13:35:22 UTC+2, Michael Brown wrote:
>>
>> Looked at the manual for the 8i20 you mentioned:
>> http://www.mesanet.com/pdf/motion/8i20man.pdf
>>
>> Page 5 specifies 2 rx and 2 tx channels  ?
>>
>>
>> On Friday, 23 August 2019 13:16:41 UTC+2, Michael Brown wrote:
>>
>> You forgot the reply all so I repost here:
>>
>> I tried it with the first .rbf you posted and still didn't get it to
>> communicate. I'll try the 2nd one tomorrow.
>> The problem at the moment is that I haven't seen my setup work with a
>> known good SS config and the DE10-Nano config hasn't worked with known good
>> hardware. I can't think of an easy way to test the hardware other than to
>> scope it which I'll do if you can't find the firmware issue easily.
>>
>>
>> I thought Charles Mentioned a working setup above so I looked thru the
>> thread:
>> (Thinking you could test with that DE10_..._DB25 config)
>> REcap:
>>
>> Charles
>> Re: [Machinekit] Re: DE10 Nano suggested development environment?
>> 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.
>>
>>
>> So seems like you are missing the 2'nd SSerial in your pin config / Hw
>> setup ?
>>
>>
>>
>> On Thursday, 22 August 2019 22:36:35 UTC+2, Michael Brown wrote:
>>
>> I just ran a docker compilation and attach that file here.(functionality
>> should be the same as the former file,,,(but just in case) :-)
>>
>> On Thursday, 22 August 2019 21:05:16 UTC+2, Michael Brown wrote:
>>
>> OK copied the new .rbf file, renamed and attached it for testing
>>
>> uartx8:\makeUARTTXs:0:auartx 75.2 (56.5) 102.7 (56.8) 27.5 (0.3) 0.0
>> (0.0) 0.0 (0.0) 95 (95) 197 (63) 0 (0) 0 0 0 0 0
>> SRL16E:\fifosrl:0:asr16e 3.7 (0.0) 4.8 (0.0) 1.2 (0.0) 0.0 (0.0) 0.0
>> (0.0) 0 (0) 16 (0) 0 (0) 0 0 0 0 0
>> look fine now
>>
>>
>> On Thursday, 22 August 2019 20:52:04 UTC+2, Michael Brown wrote:
>>
>> OK
>> I noticed:
>> uartx8:\makeUARTTXs:0:auartx 25.9 (25.9) 28.7 (28.7) 2.8 (2.8) 0.0 (0.0) 0.0
>> (0.0) 46 (46) 47 (

Re: [Machinekit] Re: DE10 Nano suggested development environment?

[Michael Brown]

So  Finally 

Got the CapSense pin configuration to work as expected and reposted the 
modified sserial-work branch.

Right now just started the full Quartus Docker build, so I can test out on 
my 3d printer machines as well.
I'll post latest version your bitfile as soon as it comes out (in a few 
hours time), however the functionality should be exact same as the former 
one posted (as CapSense is disabled).

:-)


On Friday, 23 August 2019 17:06:21 UTC+2, Michael Brown wrote:
>
> Ok 
> Here:
> Everything worked execpt the capsensot (tested on my ob-ox router running 
> on a DE0_), so
> reverted the CapSense pin commit (seems like I have perhaps loaded the pin 
> array backwards)
>
> On Friday, 23 August 2019 16:18:41 UTC+2, Michael Brown wrote:
>
> OK found the flaw in that commit (leading to currupt io), and was able to 
> fix it.
> Expect a new bit file in about 2 docker compile times :-), 1/2 hour or 
> so...
>
> On Friday, 23 August 2019 15:56:59 UTC+2, justin White wrote:
>
> lol thanks, I do appreciate it
>
>
> On Fri, Aug 23, 2019 at 8:56 AM Michael Brown  wrote:
>
> Ups Looked like I messed up testing one of my commits: (by copying the 
> wrong .rbf file)
> And that that commit (the one for configuring CapSense pins) was faulty
>
> rebasing .. compiling ... and re-testing now  AArrrghh
>
>
> On Friday, 23 August 2019 13:35:22 UTC+2, Michael Brown wrote:
>
> Looked at the manual for the 8i20 you mentioned:
> http://www.mesanet.com/pdf/motion/8i20man.pdf
>
> Page 5 specifies 2 rx and 2 tx channels  ?
>
>
> On Friday, 23 August 2019 13:16:41 UTC+2, Michael Brown wrote:
>
> You forgot the reply all so I repost here:
>
> I tried it with the first .rbf you posted and still didn't get it to 
> communicate. I'll try the 2nd one tomorrow.
> The problem at the moment is that I haven't seen my setup work with a 
> known good SS config and the DE10-Nano config hasn't worked with known good 
> hardware. I can't think of an easy way to test the hardware other than to 
> scope it which I'll do if you can't find the firmware issue easily.
>
>
> I thought Charles Mentioned a working setup above so I looked thru the 
> thread:
> (Thinking you could test with that DE10_..._DB25 config)
> REcap:
>
> Charles
> Re: [Machinekit] Re: DE10 Nano suggested development environment?
> 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. 
>
>
> So seems like you are missing the 2'nd SSerial in your pin config / Hw 
> setup ?
>
>
>
> On Thursday, 22 August 2019 22:36:35 UTC+2, Michael Brown wrote:
>
> I just ran a docker compilation and attach that file here.(functionality 
> should be the same as the former file,,,(but just in case) :-)
>
> On Thursday, 22 August 2019 21:05:16 UTC+2, Michael Brown wrote:
>
> OK copied the new .rbf file, renamed and attached it for testing
>
> uartx8:\makeUARTTXs:0:auartx 75.2 (56.5) 102.7 (56.8) 27.5 (0.3) 0.0 (0.0) 
> 0.0 
> (0.0) 95 (95) 197 (63) 0 (0) 0 0 0 0 0 
> SRL16E:\fifosrl:0:asr16e 3.7 (0.0) 4.8 (0.0) 1.2 (0.0) 0.0 (0.0) 0.0 (0.0) 0 
> (0) 16 (0) 0 (0) 0 0 0 0 0 
> look fine now
>
>
> On Thursday, 22 August 2019 20:52:04 UTC+2, Michael Brown wrote:
>
> OK
> I noticed:
> uartx8:\makeUARTTXs:0:auartx 25.9 (25.9) 28.7 (28.7) 2.8 (2.8) 0.0 (0.0) 0.0 
> (0.0) 46 (46) 47 (47) 0 (0) 0 0 0 0 0 
> SRL16E:\fifosrl:0:asr16e 
>
> Were Empty, so I'm currently compiling a correction to the uart tx wireing 
> mishap. brb in 12 min or so...
>
> On Thursday, 22 August 2019 18:50:12 UTC+2, justin White wrote:
>
> I dropped my ADC component on git. This is still the version with the 
> problematic filter, but I figure this would make it easier for my friend or 
> anyone else with interest 

Re: [Machinekit] Re: DE10 Nano suggested development environment?

[Michael Brown]

OK found the flaw in that commit (leading to currupt io), and was able to 
fix it.
Expect a new bit file in about 2 docker compile times :-), 1/2 hour or 
so...

On Friday, 23 August 2019 15:56:59 UTC+2, justin White wrote:
>
> lol thanks, I do appreciate it
>
>
> On Fri, Aug 23, 2019 at 8:56 AM Michael Brown  > wrote:
>
>> Ups Looked like I messed up testing one of my commits: (by copying the 
>> wrong .rbf file)
>> And that that commit (the one for configuring CapSense pins) was 
>> faulty
>>
>> rebasing .. compiling ... and re-testing now  AArrrghh
>>
>>
>> On Friday, 23 August 2019 13:35:22 UTC+2, Michael Brown wrote:
>>>
>>> Looked at the manual for the 8i20 you mentioned:
>>> http://www.mesanet.com/pdf/motion/8i20man.pdf
>>>
>>> Page 5 specifies 2 rx and 2 tx channels  ?
>>>
>>>
>>> On Friday, 23 August 2019 13:16:41 UTC+2, Michael Brown wrote:
>>>>
>>>> You forgot the reply all so I repost here:
>>>>
>>>> I tried it with the first .rbf you posted and still didn't get it to 
>>>>> communicate. I'll try the 2nd one tomorrow.
>>>>> The problem at the moment is that I haven't seen my setup work with a 
>>>>> known good SS config and the DE10-Nano config hasn't worked with known 
>>>>> good 
>>>>> hardware. I can't think of an easy way to test the hardware other than to 
>>>>> scope it which I'll do if you can't find the firmware issue easily.
>>>>
>>>>
>>>> I thought Charles Mentioned a working setup above so I looked thru the 
>>>> thread:
>>>> (Thinking you could test with that DE10_..._DB25 config)
>>>> REcap:
>>>>
>>>> Charles
>>>>> Re: [Machinekit] Re: DE10 Nano suggested development environment?
>>>>> 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. 
>>>>>
>>>>
>>>> So seems like you are missing the 2'nd SSerial in your pin config / Hw 
>>>> setup ?
>>>>
>>>>
>>>>
>>>> On Thursday, 22 August 2019 22:36:35 UTC+2, Michael Brown wrote:
>>>>>
>>>>> I just ran a docker compilation and attach that file 
>>>>> here.(functionality should be the same as the former file,,,(but just in 
>>>>> case) :-)
>>>>>
>>>>> On Thursday, 22 August 2019 21:05:16 UTC+2, Michael Brown wrote:
>>>>>>
>>>>>> OK copied the new .rbf file, renamed and attached it for testing
>>>>>>
>>>>>> uartx8:\makeUARTTXs:0:auartx 75.2 (56.5) 102.7 (56.8) 27.5 (0.3) 0.0 
>>>>>> (0.0) 0.0 (0.0) 95 (95) 197 (63) 0 (0) 0 0 0 0 0 
>>>>>> SRL16E:\fifosrl:0:asr16e 3.7 (0.0) 4.8 (0.0) 1.2 (0.0) 0.0 (0.0) 0.0 
>>>>>> (0.0) 0 (0) 16 (0) 0 (0) 0 0 0 0 0 
>>>>>> look fine now
>>>>>>
>>>>>>
>>>>>> On Thursday, 22 August 2019 20:52:04 UTC+2, Michael Brown wrote:
>>>>>>>
>>>>>>> OK
>>>>>>> I noticed:
>>>>>>> uartx8:\makeUARTTXs:0:auartx 25.9 (25.9) 28.7 (28.7) 2.8 (2.8) 0.0 
>>>>>>> (0.0) 0.0 (0.0) 46 (46) 47 (47) 0 (0) 0 0 0 0 0 
>>>>>>> SRL16E:\fifosrl

Re: [Machinekit] Re: DE10 Nano suggested development environment?

[justin White]

lol thanks, I do appreciate it


On Fri, Aug 23, 2019 at 8:56 AM Michael Brown 
wrote:

> Ups Looked like I messed up testing one of my commits: (by copying the
> wrong .rbf file)
> And that that commit (the one for configuring CapSense pins) was faulty
>
> rebasing .. compiling ... and re-testing now  AArrrghh
>
>
> On Friday, 23 August 2019 13:35:22 UTC+2, Michael Brown wrote:
>>
>> Looked at the manual for the 8i20 you mentioned:
>> http://www.mesanet.com/pdf/motion/8i20man.pdf
>>
>> Page 5 specifies 2 rx and 2 tx channels  ?
>>
>>
>> On Friday, 23 August 2019 13:16:41 UTC+2, Michael Brown wrote:
>>>
>>> You forgot the reply all so I repost here:
>>>
>>> I tried it with the first .rbf you posted and still didn't get it to
>>>> communicate. I'll try the 2nd one tomorrow.
>>>> The problem at the moment is that I haven't seen my setup work with a
>>>> known good SS config and the DE10-Nano config hasn't worked with known good
>>>> hardware. I can't think of an easy way to test the hardware other than to
>>>> scope it which I'll do if you can't find the firmware issue easily.
>>>
>>>
>>> I thought Charles Mentioned a working setup above so I looked thru the
>>> thread:
>>> (Thinking you could test with that DE10_..._DB25 config)
>>> REcap:
>>>
>>> Charles
>>>> Re: [Machinekit] Re: DE10 Nano suggested development environment?
>>>> 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.
>>>>
>>>
>>> So seems like you are missing the 2'nd SSerial in your pin config / Hw
>>> setup ?
>>>
>>>
>>>
>>> On Thursday, 22 August 2019 22:36:35 UTC+2, Michael Brown wrote:
>>>>
>>>> I just ran a docker compilation and attach that file
>>>> here.(functionality should be the same as the former file,,,(but just in
>>>> case) :-)
>>>>
>>>> On Thursday, 22 August 2019 21:05:16 UTC+2, Michael Brown wrote:
>>>>>
>>>>> OK copied the new .rbf file, renamed and attached it for testing
>>>>>
>>>>> uartx8:\makeUARTTXs:0:auartx 75.2 (56.5) 102.7 (56.8) 27.5 (0.3) 0.0
>>>>> (0.0) 0.0 (0.0) 95 (95) 197 (63) 0 (0) 0 0 0 0 0
>>>>> SRL16E:\fifosrl:0:asr16e 3.7 (0.0) 4.8 (0.0) 1.2 (0.0) 0.0 (0.0) 0.0
>>>>> (0.0) 0 (0) 16 (0) 0 (0) 0 0 0 0 0
>>>>> look fine now
>>>>>
>>>>>
>>>>> On Thursday, 22 August 2019 20:52:04 UTC+2, Michael Brown wrote:
>>>>>>
>>>>>> OK
>>>>>> I noticed:
>>>>>> uartx8:\makeUARTTXs:0:auartx 25.9 (25.9) 28.7 (28.7) 2.8 (2.8) 0.0
>>>>>> (0.0) 0.0 (0.0) 46 (46) 47 (47) 0 (0) 0 0 0 0 0
>>>>>> SRL16E:\fifosrl:0:asr16e
>>>>>>
>>>>>> Were Empty, so I'm currently compiling a correction to the uart tx
>>>>>> wireing mishap. brb in 12 min or so...
>>>>>>
>>>>>> On Thursday, 22 August 2019 18:50:12 UTC+2, justin White wrote:
>>>>>>>
>>>>>>> I dropped my ADC component on git. This is still the version with
>>>>>>> the problematic filter, but I figure this would make it easier for my
>>>>>>> friend or anyone else with interest to fix that portion
>>>>>>> https://githu

Re: [Machinekit] Re: DE10 Nano suggested development environment?

[Michael Brown]

Ups Looked like I messed up testing one of my commits: (by copying the 
wrong .rbf file)
And that that commit (the one for configuring CapSense pins) was faulty

rebasing .. compiling ... and re-testing now  AArrrghh


On Friday, 23 August 2019 13:35:22 UTC+2, Michael Brown wrote:
>
> Looked at the manual for the 8i20 you mentioned:
> http://www.mesanet.com/pdf/motion/8i20man.pdf
>
> Page 5 specifies 2 rx and 2 tx channels  ?
>
>
> On Friday, 23 August 2019 13:16:41 UTC+2, Michael Brown wrote:
>>
>> You forgot the reply all so I repost here:
>>
>> I tried it with the first .rbf you posted and still didn't get it to 
>>> communicate. I'll try the 2nd one tomorrow.
>>> The problem at the moment is that I haven't seen my setup work with a 
>>> known good SS config and the DE10-Nano config hasn't worked with known good 
>>> hardware. I can't think of an easy way to test the hardware other than to 
>>> scope it which I'll do if you can't find the firmware issue easily.
>>
>>
>> I thought Charles Mentioned a working setup above so I looked thru the 
>> thread:
>> (Thinking you could test with that DE10_..._DB25 config)
>> REcap:
>>
>> Charles
>>> Re: [Machinekit] Re: DE10 Nano suggested development environment?
>>> 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. 
>>>
>>
>> So seems like you are missing the 2'nd SSerial in your pin config / Hw 
>> setup ?
>>
>>
>>
>> On Thursday, 22 August 2019 22:36:35 UTC+2, Michael Brown wrote:
>>>
>>> I just ran a docker compilation and attach that file here.(functionality 
>>> should be the same as the former file,,,(but just in case) :-)
>>>
>>> On Thursday, 22 August 2019 21:05:16 UTC+2, Michael Brown wrote:
>>>>
>>>> OK copied the new .rbf file, renamed and attached it for testing
>>>>
>>>> uartx8:\makeUARTTXs:0:auartx 75.2 (56.5) 102.7 (56.8) 27.5 (0.3) 0.0 
>>>> (0.0) 0.0 (0.0) 95 (95) 197 (63) 0 (0) 0 0 0 0 0 
>>>> SRL16E:\fifosrl:0:asr16e 3.7 (0.0) 4.8 (0.0) 1.2 (0.0) 0.0 (0.0) 0.0 
>>>> (0.0) 0 (0) 16 (0) 0 (0) 0 0 0 0 0 
>>>> look fine now
>>>>
>>>>
>>>> On Thursday, 22 August 2019 20:52:04 UTC+2, Michael Brown wrote:
>>>>>
>>>>> OK
>>>>> I noticed:
>>>>> uartx8:\makeUARTTXs:0:auartx 25.9 (25.9) 28.7 (28.7) 2.8 (2.8) 0.0 
>>>>> (0.0) 0.0 (0.0) 46 (46) 47 (47) 0 (0) 0 0 0 0 0 
>>>>> SRL16E:\fifosrl:0:asr16e 
>>>>>
>>>>> Were Empty, so I'm currently compiling a correction to the uart tx 
>>>>> wireing mishap. brb in 12 min or so...
>>>>>
>>>>> On Thursday, 22 August 2019 18:50:12 UTC+2, justin White wrote:
>>>>>>
>>>>>> I dropped my ADC component on git. This is still the version with the 
>>>>>> problematic filter, but I figure this would make it easier for my friend 
>>>>>> or 
>>>>>> anyone else with interest to fix that portion
>>>>>> https://github.com/blazini36/ST_DC1-configs/tree/master/ADC_component
>>>>>>
>>>>>> On Thursday, August 22, 2019 at 11:04:23 AM UTC-4, justin White wrote:
>>>>>>>
>>>>>>> The pin comments in the .vhd were a little messed up due to the 
>>>>>>> changes I was making on board revs, copy/paste only goes so far lol. 
>>>>>>> The

Re: [Machinekit] Re: DE10 Nano suggested development environment?

[justin White]

Those are RS422 differential pairs. SS coming directly off of the FPGA is 
actually RS232, then it's split with an RS422 differential transceiver. If 
you ever worked with a Mesa card it's the same deal with the stepgens and 
encoders, everything on the card at the I/O connector is differential other 
that normal inputs and outputs, which is pretty much the way I do 
everything on my board.

This is my SS circuit, the Rx and Tx flags go back to the FPGA, then you'll 
see at the 6pin connector there is 4 total serial pins:

[image: RS422.png]


On Friday, August 23, 2019 at 7:35:22 AM UTC-4, Michael Brown wrote:
>
> Looked at the manual for the 8i20 you mentioned:
> http://www.mesanet.com/pdf/motion/8i20man.pdf
>
> Page 5 specifies 2 rx and 2 tx channels  ?
>
>
> On Friday, 23 August 2019 13:16:41 UTC+2, Michael Brown wrote:
>>
>> You forgot the reply all so I repost here:
>>
>> I tried it with the first .rbf you posted and still didn't get it to 
>>> communicate. I'll try the 2nd one tomorrow.
>>> The problem at the moment is that I haven't seen my setup work with a 
>>> known good SS config and the DE10-Nano config hasn't worked with known good 
>>> hardware. I can't think of an easy way to test the hardware other than to 
>>> scope it which I'll do if you can't find the firmware issue easily.
>>
>>
>> I thought Charles Mentioned a working setup above so I looked thru the 
>> thread:
>> (Thinking you could test with that DE10_..._DB25 config)
>> REcap:
>>
>> Charles
>>> Re: [Machinekit] Re: DE10 Nano suggested development environment?
>>> 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. 
>>>
>>
>> So seems like you are missing the 2'nd SSerial in your pin config / Hw 
>> setup ?
>>
>>
>>
>> On Thursday, 22 August 2019 22:36:35 UTC+2, Michael Brown wrote:
>>>
>>> I just ran a docker compilation and attach that file here.(functionality 
>>> should be the same as the former file,,,(but just in case) :-)
>>>
>>> On Thursday, 22 August 2019 21:05:16 UTC+2, Michael Brown wrote:
>>>>
>>>> OK copied the new .rbf file, renamed and attached it for testing
>>>>
>>>> uartx8:\makeUARTTXs:0:auartx 75.2 (56.5) 102.7 (56.8) 27.5 (0.3) 0.0 
>>>> (0.0) 0.0 (0.0) 95 (95) 197 (63) 0 (0) 0 0 0 0 0 
>>>> SRL16E:\fifosrl:0:asr16e 3.7 (0.0) 4.8 (0.0) 1.2 (0.0) 0.0 (0.0) 0.0 
>>>> (0.0) 0 (0) 16 (0) 0 (0) 0 0 0 0 0 
>>>> look fine now
>>>>
>>>>
>>>> On Thursday, 22 August 2019 20:52:04 UTC+2, Michael Brown wrote:
>>>>>
>>>>> OK
>>>>> I noticed:
>>>>> uartx8:\makeUARTTXs:0:auartx 25.9 (25.9) 28.7 (28.7) 2.8 (2.8) 0.0 
>>>>> (0.0) 0.0 (0.0) 46 (46) 47 (47) 0 (0) 0 0 0 0 0 
>>>>> SRL16E:\fifosrl:0:asr16e 
>>>>>
>>>>> Were Empty, so I'm currently compiling a correction to the uart tx 
>>>>> wireing mishap. brb in 12 min or so...
>>>>>
>>>>> On Thursday, 22 August 2019 18:50:12 UTC+2, justin White wrote:
>>>>>>
>>>>>> I dropped my ADC component on git. This is still the version with the 
>>>>>> problematic filter, but I figure this would make it easier for my friend 
>>>>>> or 
>>>>>> anyone else with interest to fix that portion
>>>>>> https://github.com/blazini36/ST_DC1-configs/tree/master/ADC_component
>>>>>>
>

Re: [Machinekit] Re: DE10 Nano suggested development environment?

[Michael Brown]

Looked at the manual for the 8i20 you mentioned:
http://www.mesanet.com/pdf/motion/8i20man.pdf

Page 5 specifies 2 rx and 2 tx channels  ?


On Friday, 23 August 2019 13:16:41 UTC+2, Michael Brown wrote:
>
> You forgot the reply all so I repost here:
>
> I tried it with the first .rbf you posted and still didn't get it to 
>> communicate. I'll try the 2nd one tomorrow.
>> The problem at the moment is that I haven't seen my setup work with a 
>> known good SS config and the DE10-Nano config hasn't worked with known good 
>> hardware. I can't think of an easy way to test the hardware other than to 
>> scope it which I'll do if you can't find the firmware issue easily.
>
>
> I thought Charles Mentioned a working setup above so I looked thru the 
> thread:
> (Thinking you could test with that DE10_..._DB25 config)
> REcap:
>
> Charles
>> Re: [Machinekit] Re: DE10 Nano suggested development environment?
>> 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. 
>>
>
> So seems like you are missing the 2'nd SSerial in your pin config / Hw 
> setup ?
>
>
>
> On Thursday, 22 August 2019 22:36:35 UTC+2, Michael Brown wrote:
>>
>> I just ran a docker compilation and attach that file here.(functionality 
>> should be the same as the former file,,,(but just in case) :-)
>>
>> On Thursday, 22 August 2019 21:05:16 UTC+2, Michael Brown wrote:
>>>
>>> OK copied the new .rbf file, renamed and attached it for testing
>>>
>>> uartx8:\makeUARTTXs:0:auartx 75.2 (56.5) 102.7 (56.8) 27.5 (0.3) 0.0 
>>> (0.0) 0.0 (0.0) 95 (95) 197 (63) 0 (0) 0 0 0 0 0 
>>> SRL16E:\fifosrl:0:asr16e 3.7 (0.0) 4.8 (0.0) 1.2 (0.0) 0.0 (0.0) 0.0 
>>> (0.0) 0 (0) 16 (0) 0 (0) 0 0 0 0 0 
>>> look fine now
>>>
>>>
>>> On Thursday, 22 August 2019 20:52:04 UTC+2, Michael Brown wrote:
>>>>
>>>> OK
>>>> I noticed:
>>>> uartx8:\makeUARTTXs:0:auartx 25.9 (25.9) 28.7 (28.7) 2.8 (2.8) 0.0 
>>>> (0.0) 0.0 (0.0) 46 (46) 47 (47) 0 (0) 0 0 0 0 0 
>>>> SRL16E:\fifosrl:0:asr16e 
>>>>
>>>> Were Empty, so I'm currently compiling a correction to the uart tx 
>>>> wireing mishap. brb in 12 min or so...
>>>>
>>>> On Thursday, 22 August 2019 18:50:12 UTC+2, justin White wrote:
>>>>>
>>>>> I dropped my ADC component on git. This is still the version with the 
>>>>> problematic filter, but I figure this would make it easier for my friend 
>>>>> or 
>>>>> anyone else with interest to fix that portion
>>>>> https://github.com/blazini36/ST_DC1-configs/tree/master/ADC_component
>>>>>
>>>>> On Thursday, August 22, 2019 at 11:04:23 AM UTC-4, justin White wrote:
>>>>>>
>>>>>> The pin comments in the .vhd were a little messed up due to the 
>>>>>> changes I was making on board revs, copy/paste only goes so far lol. The 
>>>>>> actual pin assignments and "function" comments are all correct with the 
>>>>>> possible exception of the SS pins, can't speak on that until I actually 
>>>>>> see 
>>>>>> it work. I sorted the pins out based on convenient PCB layout rather 
>>>>>> than 
>>>>>> intuitive config files. You'll have to excuse me if I do something silly 
>>>>>> on 
>>>>>> Github, I haven't really hosted any projects before.
>>>>>>
>>>>>> Definitely getting somewhere with SS, I added your firmware a

Re: [Machinekit] Re: DE10 Nano suggested development environment?

[Michael Brown]

You forgot the reply all so I repost here:

I tried it with the first .rbf you posted and still didn't get it to 
> communicate. I'll try the 2nd one tomorrow.
> The problem at the moment is that I haven't seen my setup work with a 
> known good SS config and the DE10-Nano config hasn't worked with known good 
> hardware. I can't think of an easy way to test the hardware other than to 
> scope it which I'll do if you can't find the firmware issue easily.


I thought Charles Mentioned a working setup above so I looked thru the 
thread:
(Thinking you could test with that DE10_..._DB25 config)
REcap:

Charles
> Re: [Machinekit] Re: DE10 Nano suggested development environment?
> 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. 
>

So seems like you are missing the 2'nd SSerial in your pin config / Hw 
setup ?



On Thursday, 22 August 2019 22:36:35 UTC+2, Michael Brown wrote:
>
> I just ran a docker compilation and attach that file here.(functionality 
> should be the same as the former file,,,(but just in case) :-)
>
> On Thursday, 22 August 2019 21:05:16 UTC+2, Michael Brown wrote:
>>
>> OK copied the new .rbf file, renamed and attached it for testing
>>
>> uartx8:\makeUARTTXs:0:auartx 75.2 (56.5) 102.7 (56.8) 27.5 (0.3) 0.0 
>> (0.0) 0.0 (0.0) 95 (95) 197 (63) 0 (0) 0 0 0 0 0 
>> SRL16E:\fifosrl:0:asr16e 3.7 (0.0) 4.8 (0.0) 1.2 (0.0) 0.0 (0.0) 0.0 
>> (0.0) 0 (0) 16 (0) 0 (0) 0 0 0 0 0 
>> look fine now
>>
>>
>> On Thursday, 22 August 2019 20:52:04 UTC+2, Michael Brown wrote:
>>>
>>> OK
>>> I noticed:
>>> uartx8:\makeUARTTXs:0:auartx 25.9 (25.9) 28.7 (28.7) 2.8 (2.8) 0.0 (0.0) 
>>> 0.0 
>>> (0.0) 46 (46) 47 (47) 0 (0) 0 0 0 0 0 
>>> SRL16E:\fifosrl:0:asr16e 
>>>
>>> Were Empty, so I'm currently compiling a correction to the uart tx 
>>> wireing mishap. brb in 12 min or so...
>>>
>>> On Thursday, 22 August 2019 18:50:12 UTC+2, justin White wrote:
>>>>
>>>> I dropped my ADC component on git. This is still the version with the 
>>>> problematic filter, but I figure this would make it easier for my friend 
>>>> or 
>>>> anyone else with interest to fix that portion
>>>> https://github.com/blazini36/ST_DC1-configs/tree/master/ADC_component
>>>>
>>>> On Thursday, August 22, 2019 at 11:04:23 AM UTC-4, justin White wrote:
>>>>>
>>>>> The pin comments in the .vhd were a little messed up due to the 
>>>>> changes I was making on board revs, copy/paste only goes so far lol. The 
>>>>> actual pin assignments and "function" comments are all correct with the 
>>>>> possible exception of the SS pins, can't speak on that until I actually 
>>>>> see 
>>>>> it work. I sorted the pins out based on convenient PCB layout rather than 
>>>>> intuitive config files. You'll have to excuse me if I do something silly 
>>>>> on 
>>>>> Github, I haven't really hosted any projects before.
>>>>>
>>>>> Definitely getting somewhere with SS, I added your firmware and I can 
>>>>> verify from the log file that it now instantiates as "version 43" which 
>>>>> is 
>>>>> the version that my Mesa boards on my standard LinuxCNC machines. I 
>>>>> briefly 
>>>>> tested it and I can't verify any communication though, No new 8i20 pins 
>>>>> showed up in hal when I connected it to my 8i20. SS is kind of tough to 
>>>>> debug on the user end, there's really not much visibility as to what is 
>>>>> going on that I'm aware of. I

Re: [Machinekit] Re: DE10 Nano suggested development environment?

[Michael Brown]

OK
I noticed:
uartx8:\makeUARTTXs:0:auartx 25.9 (25.9) 28.7 (28.7) 2.8 (2.8) 0.0 (0.0) 0.0 
(0.0) 46 (46) 47 (47) 0 (0) 0 0 0 0 0 
SRL16E:\fifosrl:0:asr16e 

Were Empty, so I'm currently compiling a correction to the uart tx wireing 
mishap. brb in 12 min or so...

On Thursday, 22 August 2019 18:50:12 UTC+2, justin White wrote:
>
> I dropped my ADC component on git. This is still the version with the 
> problematic filter, but I figure this would make it easier for my friend or 
> anyone else with interest to fix that portion
> https://github.com/blazini36/ST_DC1-configs/tree/master/ADC_component
>
> On Thursday, August 22, 2019 at 11:04:23 AM UTC-4, justin White wrote:
>>
>> The pin comments in the .vhd were a little messed up due to the changes I 
>> was making on board revs, copy/paste only goes so far lol. The actual pin 
>> assignments and "function" comments are all correct with the possible 
>> exception of the SS pins, can't speak on that until I actually see it work. 
>> I sorted the pins out based on convenient PCB layout rather than intuitive 
>> config files. You'll have to excuse me if I do something silly on Github, I 
>> haven't really hosted any projects before.
>>
>> Definitely getting somewhere with SS, I added your firmware and I can 
>> verify from the log file that it now instantiates as "version 43" which is 
>> the version that my Mesa boards on my standard LinuxCNC machines. I briefly 
>> tested it and I can't verify any communication though, No new 8i20 pins 
>> showed up in hal when I connected it to my 8i20. SS is kind of tough to 
>> debug on the user end, there's really not much visibility as to what is 
>> going on that I'm aware of. It could be a hardware issue yet, I don't have 
>> a convenient means of testing SS, right now I take the nano down to my 
>> mill, plug it in and hope for the best. Now that I have another nano on 
>> hand I can probably get something setup a little better when I get a 
>> chance.  
>>
>>
>>
>>
>>
>> On Thursday, August 22, 2019 at 7:29:46 AM UTC-4, Michael Brown wrote:
>>>
>>> OK
>>> Besides adding SSerial and your config, I have updated the GPIO pin 
>>> names from 1-36 to 0-35,
>>> I noticed something odd with the pin naming of GPIO_0 in your pin file, 
>>> so I was unable to update that.
>>> Could you explain/clean up those gpio and pin names/numbers ?
>>> Is your pin config now final ?
>>>
>>> Lastly I will push the commits,
>>>  and create a pr for the SSerial and your config addition after your 
>>> sucessfull test reports.
>>> After sucessfull online build your bitfile will show up in the 
>>> socfpga-rbf package for both De0 and DE10 board variants.
>>>
>>> Currently the (now hopefully) whole project is here:
>>> https://github.com/the-snowwhite/mksocfpga/tree/sserial-work
>>>
>>>
>>> On Thursday, 22 August 2019 12:52:29 UTC+2, Michael Brown wrote:

 OK
 now:
 MakeSSerials:\GenMakeSSerials:MakeSSerials 649.0 (6.2) 805.6 (6.2) 159.6 
 (0.0) 3.0 (0.0) 0.0 (0.0) 748 (12) 1129 (0) 0 (0) 40960 5 0 0 0 
 Entity instance magicially appears in Quartus after full compile.

 next I'll run the docker compilation and post the bitfiles here

 On Thursday, 22 August 2019 10:26:57 UTC+2, Michael Brown wrote:
>
> Yeah comes to mind the DExx_Cramps projects run on a reduced 
> configuration so only the needed cores are added/included (the one's in 
> the 
> current configs) so...
> SSerial core needs to be included.
> I'll do that asap.
>
> On Thursday, 22 August 2019 03:53:39 UTC+2, justin White wrote:
>>
>> I threw the new FW on the nano and the stepgens are all working now. 
>> Still no SS but I suppose that was to be expected. As PCW said, since 
>> the 
>> version prints as "0", the SS CPU must be broken.
>>
>> On Wednesday, August 21, 2019 at 3:25:53 PM UTC-4, justin White wrote:
>>>
>>> Well that makes sense, my SS pins were on GPIO1_00 and GPIO1_01, 
>>> Stepgens start on GPIO1_02 so it might explain quite a bit.
>>>
>>> I would have tested it out a bit earlier but I went full nerd 
>>> yesterday and built a 3900x/5700xt system I've been working on getting 
>>> running. I got quatus installed and used the config files you attached 
>>> and 
>>> I see all of the stepgens are now full. Going to build the .rbf and set 
>>> it 
>>> back up to test SS again..hopefully it all justworks lol
>>>
>>> thanks fellas
>>>
>>> On Tuesday, August 20, 2019 at 2:06:34 PM UTC-4, Michael Brown wrote:

 Note:
 It did really help to have your full quartus project online to play 
 with, that was probaly what immediately triggered my internal 
 analyzer/debugger :-)

 On Tuesday, 20 August 2019 19:54:02 UTC+2, Michael Brown wrote:
>
> Valid Files Here:
>
> On Tuesday, 20 August 2019 19:50:53 UTC+2, Michael 

Re: [Machinekit] Re: DE10 Nano suggested development environment?

[justin White]

I dropped my ADC component on git. This is still the version with the 
problematic filter, but I figure this would make it easier for my friend or 
anyone else with interest to fix that portion
https://github.com/blazini36/ST_DC1-configs/tree/master/ADC_component

On Thursday, August 22, 2019 at 11:04:23 AM UTC-4, justin White wrote:
>
> The pin comments in the .vhd were a little messed up due to the changes I 
> was making on board revs, copy/paste only goes so far lol. The actual pin 
> assignments and "function" comments are all correct with the possible 
> exception of the SS pins, can't speak on that until I actually see it work. 
> I sorted the pins out based on convenient PCB layout rather than intuitive 
> config files. You'll have to excuse me if I do something silly on Github, I 
> haven't really hosted any projects before.
>
> Definitely getting somewhere with SS, I added your firmware and I can 
> verify from the log file that it now instantiates as "version 43" which is 
> the version that my Mesa boards on my standard LinuxCNC machines. I briefly 
> tested it and I can't verify any communication though, No new 8i20 pins 
> showed up in hal when I connected it to my 8i20. SS is kind of tough to 
> debug on the user end, there's really not much visibility as to what is 
> going on that I'm aware of. It could be a hardware issue yet, I don't have 
> a convenient means of testing SS, right now I take the nano down to my 
> mill, plug it in and hope for the best. Now that I have another nano on 
> hand I can probably get something setup a little better when I get a 
> chance.  
>
>
>
>
>
> On Thursday, August 22, 2019 at 7:29:46 AM UTC-4, Michael Brown wrote:
>>
>> OK
>> Besides adding SSerial and your config, I have updated the GPIO pin names 
>> from 1-36 to 0-35,
>> I noticed something odd with the pin naming of GPIO_0 in your pin file, 
>> so I was unable to update that.
>> Could you explain/clean up those gpio and pin names/numbers ?
>> Is your pin config now final ?
>>
>> Lastly I will push the commits,
>>  and create a pr for the SSerial and your config addition after your 
>> sucessfull test reports.
>> After sucessfull online build your bitfile will show up in the 
>> socfpga-rbf package for both De0 and DE10 board variants.
>>
>> Currently the (now hopefully) whole project is here:
>> https://github.com/the-snowwhite/mksocfpga/tree/sserial-work
>>
>>
>> On Thursday, 22 August 2019 12:52:29 UTC+2, Michael Brown wrote:
>>>
>>> OK
>>> now:
>>> MakeSSerials:\GenMakeSSerials:MakeSSerials 649.0 (6.2) 805.6 (6.2) 159.6 
>>> (0.0) 3.0 (0.0) 0.0 (0.0) 748 (12) 1129 (0) 0 (0) 40960 5 0 0 0 
>>> Entity instance magicially appears in Quartus after full compile.
>>>
>>> next I'll run the docker compilation and post the bitfiles here
>>>
>>> On Thursday, 22 August 2019 10:26:57 UTC+2, Michael Brown wrote:

 Yeah comes to mind the DExx_Cramps projects run on a reduced 
 configuration so only the needed cores are added/included (the one's in 
 the 
 current configs) so...
 SSerial core needs to be included.
 I'll do that asap.

 On Thursday, 22 August 2019 03:53:39 UTC+2, justin White wrote:
>
> I threw the new FW on the nano and the stepgens are all working now. 
> Still no SS but I suppose that was to be expected. As PCW said, since the 
> version prints as "0", the SS CPU must be broken.
>
> On Wednesday, August 21, 2019 at 3:25:53 PM UTC-4, justin White wrote:
>>
>> Well that makes sense, my SS pins were on GPIO1_00 and GPIO1_01, 
>> Stepgens start on GPIO1_02 so it might explain quite a bit.
>>
>> I would have tested it out a bit earlier but I went full nerd 
>> yesterday and built a 3900x/5700xt system I've been working on getting 
>> running. I got quatus installed and used the config files you attached 
>> and 
>> I see all of the stepgens are now full. Going to build the .rbf and set 
>> it 
>> back up to test SS again..hopefully it all justworks lol
>>
>> thanks fellas
>>
>> On Tuesday, August 20, 2019 at 2:06:34 PM UTC-4, Michael Brown wrote:
>>>
>>> Note:
>>> It did really help to have your full quartus project online to play 
>>> with, that was probaly what immediately triggered my internal 
>>> analyzer/debugger :-)
>>>
>>> On Tuesday, 20 August 2019 19:54:02 UTC+2, Michael Brown wrote:

 Valid Files Here:

 On Tuesday, 20 August 2019 19:50:53 UTC+2, Michael Brown wrote:
>
> Ups Sorry sorry sorry ... my BAD  (Suddently my biain kicked 
> in :-) )
> I should have spotted it immediately.
> Culprit is due to my single experimental (verilog) added 
> capasitive depth/touch sensor core.
> This is not a part of the "original mesa hm2 vhdl config system, 
> and the pins are hardwired to:
>  GPIO_1 pins 00 + num sense parameter. (if 

Re: [Machinekit] Re: DE10 Nano suggested development environment?

[justin White]

The pin comments in the .vhd were a little messed up due to the changes I 
was making on board revs, copy/paste only goes so far lol. The actual pin 
assignments and "function" comments are all correct with the possible 
exception of the SS pins, can't speak on that until I actually see it work. 
I sorted the pins out based on convenient PCB layout rather than intuitive 
config files. You'll have to excuse me if I do something silly on Github, I 
haven't really hosted any projects before.

Definitely getting somewhere with SS, I added your firmware and I can 
verify from the log file that it now instantiates as "version 43" which is 
the version that my Mesa boards on my standard LinuxCNC machines. I briefly 
tested it and I can't verify any communication though, No new 8i20 pins 
showed up in hal when I connected it to my 8i20. SS is kind of tough to 
debug on the user end, there's really not much visibility as to what is 
going on that I'm aware of. It could be a hardware issue yet, I don't have 
a convenient means of testing SS, right now I take the nano down to my 
mill, plug it in and hope for the best. Now that I have another nano on 
hand I can probably get something setup a little better when I get a 
chance.  





On Thursday, August 22, 2019 at 7:29:46 AM UTC-4, Michael Brown wrote:
>
> OK
> Besides adding SSerial and your config, I have updated the GPIO pin names 
> from 1-36 to 0-35,
> I noticed something odd with the pin naming of GPIO_0 in your pin file, so 
> I was unable to update that.
> Could you explain/clean up those gpio and pin names/numbers ?
> Is your pin config now final ?
>
> Lastly I will push the commits,
>  and create a pr for the SSerial and your config addition after your 
> sucessfull test reports.
> After sucessfull online build your bitfile will show up in the socfpga-rbf 
> package for both De0 and DE10 board variants.
>
> Currently the (now hopefully) whole project is here:
> https://github.com/the-snowwhite/mksocfpga/tree/sserial-work
>
>
> On Thursday, 22 August 2019 12:52:29 UTC+2, Michael Brown wrote:
>>
>> OK
>> now:
>> MakeSSerials:\GenMakeSSerials:MakeSSerials 649.0 (6.2) 805.6 (6.2) 159.6 
>> (0.0) 3.0 (0.0) 0.0 (0.0) 748 (12) 1129 (0) 0 (0) 40960 5 0 0 0 
>> Entity instance magicially appears in Quartus after full compile.
>>
>> next I'll run the docker compilation and post the bitfiles here
>>
>> On Thursday, 22 August 2019 10:26:57 UTC+2, Michael Brown wrote:
>>>
>>> Yeah comes to mind the DExx_Cramps projects run on a reduced 
>>> configuration so only the needed cores are added/included (the one's in the 
>>> current configs) so...
>>> SSerial core needs to be included.
>>> I'll do that asap.
>>>
>>> On Thursday, 22 August 2019 03:53:39 UTC+2, justin White wrote:

 I threw the new FW on the nano and the stepgens are all working now. 
 Still no SS but I suppose that was to be expected. As PCW said, since the 
 version prints as "0", the SS CPU must be broken.

 On Wednesday, August 21, 2019 at 3:25:53 PM UTC-4, justin White wrote:
>
> Well that makes sense, my SS pins were on GPIO1_00 and GPIO1_01, 
> Stepgens start on GPIO1_02 so it might explain quite a bit.
>
> I would have tested it out a bit earlier but I went full nerd 
> yesterday and built a 3900x/5700xt system I've been working on getting 
> running. I got quatus installed and used the config files you attached 
> and 
> I see all of the stepgens are now full. Going to build the .rbf and set 
> it 
> back up to test SS again..hopefully it all justworks lol
>
> thanks fellas
>
> On Tuesday, August 20, 2019 at 2:06:34 PM UTC-4, Michael Brown wrote:
>>
>> Note:
>> It did really help to have your full quartus project online to play 
>> with, that was probaly what immediately triggered my internal 
>> analyzer/debugger :-)
>>
>> On Tuesday, 20 August 2019 19:54:02 UTC+2, Michael Brown wrote:
>>>
>>> Valid Files Here:
>>>
>>> On Tuesday, 20 August 2019 19:50:53 UTC+2, Michael Brown wrote:

 Ups Sorry sorry sorry ... my BAD  (Suddently my biain kicked in 
 :-) )
 I should have spotted it immediately.
 Culprit is due to my single experimental (verilog) added capasitive 
 depth/touch sensor core.
 This is not a part of the "original mesa hm2 vhdl config system, 
 and the pins are hardwired to:
  GPIO_1 pins 00 + num sense parameter. (if that exact core is 
 enabled in config file)
 ---
 Solution is very simple:
 edit mksocfpga/HW/hm2/config/DExx_Nano_xxx_Cramps/
 atlas_st_fpga_soc_dc1f_ss.sv
 --> parameter Capsense  = 0;
  
 I have tested with:
 (StepGenTag,x"02",  ClockLowTag,x"06",  
 StepGenRateAddr,   StepGenNumRegs, x"00",  
 StepGenMPBitMask),

 and 

Re: [Machinekit] Re: DE10 Nano suggested development environment?

[Michael Brown]

OK
now:
MakeSSerials:\GenMakeSSerials:MakeSSerials 649.0 (6.2) 805.6 (6.2) 159.6 
(0.0) 3.0 (0.0) 0.0 (0.0) 748 (12) 1129 (0) 0 (0) 40960 5 0 0 0 
Entity instance magicially appears in Quartus after full compile.

next I'll run the docker compilation and post the bitfiles here

On Thursday, 22 August 2019 10:26:57 UTC+2, Michael Brown wrote:
>
> Yeah comes to mind the DExx_Cramps projects run on a reduced configuration 
> so only the needed cores are added/included (the one's in the current 
> configs) so...
> SSerial core needs to be included.
> I'll do that asap.
>
> On Thursday, 22 August 2019 03:53:39 UTC+2, justin White wrote:
>>
>> I threw the new FW on the nano and the stepgens are all working now. 
>> Still no SS but I suppose that was to be expected. As PCW said, since the 
>> version prints as "0", the SS CPU must be broken.
>>
>> On Wednesday, August 21, 2019 at 3:25:53 PM UTC-4, justin White wrote:
>>>
>>> Well that makes sense, my SS pins were on GPIO1_00 and GPIO1_01, 
>>> Stepgens start on GPIO1_02 so it might explain quite a bit.
>>>
>>> I would have tested it out a bit earlier but I went full nerd yesterday 
>>> and built a 3900x/5700xt system I've been working on getting running. I got 
>>> quatus installed and used the config files you attached and I see all of 
>>> the stepgens are now full. Going to build the .rbf and set it back up to 
>>> test SS again..hopefully it all justworks lol
>>>
>>> thanks fellas
>>>
>>> On Tuesday, August 20, 2019 at 2:06:34 PM UTC-4, Michael Brown wrote:

 Note:
 It did really help to have your full quartus project online to play 
 with, that was probaly what immediately triggered my internal 
 analyzer/debugger :-)

 On Tuesday, 20 August 2019 19:54:02 UTC+2, Michael Brown wrote:
>
> Valid Files Here:
>
> On Tuesday, 20 August 2019 19:50:53 UTC+2, Michael Brown wrote:
>>
>> Ups Sorry sorry sorry ... my BAD  (Suddently my biain kicked in 
>> :-) )
>> I should have spotted it immediately.
>> Culprit is due to my single experimental (verilog) added capasitive 
>> depth/touch sensor core.
>> This is not a part of the "original mesa hm2 vhdl config system, and 
>> the pins are hardwired to:
>>  GPIO_1 pins 00 + num sense parameter. (if that exact core is enabled 
>> in config file)
>> ---
>> Solution is very simple:
>> edit mksocfpga/HW/hm2/config/DExx_Nano_xxx_Cramps/
>> atlas_st_fpga_soc_dc1f_ss.sv
>> --> parameter Capsense  = 0;
>>  
>> I have tested with:
>> (StepGenTag,x"02",  ClockLowTag,x"06",  
>> StepGenRateAddr,   StepGenNumRegs, x"00",  
>> StepGenMPBitMask),
>>
>> and all 
>> SRL16E:\steptable:1:asr16e 4.2 (0.0) 8.5 (0.0) 4.3 (0.0) 0.0 (0.0) 0.0 
>> (0.0) 5 (0) 17 (0) 0 (0) 0 0 0 0 0 
>> entities show up populated.
>> :-)
>> once again excuse for my temporary brain paralysys..
>> ...
>>
>> On Tuesday, 20 August 2019 16:30:50 UTC+2, Charles Steinkuehler wrote:
>>>
>>> Dig through the synthesis log (*.map.rpt) a bit and look for 
>>> warnings 
>>> that indicate undriven nets.  Sadly, most tool chains consider 
>>> undriven signals a warning vs. an error, so they'll happily optimize 
>>> away huge chunks of your design.  A typical warning would look 
>>> something like: 
>>>
>>> Warning (10541): VHDL Signal Declaration warning at 
>>> HD_Core_CycloneV_pipen1b.vhd(45): used implicit default value for 
>>> signal "clk250_out" because signal was never assigned a value or an 
>>> explicit default value. Use of implicit default value may introduce 
>>> unintended design optimizations. 
>>>
>>> In vim, I use the regex: ^Warning.*$ which highlights the whole line 
>>> (if you're in GUI mode). 
>>>
>>> Note you will see lots of other warnings, most of which are probably 
>>> OK.  In particular, the ever present: 
>>>
>>> Warning (10036): Verilog HDL or VHDL warning at 
>>> HD_Core_CycloneV.vhd(471): object "HDMI_clk" assigned a value but 
>>> never read 
>>>
>>> ...is (usually) perfectly OK, it's similar to an unused variable in 
>>> "C".  This _might_ be an actual error (if the signal was supposed to 
>>> go somewhere) but is typically OK. 
>>>
>>> On 8/20/2019 9:09 AM, justin White wrote: 
>>> > Thanks for the advice Charles. Actually I use this project: 
>>> > 
>>> https://github.com/machinekit/mksocfpga/tree/master/HW/QuartusProjects/DE10_Nano_FB_Cramps
>>>  
>>> > 
>>> > Michael explained it has more functionallity than the DB25 
>>> project, so I've 
>>> > never tried the DB25. 
>>> > 
>>> > Not really up on my git stuff, I forked master and slapped my 
>>> config files 
>>> > in, like I said these are modifications of the "3x24_cap_enc" 
>>> config. 
>>> > 

Re: [Machinekit] Re: DE10 Nano suggested development environment?

[Michael Brown]

Yeah comes to mind the DExx_Cramps projects run on a reduced configuration 
so only the needed cores are added/included (the one's in the current 
configs) so...
SSerial core needs to be included.
I'll do that asap.

On Thursday, 22 August 2019 03:53:39 UTC+2, justin White wrote:
>
> I threw the new FW on the nano and the stepgens are all working now. Still 
> no SS but I suppose that was to be expected. As PCW said, since the version 
> prints as "0", the SS CPU must be broken.
>
> On Wednesday, August 21, 2019 at 3:25:53 PM UTC-4, justin White wrote:
>>
>> Well that makes sense, my SS pins were on GPIO1_00 and GPIO1_01, Stepgens 
>> start on GPIO1_02 so it might explain quite a bit.
>>
>> I would have tested it out a bit earlier but I went full nerd yesterday 
>> and built a 3900x/5700xt system I've been working on getting running. I got 
>> quatus installed and used the config files you attached and I see all of 
>> the stepgens are now full. Going to build the .rbf and set it back up to 
>> test SS again..hopefully it all justworks lol
>>
>> thanks fellas
>>
>> On Tuesday, August 20, 2019 at 2:06:34 PM UTC-4, Michael Brown wrote:
>>>
>>> Note:
>>> It did really help to have your full quartus project online to play 
>>> with, that was probaly what immediately triggered my internal 
>>> analyzer/debugger :-)
>>>
>>> On Tuesday, 20 August 2019 19:54:02 UTC+2, Michael Brown wrote:

 Valid Files Here:

 On Tuesday, 20 August 2019 19:50:53 UTC+2, Michael Brown wrote:
>
> Ups Sorry sorry sorry ... my BAD  (Suddently my biain kicked in 
> :-) )
> I should have spotted it immediately.
> Culprit is due to my single experimental (verilog) added capasitive 
> depth/touch sensor core.
> This is not a part of the "original mesa hm2 vhdl config system, and 
> the pins are hardwired to:
>  GPIO_1 pins 00 + num sense parameter. (if that exact core is enabled 
> in config file)
> ---
> Solution is very simple:
> edit mksocfpga/HW/hm2/config/DExx_Nano_xxx_Cramps/
> atlas_st_fpga_soc_dc1f_ss.sv
> --> parameter Capsense  = 0;
>  
> I have tested with:
> (StepGenTag,x"02",  ClockLowTag,x"06",  
> StepGenRateAddr,   StepGenNumRegs, x"00",  StepGenMPBitMask),
>
> and all 
> SRL16E:\steptable:1:asr16e 4.2 (0.0) 8.5 (0.0) 4.3 (0.0) 0.0 (0.0) 0.0 
> (0.0) 5 (0) 17 (0) 0 (0) 0 0 0 0 0 
> entities show up populated.
> :-)
> once again excuse for my temporary brain paralysys..
> ...
>
> On Tuesday, 20 August 2019 16:30:50 UTC+2, Charles Steinkuehler wrote:
>>
>> Dig through the synthesis log (*.map.rpt) a bit and look for warnings 
>> that indicate undriven nets.  Sadly, most tool chains consider 
>> undriven signals a warning vs. an error, so they'll happily optimize 
>> away huge chunks of your design.  A typical warning would look 
>> something like: 
>>
>> Warning (10541): VHDL Signal Declaration warning at 
>> HD_Core_CycloneV_pipen1b.vhd(45): used implicit default value for 
>> signal "clk250_out" because signal was never assigned a value or an 
>> explicit default value. Use of implicit default value may introduce 
>> unintended design optimizations. 
>>
>> In vim, I use the regex: ^Warning.*$ which highlights the whole line 
>> (if you're in GUI mode). 
>>
>> Note you will see lots of other warnings, most of which are probably 
>> OK.  In particular, the ever present: 
>>
>> Warning (10036): Verilog HDL or VHDL warning at 
>> HD_Core_CycloneV.vhd(471): object "HDMI_clk" assigned a value but 
>> never read 
>>
>> ...is (usually) perfectly OK, it's similar to an unused variable in 
>> "C".  This _might_ be an actual error (if the signal was supposed to 
>> go somewhere) but is typically OK. 
>>
>> On 8/20/2019 9:09 AM, justin White wrote: 
>> > Thanks for the advice Charles. Actually I use this project: 
>> > 
>> https://github.com/machinekit/mksocfpga/tree/master/HW/QuartusProjects/DE10_Nano_FB_Cramps
>>  
>> > 
>> > Michael explained it has more functionallity than the DB25 project, 
>> so I've 
>> > never tried the DB25. 
>> > 
>> > Not really up on my git stuff, I forked master and slapped my 
>> config files 
>> > in, like I said these are modifications of the "3x24_cap_enc" 
>> config. 
>> > https://github.com/blazini36/mksocfpga 
>> > 
>> > The pin assignments are so different from anything else I can't 
>> imagine 
>> > it's looking at another pinfile, it's likely I just didn't modify 
>> something 
>> > I probably should have. I'll try to look into your suggestions a 
>> bit later. 
>> > 
>> > 
>> > On Tuesday, August 20, 2019 at 9:41:57 AM UTC-4, Charles 
>> Steinkuehler wrote: 
>> >> 
>> >> It sounds like the 

Re: [Machinekit] Re: DE10 Nano suggested development environment?

[justin White]

I threw the new FW on the nano and the stepgens are all working now. Still 
no SS but I suppose that was to be expected. As PCW said, since the version 
prints as "0", the SS CPU must be broken.

On Wednesday, August 21, 2019 at 3:25:53 PM UTC-4, justin White wrote:
>
> Well that makes sense, my SS pins were on GPIO1_00 and GPIO1_01, Stepgens 
> start on GPIO1_02 so it might explain quite a bit.
>
> I would have tested it out a bit earlier but I went full nerd yesterday 
> and built a 3900x/5700xt system I've been working on getting running. I got 
> quatus installed and used the config files you attached and I see all of 
> the stepgens are now full. Going to build the .rbf and set it back up to 
> test SS again..hopefully it all justworks lol
>
> thanks fellas
>
> On Tuesday, August 20, 2019 at 2:06:34 PM UTC-4, Michael Brown wrote:
>>
>> Note:
>> It did really help to have your full quartus project online to play with, 
>> that was probaly what immediately triggered my internal 
>> analyzer/debugger :-)
>>
>> On Tuesday, 20 August 2019 19:54:02 UTC+2, Michael Brown wrote:
>>>
>>> Valid Files Here:
>>>
>>> On Tuesday, 20 August 2019 19:50:53 UTC+2, Michael Brown wrote:

 Ups Sorry sorry sorry ... my BAD  (Suddently my biain kicked in :-) 
 )
 I should have spotted it immediately.
 Culprit is due to my single experimental (verilog) added capasitive 
 depth/touch sensor core.
 This is not a part of the "original mesa hm2 vhdl config system, and 
 the pins are hardwired to:
  GPIO_1 pins 00 + num sense parameter. (if that exact core is enabled 
 in config file)
 ---
 Solution is very simple:
 edit mksocfpga/HW/hm2/config/DExx_Nano_xxx_Cramps/
 atlas_st_fpga_soc_dc1f_ss.sv
 --> parameter Capsense  = 0;
  
 I have tested with:
 (StepGenTag,x"02",  ClockLowTag,x"06",  
 StepGenRateAddr,   StepGenNumRegs, x"00",  StepGenMPBitMask),

 and all 
 SRL16E:\steptable:1:asr16e 4.2 (0.0) 8.5 (0.0) 4.3 (0.0) 0.0 (0.0) 0.0 
 (0.0) 5 (0) 17 (0) 0 (0) 0 0 0 0 0 
 entities show up populated.
 :-)
 once again excuse for my temporary brain paralysys..
 ...

 On Tuesday, 20 August 2019 16:30:50 UTC+2, Charles Steinkuehler wrote:
>
> Dig through the synthesis log (*.map.rpt) a bit and look for warnings 
> that indicate undriven nets.  Sadly, most tool chains consider 
> undriven signals a warning vs. an error, so they'll happily optimize 
> away huge chunks of your design.  A typical warning would look 
> something like: 
>
> Warning (10541): VHDL Signal Declaration warning at 
> HD_Core_CycloneV_pipen1b.vhd(45): used implicit default value for 
> signal "clk250_out" because signal was never assigned a value or an 
> explicit default value. Use of implicit default value may introduce 
> unintended design optimizations. 
>
> In vim, I use the regex: ^Warning.*$ which highlights the whole line 
> (if you're in GUI mode). 
>
> Note you will see lots of other warnings, most of which are probably 
> OK.  In particular, the ever present: 
>
> Warning (10036): Verilog HDL or VHDL warning at 
> HD_Core_CycloneV.vhd(471): object "HDMI_clk" assigned a value but 
> never read 
>
> ...is (usually) perfectly OK, it's similar to an unused variable in 
> "C".  This _might_ be an actual error (if the signal was supposed to 
> go somewhere) but is typically OK. 
>
> On 8/20/2019 9:09 AM, justin White wrote: 
> > Thanks for the advice Charles. Actually I use this project: 
> > 
> https://github.com/machinekit/mksocfpga/tree/master/HW/QuartusProjects/DE10_Nano_FB_Cramps
>  
> > 
> > Michael explained it has more functionallity than the DB25 project, 
> so I've 
> > never tried the DB25. 
> > 
> > Not really up on my git stuff, I forked master and slapped my config 
> files 
> > in, like I said these are modifications of the "3x24_cap_enc" 
> config. 
> > https://github.com/blazini36/mksocfpga 
> > 
> > The pin assignments are so different from anything else I can't 
> imagine 
> > it's looking at another pinfile, it's likely I just didn't modify 
> something 
> > I probably should have. I'll try to look into your suggestions a bit 
> later. 
> > 
> > 
> > On Tuesday, August 20, 2019 at 9:41:57 AM UTC-4, Charles 
> Steinkuehler wrote: 
> >> 
> >> It sounds like the synthesis tools are optimizing away the stepgen 
> >> logic, almost certainly because of an issue with signal 
> connectivity 
> >> to the top level I/O pins.  The actual step accumulator is still 
> >> generated because it's value gets read back via the register 
> >> interface, but the steptables are only needed to generate the 
> output 
> >> signals so they're getting 

Re: [Machinekit] Re: DE10 Nano suggested development environment?

[justin White]

Well that makes sense, my SS pins were on GPIO1_00 and GPIO1_01, Stepgens 
start on GPIO1_02 so it might explain quite a bit.

I would have tested it out a bit earlier but I went full nerd yesterday and 
built a 3900x/5700xt system I've been working on getting running. I got 
quatus installed and used the config files you attached and I see all of 
the stepgens are now full. Going to build the .rbf and set it back up to 
test SS again..hopefully it all justworks lol

thanks fellas

On Tuesday, August 20, 2019 at 2:06:34 PM UTC-4, Michael Brown wrote:
>
> Note:
> It did really help to have your full quartus project online to play with, 
> that was probaly what immediately triggered my internal 
> analyzer/debugger :-)
>
> On Tuesday, 20 August 2019 19:54:02 UTC+2, Michael Brown wrote:
>>
>> Valid Files Here:
>>
>> On Tuesday, 20 August 2019 19:50:53 UTC+2, Michael Brown wrote:
>>>
>>> Ups Sorry sorry sorry ... my BAD  (Suddently my biain kicked in :-) )
>>> I should have spotted it immediately.
>>> Culprit is due to my single experimental (verilog) added capasitive 
>>> depth/touch sensor core.
>>> This is not a part of the "original mesa hm2 vhdl config system, and the 
>>> pins are hardwired to:
>>>  GPIO_1 pins 00 + num sense parameter. (if that exact core is enabled in 
>>> config file)
>>> ---
>>> Solution is very simple:
>>> edit mksocfpga/HW/hm2/config/DExx_Nano_xxx_Cramps/
>>> atlas_st_fpga_soc_dc1f_ss.sv
>>> --> parameter Capsense  = 0;
>>>  
>>> I have tested with:
>>> (StepGenTag,x"02",  ClockLowTag,x"06",  
>>> StepGenRateAddr,   StepGenNumRegs, x"00",  StepGenMPBitMask),
>>>
>>> and all 
>>> SRL16E:\steptable:1:asr16e 4.2 (0.0) 8.5 (0.0) 4.3 (0.0) 0.0 (0.0) 0.0 
>>> (0.0) 5 (0) 17 (0) 0 (0) 0 0 0 0 0 
>>> entities show up populated.
>>> :-)
>>> once again excuse for my temporary brain paralysys..
>>> ...
>>>
>>> On Tuesday, 20 August 2019 16:30:50 UTC+2, Charles Steinkuehler wrote:

 Dig through the synthesis log (*.map.rpt) a bit and look for warnings 
 that indicate undriven nets.  Sadly, most tool chains consider 
 undriven signals a warning vs. an error, so they'll happily optimize 
 away huge chunks of your design.  A typical warning would look 
 something like: 

 Warning (10541): VHDL Signal Declaration warning at 
 HD_Core_CycloneV_pipen1b.vhd(45): used implicit default value for 
 signal "clk250_out" because signal was never assigned a value or an 
 explicit default value. Use of implicit default value may introduce 
 unintended design optimizations. 

 In vim, I use the regex: ^Warning.*$ which highlights the whole line 
 (if you're in GUI mode). 

 Note you will see lots of other warnings, most of which are probably 
 OK.  In particular, the ever present: 

 Warning (10036): Verilog HDL or VHDL warning at 
 HD_Core_CycloneV.vhd(471): object "HDMI_clk" assigned a value but 
 never read 

 ...is (usually) perfectly OK, it's similar to an unused variable in 
 "C".  This _might_ be an actual error (if the signal was supposed to 
 go somewhere) but is typically OK. 

 On 8/20/2019 9:09 AM, justin White wrote: 
 > Thanks for the advice Charles. Actually I use this project: 
 > 
 https://github.com/machinekit/mksocfpga/tree/master/HW/QuartusProjects/DE10_Nano_FB_Cramps
  
 > 
 > Michael explained it has more functionallity than the DB25 project, 
 so I've 
 > never tried the DB25. 
 > 
 > Not really up on my git stuff, I forked master and slapped my config 
 files 
 > in, like I said these are modifications of the "3x24_cap_enc" config. 
 > https://github.com/blazini36/mksocfpga 
 > 
 > The pin assignments are so different from anything else I can't 
 imagine 
 > it's looking at another pinfile, it's likely I just didn't modify 
 something 
 > I probably should have. I'll try to look into your suggestions a bit 
 later. 
 > 
 > 
 > On Tuesday, August 20, 2019 at 9:41:57 AM UTC-4, Charles Steinkuehler 
 wrote: 
 >> 
 >> It sounds like the synthesis tools are optimizing away the stepgen 
 >> logic, almost certainly because of an issue with signal connectivity 
 >> to the top level I/O pins.  The actual step accumulator is still 
 >> generated because it's value gets read back via the register 
 >> interface, but the steptables are only needed to generate the output 
 >> signals so they're getting optimized away. 
 >> 
 >> Is your project checked into github somewhere I can grab it?  I can 
 >> try building in the desktop Quartus tools and see what's wrong. 
 >> 
 >> Otherwise, double-check the pin assignments the top-level I/O port 
 >> definitions, and make sure the physical I/O pins are properly 
 >> connected to the hm2 instance. 
 >> 
 >> I took a quick look at the 

Re: [Machinekit] Re: DE10 Nano suggested development environment?

[Michael Brown]

Note:
It did really help to have your full quartus project online to play with, 
that was probaly what immediately triggered my internal 
analyzer/debugger :-)

On Tuesday, 20 August 2019 19:54:02 UTC+2, Michael Brown wrote:
>
> Valid Files Here:
>
> On Tuesday, 20 August 2019 19:50:53 UTC+2, Michael Brown wrote:
>>
>> Ups Sorry sorry sorry ... my BAD  (Suddently my biain kicked in :-) )
>> I should have spotted it immediately.
>> Culprit is due to my single experimental (verilog) added capasitive 
>> depth/touch sensor core.
>> This is not a part of the "original mesa hm2 vhdl config system, and the 
>> pins are hardwired to:
>>  GPIO_1 pins 00 + num sense parameter. (if that exact core is enabled in 
>> config file)
>> ---
>> Solution is very simple:
>> edit mksocfpga/HW/hm2/config/DExx_Nano_xxx_Cramps/
>> atlas_st_fpga_soc_dc1f_ss.sv
>> --> parameter Capsense  = 0;
>>  
>> I have tested with:
>> (StepGenTag,x"02",  ClockLowTag,x"06",  
>> StepGenRateAddr,   StepGenNumRegs, x"00",  StepGenMPBitMask),
>>
>> and all 
>> SRL16E:\steptable:1:asr16e 4.2 (0.0) 8.5 (0.0) 4.3 (0.0) 0.0 (0.0) 0.0 
>> (0.0) 5 (0) 17 (0) 0 (0) 0 0 0 0 0 
>> entities show up populated.
>> :-)
>> once again excuse for my temporary brain paralysys..
>> ...
>>
>> On Tuesday, 20 August 2019 16:30:50 UTC+2, Charles Steinkuehler wrote:
>>>
>>> Dig through the synthesis log (*.map.rpt) a bit and look for warnings 
>>> that indicate undriven nets.  Sadly, most tool chains consider 
>>> undriven signals a warning vs. an error, so they'll happily optimize 
>>> away huge chunks of your design.  A typical warning would look 
>>> something like: 
>>>
>>> Warning (10541): VHDL Signal Declaration warning at 
>>> HD_Core_CycloneV_pipen1b.vhd(45): used implicit default value for 
>>> signal "clk250_out" because signal was never assigned a value or an 
>>> explicit default value. Use of implicit default value may introduce 
>>> unintended design optimizations. 
>>>
>>> In vim, I use the regex: ^Warning.*$ which highlights the whole line 
>>> (if you're in GUI mode). 
>>>
>>> Note you will see lots of other warnings, most of which are probably 
>>> OK.  In particular, the ever present: 
>>>
>>> Warning (10036): Verilog HDL or VHDL warning at 
>>> HD_Core_CycloneV.vhd(471): object "HDMI_clk" assigned a value but 
>>> never read 
>>>
>>> ...is (usually) perfectly OK, it's similar to an unused variable in 
>>> "C".  This _might_ be an actual error (if the signal was supposed to 
>>> go somewhere) but is typically OK. 
>>>
>>> On 8/20/2019 9:09 AM, justin White wrote: 
>>> > Thanks for the advice Charles. Actually I use this project: 
>>> > 
>>> https://github.com/machinekit/mksocfpga/tree/master/HW/QuartusProjects/DE10_Nano_FB_Cramps
>>>  
>>> > 
>>> > Michael explained it has more functionallity than the DB25 project, so 
>>> I've 
>>> > never tried the DB25. 
>>> > 
>>> > Not really up on my git stuff, I forked master and slapped my config 
>>> files 
>>> > in, like I said these are modifications of the "3x24_cap_enc" config. 
>>> > https://github.com/blazini36/mksocfpga 
>>> > 
>>> > The pin assignments are so different from anything else I can't 
>>> imagine 
>>> > it's looking at another pinfile, it's likely I just didn't modify 
>>> something 
>>> > I probably should have. I'll try to look into your suggestions a bit 
>>> later. 
>>> > 
>>> > 
>>> > On Tuesday, August 20, 2019 at 9:41:57 AM UTC-4, Charles Steinkuehler 
>>> wrote: 
>>> >> 
>>> >> It sounds like the synthesis tools are optimizing away the stepgen 
>>> >> logic, almost certainly because of an issue with signal connectivity 
>>> >> to the top level I/O pins.  The actual step accumulator is still 
>>> >> generated because it's value gets read back via the register 
>>> >> interface, but the steptables are only needed to generate the output 
>>> >> signals so they're getting optimized away. 
>>> >> 
>>> >> Is your project checked into github somewhere I can grab it?  I can 
>>> >> try building in the desktop Quartus tools and see what's wrong. 
>>> >> 
>>> >> Otherwise, double-check the pin assignments the top-level I/O port 
>>> >> definitions, and make sure the physical I/O pins are properly 
>>> >> connected to the hm2 instance. 
>>> >> 
>>> >> I took a quick look at the project I think you're using: 
>>> >> 
>>> >> 
>>> >> 
>>> https://github.com/machinekit/mksocfpga/blob/master/HW/QuartusProjects/DE10_Nano_SoC_FB_DB25/
>>>  
>>> >> 
>>> >> ...and the top-level stuff looks OK at first glance.  The important 
>>> >> part is the use of the correct PIN_ library, which gets 
>>> called 
>>> >> out here: 
>>> >> 
>>> >> 
>>> >> 
>>> https://github.com/machinekit/mksocfpga/blob/master/HW/QuartusProjects/DE10_Nano_SoC_FB_DB25/hostmot2_cfg.vhd.in#L74
>>>  
>>> >> 
>>> >> Make sure in your working copy the hostmot2_cfg.vhd file is getting 
>>> >> generated with the correct name in the "use" line, and make sure the 
>>> >> pin file you're including 

Re: [Machinekit] Re: DE10 Nano suggested development environment?

[Michael Brown]

Valid Files Here:

On Tuesday, 20 August 2019 19:50:53 UTC+2, Michael Brown wrote:
>
> Ups Sorry sorry sorry ... my BAD  (Suddently my biain kicked in :-) )
> I should have spotted it immediately.
> Culprit is due to my single experimental (verilog) added capasitive 
> depth/touch sensor core.
> This is not a part of the "original mesa hm2 vhdl config system, and the 
> pins are hardwired to:
>  GPIO_1 pins 00 + num sense parameter. (if that exact core is enabled in 
> config file)
> ---
> Solution is very simple:
> edit mksocfpga/HW/hm2/config/DExx_Nano_xxx_Cramps/
> atlas_st_fpga_soc_dc1f_ss.sv
> --> parameter Capsense  = 0;
>  
> I have tested with:
> (StepGenTag,x"02",  ClockLowTag,x"06",  
> StepGenRateAddr,   StepGenNumRegs, x"00",  StepGenMPBitMask),
>
> and all 
> SRL16E:\steptable:1:asr16e 4.2 (0.0) 8.5 (0.0) 4.3 (0.0) 0.0 (0.0) 0.0 
> (0.0) 5 (0) 17 (0) 0 (0) 0 0 0 0 0 
> entities show up populated.
> :-)
> once again excuse for my temporary brain paralysys..
> ...
>
> On Tuesday, 20 August 2019 16:30:50 UTC+2, Charles Steinkuehler wrote:
>>
>> Dig through the synthesis log (*.map.rpt) a bit and look for warnings 
>> that indicate undriven nets.  Sadly, most tool chains consider 
>> undriven signals a warning vs. an error, so they'll happily optimize 
>> away huge chunks of your design.  A typical warning would look 
>> something like: 
>>
>> Warning (10541): VHDL Signal Declaration warning at 
>> HD_Core_CycloneV_pipen1b.vhd(45): used implicit default value for 
>> signal "clk250_out" because signal was never assigned a value or an 
>> explicit default value. Use of implicit default value may introduce 
>> unintended design optimizations. 
>>
>> In vim, I use the regex: ^Warning.*$ which highlights the whole line 
>> (if you're in GUI mode). 
>>
>> Note you will see lots of other warnings, most of which are probably 
>> OK.  In particular, the ever present: 
>>
>> Warning (10036): Verilog HDL or VHDL warning at 
>> HD_Core_CycloneV.vhd(471): object "HDMI_clk" assigned a value but 
>> never read 
>>
>> ...is (usually) perfectly OK, it's similar to an unused variable in 
>> "C".  This _might_ be an actual error (if the signal was supposed to 
>> go somewhere) but is typically OK. 
>>
>> On 8/20/2019 9:09 AM, justin White wrote: 
>> > Thanks for the advice Charles. Actually I use this project: 
>> > 
>> https://github.com/machinekit/mksocfpga/tree/master/HW/QuartusProjects/DE10_Nano_FB_Cramps
>>  
>> > 
>> > Michael explained it has more functionallity than the DB25 project, so 
>> I've 
>> > never tried the DB25. 
>> > 
>> > Not really up on my git stuff, I forked master and slapped my config 
>> files 
>> > in, like I said these are modifications of the "3x24_cap_enc" config. 
>> > https://github.com/blazini36/mksocfpga 
>> > 
>> > The pin assignments are so different from anything else I can't imagine 
>> > it's looking at another pinfile, it's likely I just didn't modify 
>> something 
>> > I probably should have. I'll try to look into your suggestions a bit 
>> later. 
>> > 
>> > 
>> > On Tuesday, August 20, 2019 at 9:41:57 AM UTC-4, Charles Steinkuehler 
>> wrote: 
>> >> 
>> >> It sounds like the synthesis tools are optimizing away the stepgen 
>> >> logic, almost certainly because of an issue with signal connectivity 
>> >> to the top level I/O pins.  The actual step accumulator is still 
>> >> generated because it's value gets read back via the register 
>> >> interface, but the steptables are only needed to generate the output 
>> >> signals so they're getting optimized away. 
>> >> 
>> >> Is your project checked into github somewhere I can grab it?  I can 
>> >> try building in the desktop Quartus tools and see what's wrong. 
>> >> 
>> >> Otherwise, double-check the pin assignments the top-level I/O port 
>> >> definitions, and make sure the physical I/O pins are properly 
>> >> connected to the hm2 instance. 
>> >> 
>> >> I took a quick look at the project I think you're using: 
>> >> 
>> >> 
>> >> 
>> https://github.com/machinekit/mksocfpga/blob/master/HW/QuartusProjects/DE10_Nano_SoC_FB_DB25/
>>  
>> >> 
>> >> ...and the top-level stuff looks OK at first glance.  The important 
>> >> part is the use of the correct PIN_ library, which gets called 
>> >> out here: 
>> >> 
>> >> 
>> >> 
>> https://github.com/machinekit/mksocfpga/blob/master/HW/QuartusProjects/DE10_Nano_SoC_FB_DB25/hostmot2_cfg.vhd.in#L74
>>  
>> >> 
>> >> Make sure in your working copy the hostmot2_cfg.vhd file is getting 
>> >> generated with the correct name in the "use" line, and make sure the 
>> >> pin file you're including in the project has proper values for IOWidth 
>> >> and IOPorts. 
>> >> 
>> >> You can dig through the first part of the compile log messages to 
>> >> verify the correct PIN file is _really_ getting analyzed and not some 
>> >> other file. 
>> >> 
>> >> I'm also not sure how mixing the system verilog config files with VHDL 
>> >> packages works (I know 

Re: [Machinekit] Re: DE10 Nano suggested development environment?

[Michael Brown]

Ups Sorry sorry sorry ... my BAD  (Suddently my biain kicked in :-) )
I should have spotted it immediately.
Culprit is due to my single experimental (verilog) added capasitive 
depth/touch sensor core.
This is not a part of the "original mesa hm2 vhdl config system, and the 
pins are hardwired to:
 GPIO_1 pins 00 + num sense parameter. (if that exact core is enabled in 
config file)
---
Solution is very simple:
edit 
mksocfpga/HW/hm2/config/DExx_Nano_xxx_Cramps/atlas_st_fpga_soc_dc1f_ss.sv
--> parameter Capsense  = 0;
 
I have tested with:
(StepGenTag,x"02",  ClockLowTag,x"06",  
StepGenRateAddr,   StepGenNumRegs, x"00",  StepGenMPBitMask),

and all 
SRL16E:\steptable:1:asr16e 4.2 (0.0) 8.5 (0.0) 4.3 (0.0) 0.0 (0.0) 0.0 (0.0) 5 
(0) 17 (0) 0 (0) 0 0 0 0 0 
entities show up populated.
:-)
once again excuse for my temporary brain paralysys..
...

On Tuesday, 20 August 2019 16:30:50 UTC+2, Charles Steinkuehler wrote:
>
> Dig through the synthesis log (*.map.rpt) a bit and look for warnings 
> that indicate undriven nets.  Sadly, most tool chains consider 
> undriven signals a warning vs. an error, so they'll happily optimize 
> away huge chunks of your design.  A typical warning would look 
> something like: 
>
> Warning (10541): VHDL Signal Declaration warning at 
> HD_Core_CycloneV_pipen1b.vhd(45): used implicit default value for 
> signal "clk250_out" because signal was never assigned a value or an 
> explicit default value. Use of implicit default value may introduce 
> unintended design optimizations. 
>
> In vim, I use the regex: ^Warning.*$ which highlights the whole line 
> (if you're in GUI mode). 
>
> Note you will see lots of other warnings, most of which are probably 
> OK.  In particular, the ever present: 
>
> Warning (10036): Verilog HDL or VHDL warning at 
> HD_Core_CycloneV.vhd(471): object "HDMI_clk" assigned a value but 
> never read 
>
> ...is (usually) perfectly OK, it's similar to an unused variable in 
> "C".  This _might_ be an actual error (if the signal was supposed to 
> go somewhere) but is typically OK. 
>
> On 8/20/2019 9:09 AM, justin White wrote: 
> > Thanks for the advice Charles. Actually I use this project: 
> > 
> https://github.com/machinekit/mksocfpga/tree/master/HW/QuartusProjects/DE10_Nano_FB_Cramps
>  
> > 
> > Michael explained it has more functionallity than the DB25 project, so 
> I've 
> > never tried the DB25. 
> > 
> > Not really up on my git stuff, I forked master and slapped my config 
> files 
> > in, like I said these are modifications of the "3x24_cap_enc" config. 
> > https://github.com/blazini36/mksocfpga 
> > 
> > The pin assignments are so different from anything else I can't imagine 
> > it's looking at another pinfile, it's likely I just didn't modify 
> something 
> > I probably should have. I'll try to look into your suggestions a bit 
> later. 
> > 
> > 
> > On Tuesday, August 20, 2019 at 9:41:57 AM UTC-4, Charles Steinkuehler 
> wrote: 
> >> 
> >> It sounds like the synthesis tools are optimizing away the stepgen 
> >> logic, almost certainly because of an issue with signal connectivity 
> >> to the top level I/O pins.  The actual step accumulator is still 
> >> generated because it's value gets read back via the register 
> >> interface, but the steptables are only needed to generate the output 
> >> signals so they're getting optimized away. 
> >> 
> >> Is your project checked into github somewhere I can grab it?  I can 
> >> try building in the desktop Quartus tools and see what's wrong. 
> >> 
> >> Otherwise, double-check the pin assignments the top-level I/O port 
> >> definitions, and make sure the physical I/O pins are properly 
> >> connected to the hm2 instance. 
> >> 
> >> I took a quick look at the project I think you're using: 
> >> 
> >> 
> >> 
> https://github.com/machinekit/mksocfpga/blob/master/HW/QuartusProjects/DE10_Nano_SoC_FB_DB25/
>  
> >> 
> >> ...and the top-level stuff looks OK at first glance.  The important 
> >> part is the use of the correct PIN_ library, which gets called 
> >> out here: 
> >> 
> >> 
> >> 
> https://github.com/machinekit/mksocfpga/blob/master/HW/QuartusProjects/DE10_Nano_SoC_FB_DB25/hostmot2_cfg.vhd.in#L74
>  
> >> 
> >> Make sure in your working copy the hostmot2_cfg.vhd file is getting 
> >> generated with the correct name in the "use" line, and make sure the 
> >> pin file you're including in the project has proper values for IOWidth 
> >> and IOPorts. 
> >> 
> >> You can dig through the first part of the compile log messages to 
> >> verify the correct PIN file is _really_ getting analyzed and not some 
> >> other file. 
> >> 
> >> I'm also not sure how mixing the system verilog config files with VHDL 
> >> packages works (I know just enough Verilog to generally be able to 
> >> transcode it to VHDL).  If there's any problems with that, Michael B. 
> >> will have to comment. 
> >> 
> >> On 8/20/2019 8:04 AM, justin White wrote: 
> >>> I deleted my mksocfpga 

Re: [Machinekit] Re: DE10 Nano suggested development environment?

[Charles Steinkuehler]

Dig through the synthesis log (*.map.rpt) a bit and look for warnings
that indicate undriven nets.  Sadly, most tool chains consider
undriven signals a warning vs. an error, so they'll happily optimize
away huge chunks of your design.  A typical warning would look
something like:

Warning (10541): VHDL Signal Declaration warning at
HD_Core_CycloneV_pipen1b.vhd(45): used implicit default value for
signal "clk250_out" because signal was never assigned a value or an
explicit default value. Use of implicit default value may introduce
unintended design optimizations.

In vim, I use the regex: ^Warning.*$ which highlights the whole line
(if you're in GUI mode).

Note you will see lots of other warnings, most of which are probably
OK.  In particular, the ever present:

Warning (10036): Verilog HDL or VHDL warning at
HD_Core_CycloneV.vhd(471): object "HDMI_clk" assigned a value but
never read

...is (usually) perfectly OK, it's similar to an unused variable in
"C".  This _might_ be an actual error (if the signal was supposed to
go somewhere) but is typically OK.

On 8/20/2019 9:09 AM, justin White wrote:
> Thanks for the advice Charles. Actually I use this project:
> https://github.com/machinekit/mksocfpga/tree/master/HW/QuartusProjects/DE10_Nano_FB_Cramps
> 
> Michael explained it has more functionallity than the DB25 project, so I've 
> never tried the DB25.
> 
> Not really up on my git stuff, I forked master and slapped my config files 
> in, like I said these are modifications of the "3x24_cap_enc" config.
> https://github.com/blazini36/mksocfpga
> 
> The pin assignments are so different from anything else I can't imagine 
> it's looking at another pinfile, it's likely I just didn't modify something 
> I probably should have. I'll try to look into your suggestions a bit later.
> 
> 
> On Tuesday, August 20, 2019 at 9:41:57 AM UTC-4, Charles Steinkuehler wrote:
>>
>> It sounds like the synthesis tools are optimizing away the stepgen 
>> logic, almost certainly because of an issue with signal connectivity 
>> to the top level I/O pins.  The actual step accumulator is still 
>> generated because it's value gets read back via the register 
>> interface, but the steptables are only needed to generate the output 
>> signals so they're getting optimized away. 
>>
>> Is your project checked into github somewhere I can grab it?  I can 
>> try building in the desktop Quartus tools and see what's wrong. 
>>
>> Otherwise, double-check the pin assignments the top-level I/O port 
>> definitions, and make sure the physical I/O pins are properly 
>> connected to the hm2 instance. 
>>
>> I took a quick look at the project I think you're using: 
>>
>>
>> https://github.com/machinekit/mksocfpga/blob/master/HW/QuartusProjects/DE10_Nano_SoC_FB_DB25/
>>  
>>
>> ...and the top-level stuff looks OK at first glance.  The important 
>> part is the use of the correct PIN_ library, which gets called 
>> out here: 
>>
>>
>> https://github.com/machinekit/mksocfpga/blob/master/HW/QuartusProjects/DE10_Nano_SoC_FB_DB25/hostmot2_cfg.vhd.in#L74
>>  
>>
>> Make sure in your working copy the hostmot2_cfg.vhd file is getting 
>> generated with the correct name in the "use" line, and make sure the 
>> pin file you're including in the project has proper values for IOWidth 
>> and IOPorts. 
>>
>> You can dig through the first part of the compile log messages to 
>> verify the correct PIN file is _really_ getting analyzed and not some 
>> other file. 
>>
>> I'm also not sure how mixing the system verilog config files with VHDL 
>> packages works (I know just enough Verilog to generally be able to 
>> transcode it to VHDL).  If there's any problems with that, Michael B. 
>> will have to comment. 
>>
>> On 8/20/2019 8:04 AM, justin White wrote: 
>>> I deleted my mksocfpga directory and re-pulled it and I get the same 
>>> results after building the .rbf. 
>>>
>>> Still not quite sure what's going on, though I did catch something in 
>>> Quartus. Using "0A" for stepgens in the pinfile  creates 10 stepgens, 
>> but 
>>> only the first 4 seem to be complete. #4 (the 5th stepgen) when expanded 
>>> shows blank resources for "SRL16E:\steptable:0:asr16e", but does show 
>>> resources for "SRL16E:\steptable:1:asr16e". On every stepgen after they 
>> are 
>>> both blank which looks like it mimics exactly the problem I'm having. If 
>>  "steptable:1" 
>>> relates to the dir pin and "steptable:0" relates to the step pin, it 
>>> explains why I have a working direction pin on #4 but no step pin, and 
>> #5 
>>> doesn't work at all. In this case I'd assume no later stepgens would 
>> work. 
>>>
>>> I'm not really sure how Quartus works with the configs. I'm just 
>> dropping 
>>> the pinfile I made into the 
>>> '../mksocfpga/HW/hm2/config/DExx_Nano_xxx_Cramps' directory and renaming 
>>> the "atlas_3x24_cap_enc.sv" to match my pinfile, which is what I do 
>> with 
>>> the mksocfpga docker build. I don't specify a pinfile or anything when 
>>> running the analysis 

Re: [Machinekit] Re: DE10 Nano suggested development environment?

[justin White]

Thanks for the advice Charles. Actually I use this project:
https://github.com/machinekit/mksocfpga/tree/master/HW/QuartusProjects/DE10_Nano_FB_Cramps

Michael explained it has more functionallity than the DB25 project, so I've 
never tried the DB25.

Not really up on my git stuff, I forked master and slapped my config files 
in, like I said these are modifications of the "3x24_cap_enc" config.
https://github.com/blazini36/mksocfpga

The pin assignments are so different from anything else I can't imagine 
it's looking at another pinfile, it's likely I just didn't modify something 
I probably should have. I'll try to look into your suggestions a bit later.


On Tuesday, August 20, 2019 at 9:41:57 AM UTC-4, Charles Steinkuehler wrote:
>
> It sounds like the synthesis tools are optimizing away the stepgen 
> logic, almost certainly because of an issue with signal connectivity 
> to the top level I/O pins.  The actual step accumulator is still 
> generated because it's value gets read back via the register 
> interface, but the steptables are only needed to generate the output 
> signals so they're getting optimized away. 
>
> Is your project checked into github somewhere I can grab it?  I can 
> try building in the desktop Quartus tools and see what's wrong. 
>
> Otherwise, double-check the pin assignments the top-level I/O port 
> definitions, and make sure the physical I/O pins are properly 
> connected to the hm2 instance. 
>
> I took a quick look at the project I think you're using: 
>
>
> https://github.com/machinekit/mksocfpga/blob/master/HW/QuartusProjects/DE10_Nano_SoC_FB_DB25/
>  
>
> ...and the top-level stuff looks OK at first glance.  The important 
> part is the use of the correct PIN_ library, which gets called 
> out here: 
>
>
> https://github.com/machinekit/mksocfpga/blob/master/HW/QuartusProjects/DE10_Nano_SoC_FB_DB25/hostmot2_cfg.vhd.in#L74
>  
>
> Make sure in your working copy the hostmot2_cfg.vhd file is getting 
> generated with the correct name in the "use" line, and make sure the 
> pin file you're including in the project has proper values for IOWidth 
> and IOPorts. 
>
> You can dig through the first part of the compile log messages to 
> verify the correct PIN file is _really_ getting analyzed and not some 
> other file. 
>
> I'm also not sure how mixing the system verilog config files with VHDL 
> packages works (I know just enough Verilog to generally be able to 
> transcode it to VHDL).  If there's any problems with that, Michael B. 
> will have to comment. 
>
> On 8/20/2019 8:04 AM, justin White wrote: 
> > I deleted my mksocfpga directory and re-pulled it and I get the same 
> > results after building the .rbf. 
> > 
> > Still not quite sure what's going on, though I did catch something in 
> > Quartus. Using "0A" for stepgens in the pinfile  creates 10 stepgens, 
> but 
> > only the first 4 seem to be complete. #4 (the 5th stepgen) when expanded 
> > shows blank resources for "SRL16E:\steptable:0:asr16e", but does show 
> > resources for "SRL16E:\steptable:1:asr16e". On every stepgen after they 
> are 
> > both blank which looks like it mimics exactly the problem I'm having. If 
>  "steptable:1" 
> > relates to the dir pin and "steptable:0" relates to the step pin, it 
> > explains why I have a working direction pin on #4 but no step pin, and 
> #5 
> > doesn't work at all. In this case I'd assume no later stepgens would 
> work. 
> > 
> > I'm not really sure how Quartus works with the configs. I'm just 
> dropping 
> > the pinfile I made into the 
> > '../mksocfpga/HW/hm2/config/DExx_Nano_xxx_Cramps' directory and renaming 
> > the "atlas_3x24_cap_enc.sv" to match my pinfile, which is what I do 
> with 
> > the mksocfpga docker build. I don't specify a pinfile or anything when 
> > running the analysis in Quartus, yet it does seem to catch the changes 
> I've 
> > made to that specific pinfile even though I don't specify anything in 
> > Quartus, I just load the "DE10_Nano_FB_Cramps.qpf" file. 
> > 
> > Pics, QP1 shows all 10 stepgens, QP2 shows the difference between the 
> > working #3 stepgen (0-3 all look the same) and #4 and #5 where the 
> problem 
> > starts. "combinational ALUTS" and every feild after is blank. 
> > 
> > [image: QP1.png] 
> > 
> > [image: QP2.png] 
> > 
> > 
> > 
> > 
> > 
> > On Monday, August 19, 2019 at 5:00:11 PM UTC-4, Michael Brown wrote: 
> >> 
> >> Thanx for the clairifying Charles, I doublechecked tha line and it 
> reads: 
> >> (StepGenTag,x"02",  ClockLowTag,x"06",   
> >> StepGenRateAddr,   StepGenNumRegs, x"00", 
>  StepGenMPBitMask), 
> >> 
> >> So that should be ok... 
> >> 
> >> On Monday, 19 August 2019 22:37:42 UTC+2, Charles Steinkuehler wrote: 
> >>> 
> >>> 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 

Re: [Machinekit] Re: DE10 Nano suggested development environment?

[Charles Steinkuehler]

It sounds like the synthesis tools are optimizing away the stepgen
logic, almost certainly because of an issue with signal connectivity
to the top level I/O pins.  The actual step accumulator is still
generated because it's value gets read back via the register
interface, but the steptables are only needed to generate the output
signals so they're getting optimized away.

Is your project checked into github somewhere I can grab it?  I can
try building in the desktop Quartus tools and see what's wrong.

Otherwise, double-check the pin assignments the top-level I/O port
definitions, and make sure the physical I/O pins are properly
connected to the hm2 instance.

I took a quick look at the project I think you're using:

https://github.com/machinekit/mksocfpga/blob/master/HW/QuartusProjects/DE10_Nano_SoC_FB_DB25/

...and the top-level stuff looks OK at first glance.  The important
part is the use of the correct PIN_ library, which gets called
out here:

https://github.com/machinekit/mksocfpga/blob/master/HW/QuartusProjects/DE10_Nano_SoC_FB_DB25/hostmot2_cfg.vhd.in#L74

Make sure in your working copy the hostmot2_cfg.vhd file is getting
generated with the correct name in the "use" line, and make sure the
pin file you're including in the project has proper values for IOWidth
and IOPorts.

You can dig through the first part of the compile log messages to
verify the correct PIN file is _really_ getting analyzed and not some
other file.

I'm also not sure how mixing the system verilog config files with VHDL
packages works (I know just enough Verilog to generally be able to
transcode it to VHDL).  If there's any problems with that, Michael B.
will have to comment.

On 8/20/2019 8:04 AM, justin White wrote:
> I deleted my mksocfpga directory and re-pulled it and I get the same 
> results after building the .rbf.
> 
> Still not quite sure what's going on, though I did catch something in 
> Quartus. Using "0A" for stepgens in the pinfile  creates 10 stepgens, but 
> only the first 4 seem to be complete. #4 (the 5th stepgen) when expanded 
> shows blank resources for "SRL16E:\steptable:0:asr16e", but does show 
> resources for "SRL16E:\steptable:1:asr16e". On every stepgen after they are 
> both blank which looks like it mimics exactly the problem I'm having. If  
> "steptable:1" 
> relates to the dir pin and "steptable:0" relates to the step pin, it 
> explains why I have a working direction pin on #4 but no step pin, and #5 
> doesn't work at all. In this case I'd assume no later stepgens would work.
> 
> I'm not really sure how Quartus works with the configs. I'm just dropping 
> the pinfile I made into the 
> '../mksocfpga/HW/hm2/config/DExx_Nano_xxx_Cramps' directory and renaming 
> the "atlas_3x24_cap_enc.sv" to match my pinfile, which is what I do with 
> the mksocfpga docker build. I don't specify a pinfile or anything when 
> running the analysis in Quartus, yet it does seem to catch the changes I've 
> made to that specific pinfile even though I don't specify anything in 
> Quartus, I just load the "DE10_Nano_FB_Cramps.qpf" file.
> 
> Pics, QP1 shows all 10 stepgens, QP2 shows the difference between the 
> working #3 stepgen (0-3 all look the same) and #4 and #5 where the problem 
> starts. "combinational ALUTS" and every feild after is blank.
> 
> [image: QP1.png]
> 
> [image: QP2.png]
> 
> 
> 
> 
> 
> On Monday, August 19, 2019 at 5:00:11 PM UTC-4, Michael Brown wrote:
>>
>> Thanx for the clairifying Charles, I doublechecked tha line and it reads:
>> (StepGenTag,x"02",  ClockLowTag,x"06",  
>> StepGenRateAddr,   StepGenNumRegs, x"00",  StepGenMPBitMask),
>>
>> So that should be ok...
>>
>> On Monday, 19 August 2019 22:37:42 UTC+2, Charles Steinkuehler wrote:
>>>
>>> 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 

Re: [Machinekit] Re: DE10 Nano suggested development environment?

[Michael Brown]

Thanx for the clairifying Charles, I doublechecked tha line and it reads:
(StepGenTag,x"02",  ClockLowTag,x"06",  
StepGenRateAddr,   StepGenNumRegs, x"00",  StepGenMPBitMask),

So that should be ok...

On Monday, 19 August 2019 22:37:42 UTC+2, Charles Steinkuehler wrote:
>
> 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>
>  
>
> > 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: 
> >>> 
> >>> [image: QP.png] 
> >>> 
> >>> 
> >>> 
> >>> 
> >>> 
> >>> 
> >>> On Monday, August 19, 2019 at 7:46:58 AM UTC-4, Michael Brown wrote: 
>  
>  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: 
>  
>  [image: Quartus_DE10_Nano_FB_Default_Num-Stepgens_Compiled.png] 
>  
>  
>  
>  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>
>  
>
> > 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: 
> > 
> > [image: Quartus_Num_Stepgens.png] 
> >   
> > 
> > On Monday, 19 August 2019 00:31:53 UTC+2, justin White wrote: 
> >> 
> >> 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 
> 

Re: [Machinekit] Re: DE10 Nano suggested development environment?

[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: 
> 
> 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:
>>>
>>> [image: QP.png]
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Monday, August 19, 2019 at 7:46:58 AM UTC-4, Michael Brown wrote:

 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:

 [image: Quartus_DE10_Nano_FB_Default_Num-Stepgens_Compiled.png]



 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 ?
>
> Also You can look in the Compiled (Or after analysis & elaboration) 
> Quartus project and see how many stepgens are elaborated like in below 
> pic:
>
> [image: Quartus_Num_Stepgens.png]
>  
>
> On Monday, 19 August 2019 00:31:53 UTC+2, justin White wrote:
>>
>> 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 

Re: [Machinekit] Re: DE10 Nano suggested development environment?

[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 


On Monday, 19 August 2019 17:33:29 UTC+2, 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: 
>>> 
>>> 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:
>
> [image: QP.png]
>
>
>
>
>
>
> On Monday, August 19, 2019 at 7:46:58 AM UTC-4, Michael Brown wrote:
>>
>> 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:
>>
>> [image: Quartus_DE10_Nano_FB_Default_Num-Stepgens_Compiled.png]
>>
>>
>>
>> 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 ?
>>>
>>> Also You can look in the Compiled (Or after analysis & elaboration) 
>>> Quartus project and see how many stepgens are elaborated like in below pic:
>>>
>>> [image: Quartus_Num_Stepgens.png]
>>>  
>>>
>>> On Monday, 19 August 2019 00:31:53 UTC+2, justin White wrote:

 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



 On Saturday, August 17, 2019 at 6:40:07 AM UTC-4, Michael Brown wrote:
>
> 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   

Re: [Machinekit] Re: DE10 Nano suggested development environment?

[Michael Brown]

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: 
 
 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:
>>
>> [image: QP.png]
>>
>>
>>
>>
>>
>>
>> On Monday, August 19, 2019 at 7:46:58 AM UTC-4, Michael Brown wrote:
>>>
>>> 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:
>>>
>>> [image: Quartus_DE10_Nano_FB_Default_Num-Stepgens_Compiled.png]
>>>
>>>
>>>
>>> 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 ?

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

 [image: Quartus_Num_Stepgens.png]
  

 On Monday, 19 August 2019 00:31:53 UTC+2, justin White wrote:
>
> 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 

Re: [Machinekit] Re: DE10 Nano suggested development environment?

[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
,   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: 
>>> 
>>> 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:
>
> [image: QP.png]
>
>
>
>
>
>
> On Monday, August 19, 2019 at 7:46:58 AM UTC-4, Michael Brown wrote:
>>
>> 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:
>>
>> [image: Quartus_DE10_Nano_FB_Default_Num-Stepgens_Compiled.png]
>>
>>
>>
>> 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 ?
>>>
>>> Also You can look in the Compiled (Or after analysis & elaboration) 
>>> Quartus project and see how many stepgens are elaborated like in below pic:
>>>
>>> [image: Quartus_Num_Stepgens.png]
>>>  
>>>
>>> On Monday, 19 August 2019 00:31:53 UTC+2, justin White wrote:

 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



 On Saturday, August 17, 2019 at 6:40:07 AM UTC-4, Michael Brown wrote:
>
> OK back to being able to be online with my workstation:
> I have allways had a fight setting up proper display 

Re: [Machinekit] Re: DE10 Nano suggested development environment?

[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



On Saturday, August 17, 2019 at 6:40:07 AM UTC-4, Michael Brown wrote:
>
> 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 = <0x0001 0x00031000 0x0080>;
> max-width = <1024>;
> max-height = <768>;
> bits-per-color = <0x8>;
> colors-per-beat = <0x4>;
> beats-per-pixel = <0x1>;
> mem-word-width = <0x80>;
> };
>
>
> On Friday, 9 August 2019 03:55:13 UTC+2, justin White wrote:
>>
>>
>>
>> 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.
>>
>
> 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  :-)
>  
>

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 

Re: [Machinekit] Re: DE10 Nano suggested development environment?

[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 = <0x0001 0x00031000 0x0080>;
max-width = <1024>;
max-height = <768>;
bits-per-color = <0x8>;
colors-per-beat = <0x4>;
beats-per-pixel = <0x1>;
mem-word-width = <0x80>;
};


On Friday, 9 August 2019 03:55:13 UTC+2, justin White wrote:
>
>
>
> 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.
>

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

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/machinekit/734db143-8b39-4d42-804a-db00b65777a1%40googlegroups.com.

Re: [Machinekit] Re: DE10 Nano suggested development environment?

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

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/machinekit/a8ce5ea6-1cd1-4f72-b8dd-95776fd6025d%40googlegroups.com.

Re: [Machinekit] Re: DE10 Nano suggested development environment?

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

On Tue, 30 Jul 2019, 00.16 justin White  wrote:

> 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.
>
> [image: remmina_DE10-Nano MK VNC_192.168.1.125_2019729-53925.864069.png]
>
>
>
> --
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/machinekit/dfe26639-27a7-4ba6-b9bf-344bd1d0da9e%40googlegroups.com
> 
> .
>

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/machinekit/CAGKWNWPV48N-D8-ZEY6KgyfsOHbCt4rvhk%3D9x%3D%3D3_V%3Df-koPHA%40mail.gmail.com.

Re: [Machinekit] Re: DE10 Nano suggested development environment?

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

[image: remmina_DE10-Nano MK VNC_192.168.1.125_2019729-53925.864069.png]
 
  

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/machinekit/dfe26639-27a7-4ba6-b9bf-344bd1d0da9e%40googlegroups.com.

Re: [Machinekit] Re: DE10 Nano suggested development environment?

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

On Sat, 27 Jul 2019, 00.08 justin White  wrote:

> 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,
>SSerialNumRegs, x"10",  SSerialMPBitMask),
>
> if:
>
> (SSerialTag,x"00",  ClockLowTag,x"01",  SSerialCommandAddr,
>SSerialNumRegs, x"10",  SSerialMPBitMask),
>
> it will build fine, but SS does not work.
>
>
>
>
>
>
> --
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/machinekit/09220b16-ba90-4f24-b5fb-787c2f95ab35%40googlegroups.com
> 
> .
>

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/machinekit/CAGKWNWPzRAZDP%3DAX%3DsOU1qgOKYb49fSM86ziYa8n%2Bedam2hS3g%40mail.gmail.com.

Re: [Machinekit] Re: DE10 Nano suggested development environment?

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

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/machinekit/9e682d3f-1691-4077-a9a9-ade71cbfebeb%40googlegroups.com.

Re: [Machinekit] Re: DE10 Nano suggested development environment?

[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 

 
On Friday, July 26, 2019 at 6:42:04 PM UTC-4, Charles Steinkuehler wrote:
>
> On 7/26/2019 5:08 PM, justin White wrote: 
> > 
> >> 
> >> 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, 
> 
> > SSerialNumRegs, x"10",  SSerialMPBitMask), 
> > 
> > if: 
> > 
> > (SSerialTag,x"00",  ClockLowTag,x"01",  SSerialCommandAddr, 
> 
> > SSerialNumRegs, x"10",  SSerialMPBitMask), 
> > 
> > it will build fine, but SS does not work. 
>
> 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  
>

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/machinekit/d6c14465-bdaa-450d-9cb4-999aced3116d%40googlegroups.com.

Re: [Machinekit] Re: DE10 Nano suggested development environment?

[Charles Steinkuehler]

On 7/26/2019 5:08 PM, justin White wrote:
> 
>>
>> 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,
> SSerialNumRegs, x"10",  SSerialMPBitMask),
> 
> if:
> 
> (SSerialTag,x"00",  ClockLowTag,x"01",  SSerialCommandAddr,
> SSerialNumRegs, x"10",  SSerialMPBitMask),
> 
> it will build fine, but SS does not work.

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
char...@steinkuehler.net

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/machinekit/160aeed4-bc30-0351-57c0-a033f55d2d5a%40steinkuehler.net.

Re: [Machinekit] Re: DE10 Nano suggested development environment?

[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,
SSerialNumRegs, x"10",  SSerialMPBitMask),

if:

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

it will build fine, but SS does not work.




 

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/machinekit/09220b16-ba90-4f24-b5fb-787c2f95ab35%40googlegroups.com.
~$ docker pull cdsteinkuehler/jessie-quartus-15.1.2
Using default tag: latest
latest: Pulling from cdsteinkuehler/jessie-quartus-15.1.2
Digest: sha256:78dd9671b810920632a8454ef76cc6a88a702df810c3d400d0da044451a0a0f8
Status: Image is up to date for cdsteinkuehler/jessie-quartus-15.1.2:latest
~$ git clone https://github.com/machinekit/mksocfpga.git/
fatal: destination path 'mksocfpga' already exists and is not an empty 
directory.
~$ cd mksocfpga
~/mksocfpga$ docker run -itv $(pwd):/work cdsteinkuehler/jessie-quartus-15.1.2 
/bin/bash
builder@44885c2907a7:/$ cd /work/HW/QuartusProjects/DE10_Nano_FB_Cramps
Create HDL design files for synthesis
2019.07.26.21:52:15 Info: qsys-generate 
/work/HW/QuartusProjects/DE10_Nano_FB_Cramps/soc_system.qsys 
--synthesis=VERILOG 
--output-directory=/work/HW/QuartusProjects/DE10_Nano_FB_Cramps/soc_system/synthesis
 --family="Cyclone V" --part=5CSEBA6U23I7
2019.07.26.21:52:15 Info: Loading DE10_Nano_FB_Cramps/soc_system.qsys
2019.07.26.21:52:15 Info: Reading input file
2019.07.26.21:52:15 Info: Adding ILC [interrupt_latency_counter 15.1]
2019.07.26.21:52:15 Info: Parameterizing module ILC
2019.07.26.21:52:15 Info: Adding alt_vip_itc_0 [alt_vip_itc 14.0]
2019.07.26.21:52:15 Info: Parameterizing module alt_vip_itc_0
2019.07.26.21:52:15 Info: Adding alt_vip_vfr_hdmi [alt_vip_vfr 14.0]
2019.07.26.21:52:15 Info: Parameterizing module alt_vip_vfr_hdmi
2019.07.26.21:52:15 Info: Adding button_pio [altera_avalon_pio 15.1]
2019.07.26.21:52:15 Info: Parameterizing module button_pio
2019.07.26.21:52:15 Info: Adding clk_0 [clock_source 15.1]
2019.07.26.21:52:15 Info: Parameterizing module clk_0
2019.07.26.21:52:15 Info: Adding dipsw_pio [altera_avalon_pio 15.1]
2019.07.26.21:52:15 Info: Parameterizing module dipsw_pio
2019.07.26.21:52:15 Info: Adding fpga_only_master [altera_jtag_avalon_master 
15.1]
2019.07.26.21:52:15 Info: Parameterizing module fpga_only_master
2019.07.26.21:52:15 Info: Adding hm2reg_io_0 [hm2reg_io 1.0]
2019.07.26.21:52:15 Info: Parameterizing module hm2reg_io_0
2019.07.26.21:52:15 Info: Adding hps_0 [altera_hps 15.1]
2019.07.26.21:52:15 Info: Parameterizing module hps_0
2019.07.26.21:52:15 Info: Adding hps_only_master [altera_jtag_avalon_master 
15.1]
2019.07.26.21:52:15 Info: Parameterizing module hps_only_master
2019.07.26.21:52:15 Info: Adding intr_capturer_0 [intr_capturer 100.99.98.97]
2019.07.26.21:52:15 Info: Parameterizing module intr_capturer_0
2019.07.26.21:52:15 Info: Adding jtag_uart [altera_avalon_jtag_uart 15.1]
2019.07.26.21:52:15 Info: Parameterizing module jtag_uart
2019.07.26.21:52:15 Info: Adding led_pio [altera_avalon_pio 15.1]
2019.07.26.21:52:15 Info: Parameterizing module led_pio
2019.07.26.21:52:15 Info: Adding mm_bridge_0 [altera_avalon_mm_bridge 15.1]
2019.07.26.21:52:15 Info: Parameterizing module mm_bridge_0
2019.07.26.21:52:15 Info: Adding pll_lcd [altera_pll 15.1]
2019.07.26.21:52:15 Info: Parameterizing module pll_lcd
2019.07.26.21:52:15 Info: Adding sysid_qsys [altera_avalon_sysid_qsys 15.1]
2019.07.26.21:52:15 Info: Parameterizing module sysid_qsys
2019.07.26.21:52:15 Info: Building connections
2019.07.26.21:52:15 Info: Parameterizing connections
2019.07.26.21:52:15 Info: Validating
2019.07.26.21:52:23 Info: Done reading input file
2019.07.26.21:52:25 Warning: soc_system.alt_vip_vfr_hdmi: The module properties 
SIMULATION_MODEL_IN_VERILOG and SIMULATION_MODEL_IN_VHDL can not both be set 
when using the SIMULATION file property: src_hdl/alt_vipvfr131_vfr.v, 
src_hdl/alt_vipvfr131_vfr_controller.v, 
src_hdl/alt_vipvfr131_vfr_control_packet_encoder.v, 
src_hdl/alt_vipvfr131_prc.v, src_hdl/alt_vipvfr131_prc_core.v, 
src_hdl/alt_vipvfr131_prc_read_master.v, 
/home/builder/altera_lite/15.1/ip/altera/frame_reader/common_hdl/alt_vipvfr131_common_package.vhd,
 
/home/builder/altera_lite/15.1/ip/altera/frame_reader/common_hdl/alt_vipvfr131_common_avalon_mm_bursting_master_fifo.vhd,
 

Re: [Machinekit] Re: DE10 Nano suggested development environment?

[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  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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/machinekit/29f2fb1a-ed2a-49f0-9f58-63e6c65dc9f5%40googlegroups.com
> .
>

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/machinekit/CAGKWNWOjqW38duo-LgMFrw_-GfAfiEmxpuB8HdhrDMAb7RTOog%40mail.gmail.com.

Re: [Machinekit] Re: DE10 Nano suggested development environment?

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

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/machinekit/29f2fb1a-ed2a-49f0-9f58-63e6c65dc9f5%40googlegroups.com.

Re: [Machinekit] Re: DE10 Nano suggested development environment?

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

On Fri, 26 Jul 2019, 04.57 justin White  wrote:

> 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 * A9 AD A9 A9 AD E9
> ..
> *230400 8n1*  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 intrinsicslibwebsockets=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)
> 

Re: [Machinekit] Re: DE10 Nano suggested development environment?

[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



On Thursday, July 25, 2019 at 10:57:01 PM UTC-4, justin White wrote:
>
> 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 * A9 AD A9 A9 AD E9  
> ..
> *230400 8n1*  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 intrinsicslibwebsockets=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 

Re: [Machinekit] Re: DE10 Nano suggested development environment?

[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 * A9 AD A9 A9 AD E9  
..
*230400 8n1*  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 intrinsicslibwebsockets=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 

Re: [Machinekit] Re: DE10 Nano suggested development environment?

[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
char...@steinkuehler.net

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/machinekit/9d431977-01e2-35c6-6ad5-7b545a4ff14a%40steinkuehler.net.

Re: [Machinekit] Re: DE10 Nano suggested development environment?

[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  


On Tuesday, July 23, 2019 at 10:51:31 AM UTC-4, Charles Steinkuehler wrote:
>
> 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  
>

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/machinekit/168f575c-fe3d-48a3-adc9-8ee24ff97016%40googlegroups.com.

Re: [Machinekit] Re: DE10 Nano suggested development environment?

[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
char...@steinkuehler.net

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/machinekit/1297e78c-e0b9-c264-e912-9a2cdfff998e%40steinkuehler.net.

Re: [Machinekit] Re: DE10 Nano suggested development environment?

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

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/machinekit/6b469430-5e9e-4773-9c98-b70d9e2ed179%40googlegroups.com.

Re: [Machinekit] Re: DE10 Nano suggested development environment?

[Michael Brown]

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

On Sat, 20 Jul 2019, 16.03 Michael Brown  wrote:

> Monitor resolution is fixed. Changes are done in the qsys video frame
> buffer cores.
>
> On Thu, 18 Jul 2019, 01.59 justin White  wrote:
>
>> 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.
>>
>> On Sunday, July 14, 2019 at 5:25:31 PM UTC-4, justin White wrote:
>>>
>>> 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=00" 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.
>>>
>>> On Sunday, July 14, 2019 at 6:08:13 AM UTC-4, justin White wrote:

 Any insight on the issue with the rbf?
>>>
>>> --
>> 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+unsubscr...@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
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/machinekit/CAGKWNWMYu-QE60QUEJhhGOv-%3D8uLfjoTdpM2-Gw%2Bs_osmrQFYg%40mail.gmail.com.

Re: [Machinekit] Re: DE10 Nano suggested development environment?

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

On 7/18/2019 8:11 AM, justin White wrote:
> 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
char...@steinkuehler.net

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@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/98f02822-da76-6107-e4c5-1e3a65ba06a5%40steinkuehler.net.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Re: DE10 Nano suggested development environment?

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

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@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/0824bc35-2f19-4649-b564-a7b4bea71b7f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Re: DE10 Nano suggested development environment?

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

On 7/17/2019 10:38 PM, justin White wrote:
> 
> Same as attached on july 13 except I changed SS numinst to 1.
> 
> On Wednesday, July 17, 2019 at 11:24:07 PM UTC-4, Charles Steinkuehler 
> wrote:
>>
>> Got a link to your pin file for review? 
>>
>> On 7/17/2019 6:59 PM, justin White wrote: 
>>> 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. 
>>>
>>> On Sunday, July 14, 2019 at 5:25:31 PM UTC-4, justin White wrote: 

 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=00" 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. 

 On Sunday, July 14, 2019 at 6:08:13 AM UTC-4, justin White wrote: 
>
> Any insight on the issue with the rbf? 


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


-- 
Charles Steinkuehler
char...@steinkuehler.net

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@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/dadd434b-8b92-930a-d4fd-6b678b9aa5ea%40steinkuehler.net.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Re: DE10 Nano suggested development environment?

[justin White]

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

On Wednesday, July 17, 2019 at 11:24:07 PM UTC-4, Charles Steinkuehler 
wrote:
>
> Got a link to your pin file for review? 
>
> On 7/17/2019 6:59 PM, justin White wrote: 
> > 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. 
> > 
> > On Sunday, July 14, 2019 at 5:25:31 PM UTC-4, justin White wrote: 
> >> 
> >> 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=00" 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. 
> >> 
> >> On Sunday, July 14, 2019 at 6:08:13 AM UTC-4, justin White wrote: 
> >>> 
> >>> Any insight on the issue with the rbf? 
> >> 
> >> 
> > 
>
>
> -- 
> Charles Steinkuehler 
> cha...@steinkuehler.net  
>

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@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/b24072c9-aa9c-4283-bcd5-7659d2f28749%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


PIN_st_fpga_soc_dc1e_ss.vhd
Description: Binary data

Re: [Machinekit] Re: DE10 Nano suggested development environment?

[Charles Steinkuehler]

Got a link to your pin file for review?

On 7/17/2019 6:59 PM, justin White wrote:
> 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. 
> 
> On Sunday, July 14, 2019 at 5:25:31 PM UTC-4, justin White wrote:
>>
>> 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=00" 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.
>>
>> On Sunday, July 14, 2019 at 6:08:13 AM UTC-4, justin White wrote:
>>>
>>> Any insight on the issue with the rbf?
>>
>>
> 


-- 
Charles Steinkuehler
char...@steinkuehler.net

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@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/c75d0114-9965-6268-9460-a745501ed0ad%40steinkuehler.net.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Re: DE10 Nano suggested development environment?

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

On Sunday, July 14, 2019 at 5:25:31 PM UTC-4, justin White wrote:
>
> 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=00" 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.
>
> On Sunday, July 14, 2019 at 6:08:13 AM UTC-4, justin White wrote:
>>
>> Any insight on the issue with the rbf?
>
>

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@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.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Re: DE10 Nano suggested development environment?

[justin White]

Any insight on the issue with the rbf?

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@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/d6211804-598d-4e5d-aa15-1a86eb6bfeca%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Re: DE10 Nano suggested development environment?

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

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@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/a6191b18-6ada-45a6-a506-840950d7f60c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


PIN_st_fpga_soc_dc1e_SS.vhd
Description: Binary data

Re: [Machinekit] Re: DE10 Nano suggested development environment?

[Michael Brown]

Well test it and commit you results back???

On Mon, 8 Jul 2019, 03.38 justin White  wrote:

> 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.
>
> On Sunday, July 7, 2019 at 8:36:39 PM UTC-4, justin White wrote:
>>
>>
>>
>> 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.
>>
> --
> 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+unsubscr...@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.
>

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
To view this discussion on the web 

Re: [Machinekit] Re: DE10 Nano suggested development environment?

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

On Sunday, July 7, 2019 at 8:36:39 PM UTC-4, justin White wrote:
>
>
>
> 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.
>

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@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.

Re: [Machinekit] Re: DE10 Nano suggested development environment?

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

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@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/a2e4e252-eda6-41a6-9dfe-971499328d56%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Re: DE10 Nano suggested development environment?

[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
char...@steinkuehler.net

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@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/167de833-4ebe-6809-97aa-84ccfa4077e6%40steinkuehler.net.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Re: DE10 Nano suggested development environment?

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

 

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@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/60cf75a6-65ce-4836-92a2-a663ad86b789%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


RS422.pdf
Description: Adobe PDF document

Re: [Machinekit] Re: DE10 Nano suggested development environment?

[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
char...@steinkuehler.net

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@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/c967f07a-584e-eedc-1940-4959cdb40f63%40steinkuehler.net.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Re: DE10 Nano suggested development environment?

[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 

 

On Saturday, 29 June 2019 03:11:03 UTC+2, justin White wrote:
>
> I figured that was pretty much the case, I just haven't seen the 
> enable_adc parameter used. I added the parameter and the nano_soc_adc pins 
> exposed in HAL as expected. 
>
> I suppose I didn't fully understand what to expect from the values the 
> pins expose, I see an integer that looks to be 32bits wide (U32 pin) with a 
> variation of 12bits if that makes any sense. With an input of 0v to the 
> 5v_ref there is a change of 4096 which explains the 4v max. Slightly 
> difficult to deal with with pure HAL. Passing the outputs through an offset 
> then scale component is what I would do but since it's a U32 pin it'll 
> require a U32 to float conversion first. I'm sure there's a more elegant 
> way to handle the values but unless there's a more suitable hal component 
> that's probably what I'd do.
>
> I didn't realize the value would max out at 4.095v but looking at the ADC 
> chip's datasheet it does explain that. Not a huge deal as they can handle 
> over 5v electrically. My 2nd board takes runs resistor dividers to accept 
> 0-10v on 4 of the ADC pins.
>
> On Friday, June 28, 2019 at 6:24:04 PM UTC-4, Michael Brown wrote:
>>
>> Yes that tag's fine leave it as it is. (this tag gets the adc support 
>> compiled into the .rbf)
>> Since the adc is onboard the adc pins are wired internally (not via 
>> gpio's) so there are no pin settings in that file.
>>
>> All you need to do is ensure you load/instansiate the hostmot2_ol driver 
>> with the enable_adc=1 parameter included.
>>
>> then the adc pins will show up on the hm2_5i25.0 component 
>> (ie:hm2_5i25.0.nano_soc_adc.ch.0.out etc )
>>
>> You can take a look at my python based Prusa-i3 config here:
>>
>>
>> https://github.com/the-snowwhite/Hm2-soc_FDM/blob/master/Cramps/PY/Prusa-i3_Dev/prusa-i3_dev.ini#L4
>>
>>
>> https://github.com/the-snowwhite/Hm2-soc_FDM/blob/master/Cramps/PY/Prusa-i3_Dev/cramps.py#L85
>>
>> BTW: remember that the DExx  ADC's max out at 4 Volt...
>>
>>
>>
>> On Friday, 28 June 2019 02:59:20 UTC+2, justin White wrote:
>>>
>>> What is the method for using the ADC? I wasn't very concerned about the 
>>> ADC on the first go so I didn't bother with it at all really. I'm going to 
>>> have to whip up a new .vhd and .rbf for another revision of my board and 
>>> I'm actually using it.
>>>
>>> I have the "pintype" copied over from the original .vhd I used as a 
>>> template:
>>> (NANOADCTag,x"00",  ClockLowTag,x"08",  NANOADCAddr
>>> ,   NANOADCNumRegs, x"00",  NANOADCBitMask),
>>>
>>>
>>> Couldn't find an example of how to add it to the pin description section 
>>> of the PIN.vhd (if that's necessary) or how to instantiate it in the 
>>> ini/hal file.
>>>  
>>>
>>> On Friday, June 21, 2019 at 5:51:53 PM UTC-4, justin White wrote:

 Where did you find the (no-fw-load.ini)example where that line was Not 
> commeted out ?

 Like I said in the first post, I started with that image. I couldn't 
 mount the original image to check the .ini but I do see that the Git repo 
 version is commented out. Maybe I uncommented it, not sure how I'd miss 
 uncommenting one line and not commenting the other though.but it 
 happens.

 On Friday, June 21, 2019 at 6:27:55 AM UTC-4, Michael Brown wrote:
>
> I dont know how the discussion got off-list, so here's a paste:
>
> On Thu, Jun 20, 2019 at 6:10 PM Michael Brown write:
> Ups Sorry for providing too much information, let me clarify:
> You can use either:
> the no load ini method (requires you setup u-boot variables to program 
> the fpga on boot)
> OR
> using a .dtbo file (device tree fragment that programs the fpga) you 
> specify machinekit(the hm2_soc_ol driver) to load on startup
> But never both...! (as this will give problems with the uio device)
>
> So bottom line is If you choose to have the display option on th 
> DE10_Nano hdmi port: forget the .dtbo related stuff.
> ---
> ok ?
>
>
> That's actually good to know. I don't think the framebuffer or at 
>> least the HDMI port will be necessary after I get the 

Re: [Machinekit] Re: DE10 Nano suggested development environment?

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

On Friday, June 28, 2019 at 6:24:04 PM UTC-4, Michael Brown wrote:
>
> Yes that tag's fine leave it as it is. (this tag gets the adc support 
> compiled into the .rbf)
> Since the adc is onboard the adc pins are wired internally (not via 
> gpio's) so there are no pin settings in that file.
>
> All you need to do is ensure you load/instansiate the hostmot2_ol driver 
> with the enable_adc=1 parameter included.
>
> then the adc pins will show up on the hm2_5i25.0 component 
> (ie:hm2_5i25.0.nano_soc_adc.ch.0.out etc )
>
> You can take a look at my python based Prusa-i3 config here:
>
>
> https://github.com/the-snowwhite/Hm2-soc_FDM/blob/master/Cramps/PY/Prusa-i3_Dev/prusa-i3_dev.ini#L4
>
>
> https://github.com/the-snowwhite/Hm2-soc_FDM/blob/master/Cramps/PY/Prusa-i3_Dev/cramps.py#L85
>
> BTW: remember that the DExx  ADC's max out at 4 Volt...
>
>
>
> On Friday, 28 June 2019 02:59:20 UTC+2, justin White wrote:
>>
>> What is the method for using the ADC? I wasn't very concerned about the 
>> ADC on the first go so I didn't bother with it at all really. I'm going to 
>> have to whip up a new .vhd and .rbf for another revision of my board and 
>> I'm actually using it.
>>
>> I have the "pintype" copied over from the original .vhd I used as a 
>> template:
>> (NANOADCTag,x"00",  ClockLowTag,x"08",  NANOADCAddr, 
>>   NANOADCNumRegs, x"00",  NANOADCBitMask),
>>
>>
>> Couldn't find an example of how to add it to the pin description section 
>> of the PIN.vhd (if that's necessary) or how to instantiate it in the 
>> ini/hal file.
>>  
>>
>> On Friday, June 21, 2019 at 5:51:53 PM UTC-4, justin White wrote:
>>>
>>> Where did you find the (no-fw-load.ini)example where that line was Not 
 commeted out ?
>>>
>>> Like I said in the first post, I started with that image. I couldn't 
>>> mount the original image to check the .ini but I do see that the Git repo 
>>> version is commented out. Maybe I uncommented it, not sure how I'd miss 
>>> uncommenting one line and not commenting the other though.but it 
>>> happens.
>>>
>>> On Friday, June 21, 2019 at 6:27:55 AM UTC-4, Michael Brown wrote:

 I dont know how the discussion got off-list, so here's a paste:

 On Thu, Jun 20, 2019 at 6:10 PM Michael Brown write:
 Ups Sorry for providing too much information, let me clarify:
 You can use either:
 the no load ini method (requires you setup u-boot variables to program 
 the fpga on boot)
 OR
 using a .dtbo file (device tree fragment that programs the fpga) you 
 specify machinekit(the hm2_soc_ol driver) to load on startup
 But never both...! (as this will give problems with the uio device)

 So bottom line is If you choose to have the display option on th 
 DE10_Nano hdmi port: forget the .dtbo related stuff.
 ---
 ok ?


 That's actually good to know. I don't think the framebuffer or at least 
> the HDMI port will be necessary after I get the hardware sorted out. Do 
> you 
> know if VNC require an actual framebuffer? If I can access the desktop 
> through VNC I would probably reconfigure without it when I'm done.
>
 No I don't know about vnc.
  

> Now that I look at it, the reason I messed with a .dtbo file in the 
> first place is because the .ini i modified contained the 
> "CONFIG=xxx3x24.dtbo" line and that was throwing LinuxCNC errors until I 
> renamed it. It's a bit confusing because the example FB .ini's still 
> reference a .dtbo file is compiled from a .dts file that points to a non 
> FB 
> .rbf.
> I just commented out that config line in the .ini and MK still seems 
> to load up just fine, which is probably what I should have just done in 
> the 
> beginning. Should this line be removed, or commented out from the 
> provided 
> example MK no-load .ini's? 


 Where did you 

Re: [Machinekit] Re: DE10 Nano suggested development environment?

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



On Friday, 28 June 2019 02:59:20 UTC+2, justin White wrote:
>
> What is the method for using the ADC? I wasn't very concerned about the 
> ADC on the first go so I didn't bother with it at all really. I'm going to 
> have to whip up a new .vhd and .rbf for another revision of my board and 
> I'm actually using it.
>
> I have the "pintype" copied over from the original .vhd I used as a 
> template:
> (NANOADCTag,x"00",  ClockLowTag,x"08",  NANOADCAddr, 
>   NANOADCNumRegs, x"00",  NANOADCBitMask),
>
>
> Couldn't find an example of how to add it to the pin description section 
> of the PIN.vhd (if that's necessary) or how to instantiate it in the 
> ini/hal file.
>  
>
> On Friday, June 21, 2019 at 5:51:53 PM UTC-4, justin White wrote:
>>
>> Where did you find the (no-fw-load.ini)example where that line was Not 
>>> commeted out ?
>>
>> Like I said in the first post, I started with that image. I couldn't 
>> mount the original image to check the .ini but I do see that the Git repo 
>> version is commented out. Maybe I uncommented it, not sure how I'd miss 
>> uncommenting one line and not commenting the other though.but it 
>> happens.
>>
>> On Friday, June 21, 2019 at 6:27:55 AM UTC-4, Michael Brown wrote:
>>>
>>> I dont know how the discussion got off-list, so here's a paste:
>>>
>>> On Thu, Jun 20, 2019 at 6:10 PM Michael Brown write:
>>> Ups Sorry for providing too much information, let me clarify:
>>> You can use either:
>>> the no load ini method (requires you setup u-boot variables to program 
>>> the fpga on boot)
>>> OR
>>> using a .dtbo file (device tree fragment that programs the fpga) you 
>>> specify machinekit(the hm2_soc_ol driver) to load on startup
>>> But never both...! (as this will give problems with the uio device)
>>>
>>> So bottom line is If you choose to have the display option on th 
>>> DE10_Nano hdmi port: forget the .dtbo related stuff.
>>> ---
>>> ok ?
>>>
>>>
>>> That's actually good to know. I don't think the framebuffer or at least 
 the HDMI port will be necessary after I get the hardware sorted out. Do 
 you 
 know if VNC require an actual framebuffer? If I can access the desktop 
 through VNC I would probably reconfigure without it when I'm done.

>>> No I don't know about vnc.
>>>  
>>>
 Now that I look at it, the reason I messed with a .dtbo file in the 
 first place is because the .ini i modified contained the 
 "CONFIG=xxx3x24.dtbo" line and that was throwing LinuxCNC errors until I 
 renamed it. It's a bit confusing because the example FB .ini's still 
 reference a .dtbo file is compiled from a .dts file that points to a non 
 FB 
 .rbf.
 I just commented out that config line in the .ini and MK still seems to 
 load up just fine, which is probably what I should have just done in the 
 beginning. Should this line be removed, or commented out from the provided 
 example MK no-load .ini's? 
>>>
>>>
>>> Where did you find the (no-fw-load.ini)example where that line was Not 
>>> commeted out ?
>>>
>>>
>>> On Thursday, 20 June 2019 23:37:42 UTC+2, justin White wrote:

 However can you explain to me why you think you need the .dtbo ?
>
  
 Well actually it's because you said:

  The .dtbo file is compiled from the (renamed/edited).dts file via the 
> dtc (device tree compiler) tool.

 So if you just renamed the .dtbo file it will stil configure the fpga 
> with the "old" .rbf file.


  the "no-load.ini" (Machinekit does not load firmware on startup) 
> method masks this mistake as it requires you load your firmware via 
> u-boot 
> before the linux kernel starts up (to not get a blank screen or worse if 
> mackinekit re-loads the firmware).


  So I thought you were saying that just renaming the .dts (plus 
 changing the firmware tag) and .dtbo files was not sufficient. It does 
 work 
 but I am using the "no-load.ini" right now. I have to make some changes to 
 the board and the pinouts are changing some as well so since I have to do 
 this again I may as well figure out how to do it right. Are you suggesting 
 that I don't need