Fun with Phasors!

[zygot]

No, not those kinds of phasers... I'm talking about the much more fun mathematical concept of phasors!

But if you have an Eclypse-Z7, and want to tag along, then you might get a little stunned anyway, so try it out for yourself.

 

 

EclypseZ7_PhasorToy_release_R042.zip

[zygot]

Apologies for the typos ( I've found a few since posting ). The picture labeled as FSK is clearly some form of PSK. Stupid fingers have minds of their own.

It would be nice if someone from Digilent tried out the demo as I'd like to know if what I've provided can be duplicated on another PC.

[zygot]

Oops... The run.tcl script is missing the last line which is the con command. I've been doing that when testing it and forgot to include it.

No worries, after running the run.tcl script nothing will happen until you type con into the command line. That should get your interaction with PhasorToy started.

I haven't figured out why I always find the mistakes after posting a project... even though I proof read everything a few times.

I was intending to add fan control to the project but this has turned out to be more complicated than it should be. Par for the course, i guess.

[zygot]

I woke up in the middle of the night realizing that I never mentioned which port on the Eclypse-Z7 the demo supported the ZmodDAC1411; it's the ZMODB port. The A port is reserved for a later version using the ZmodADC1410. I choose to take this as a positive sign that at least a few neurons deep within my brain are busy doing some useful work.

Once I get that fan spinning I'll post an update fixing a number of typos and omissions. Currently I'm finishing a XEM7320 version of the demo.

[zygot]

I just posted an update to fix an assortment of typos.

[Wyllyam]

@zygot,

Got a chance to try this out! I was using Vivado 2019.1 on Ubuntu 18.04.4.

First, everything with your demo seems to duplicate and work just fine.

• I was able to get the demo started by running "run.tcl" through XSCT. It successfully downloaded PhasorToy.elf, and I got the 1.945MHz signals on CH 1 and CH 2, as expected.

• I ran PhasorToy.m and watched GNU Octave successfully interpret the different waveforms. And I have the following commands in OCTAVE_CMDS.txt:

  • T 2 21474836 ;

  • C 4 42950 42950 8 8 512 2147483647 42950 85899 128849 171799 214748 257698 300648 343597  ;

  • C 6 8589935 8589935 2000 4 2000 2147483647 17179869 8589935 17179869 8589935  ;

  • C 8 4294967 4294967 4000 7 4000 2147483647 2151778615 4294967 2151778615 4294967 4294967 2151778615 4294967  ;

  • C 10 4294967 4294967 4000 8 4000 1518500249 4294967 1078036791 2151778615 3225520439 4294967 2151778615 2151778615 4294967  ;

  • C 12 1048573 16777216 1 0 0 2147483647  ;

So it seems like everything with PhasorToy is working properly, but I was having some issues with PuTTY so couldn't send the new commands for the different waveforms to fully confirm.

The issue is I can't figure out exactly which port the Eclypse is enumerated on.

I run this command to see what's what:

dmesg | grep usb

The output I get from dmesg is massive, but I found the chunk specific to the Eclypse.

That's the serial number of my Eclypse board, so I know it's recognizing it. (That answers one of the questions in your README by the way; 210393AD7754A is unique to just your Eclypse.) It's strange that it says it's attached to both ttyUSB0 and ttyUSB1. So anyway, I tried both.

ttyUSB0 fails to open a connection:

ttyUSB1 opens a connection but never displays any messages, nor can I send the other waveform commands:

I'm probably messing up something simple and stupid. Any thoughts?

In any case, I will try this again (hopefully some time this week) on my Win10 machine, which has Vivado 2019.2. I don't usually run into such PuTTY issues on Windows, so I should be able to get through the whole thing. Then I can give you another data point of using it on Win10, and if XSCT does anything differently in 2019.2.

Overall, cool project! Looking forward to getting through the whole thing on my other PC!

[zygot]

@Wyllyam,

Hey, I can't tell you how much it means to me that you were able to run the demo. Usually I have multiple PCs to test project submissions on but it takes about a week of trying to install Vivado without broadband and my other development PCs aren't keeping up.

In Linux I usually do dmesg | grep TTY and use lsusb -v to see USB devices. Between them I can usually figure out what serial port to specify. The Prog port on the Eclypse-Z7 functions as both a UART and a JTAG port and both are enumerated. Did you try both enumerated tty devices? [edit] Yeah, I see now that you did. When in doubt I just unplug the target, run dmesg and lsusb; then plug it the target cable and run them again noting what's new. In Windows the Device Manager generally helps figure out what COM port to use, though occasionally I have to do the cable thing too.

The documentation is somewhat terse but I figure that I'm better off answering specific questions than trying to cover everything in the documentation. Of course I'll note issues for later releases if there's any interest.

[edit] You should be able to connect Putty to the Eclypse-Z7 before running the run.tcl script and see any messages once the PS has started execution the application.

Thanks a bunch for the feedback.

[zygot]

@Wyllyam,

Well, I did just confirm that the 2016.2 version of Vivado XSCT can't run the provide script.

I didn't have any problems connecting Putty to the Eclypse-Z7 PROG port though. I was using /dev/ttyS0.. at least there were no error messages. I'm using Centos 6 for this. In my setup dmesg | grep tty says that /dev/ttyS0 is a 16550A device. I don't get any messages because I can't run the XSCT commands without an error.

Later, I'll try again on the Ubuntu installation on my dual-boot WIN10 box.

[zygot]

@Wyllyam,

I booted into Ununtu 19.10 on my WIN10 box and downloaded the project archive from the project. I was able to connect to the Eclypse-Z7 at 921600 baud in Putty. It took two tries but I was able to open the SDK xsct application and run the run.tcl batch command file. Got the opening message in Putty after configuration and loading and executing the .elf.

Are you sure that when you opened Putty you selected the serial connection? Can't think of anything else that could be wrong.

What I was unable to do is copy and paste text into Putty. I guess that Putty works differently in Linux than it does in Windows. If Linux users need it I can create a Python script to replace Putty. Everything should work fine on Windows 10.

[Wyllyam]

@zygot,

Ahhh, I made a simple mistake.

/dev/ttyUSB1 was correct and the serial session was setup correctly. However, I opened the PuTTY session AFTER starting the default tone demo, so I never caught the initial "Running Default Tone Demo" message. Then, like you said, I couldn't copy and paste text into PuTTY to send commands for the others tones, so I assumed there was something wrong with the PuTTY session in general, when it's just a quirk about how it operates in Linux.

Got it now! (Other than not being able to paste the commands into PuTTY.)

 

 

Tested it on Windows 10 as well with Vivado 2018.2. (I also have a Windows 10 + Vivado 2019.2 setup, but didn't install Vitis so don't have XSCT on that one.)

It worked great! And I didn't have the Linux PuTTY issues, so was able to provide additional commands and see the other waveforms on my scope.

So it all works great! To summarize, I successfully ran it on Ubuntu 18.04.4 with Vivado 2019.1 and Windows 10 with Vivado 2018.2. The only issues I ran into were PuTTY-related when on Linux, so it'd be great if you replaced that with a Python script or something, like you suggested.

 

EDIT: Forgot something

I ran into a "CRITICAL WARNING" when initially running the run.tcl script through XSCT.

This didn't seem to affect the operation of the demo because it looks like it still identifies the right target, but it claims it's missing a "board_part definition".

[zygot]

@Wyllyam,

Again, many thanks for posting your experiences.

I also get that board_part definition warning. I'm assuming that for some reason the SDK can't access the board part that I've installed into Vivado. Until someone convinces me differently it's a non-issue and just a nuisance message. Since I exported the HW from Vivado and the SDK created all of the PS related sources it seems like an odd thing to complain about, particularly as a 'Critical Warning'.

Because I used xil_printf to send messages to the PS UART you need to set Putty to imply a CR for every LF and visa versa. This will clean up your Putty display.

I've been using Python 2.7, which has been officially depreciated.... so perhaps it's about time that I get used to Python 3. Not, a project that I'm particularly interested in but, since I do like using Python for its cross-platform utility I suppose that I have to stop procrastinating...

One thing for sure is that reading text from files in Python is a lot easier than doing the same thing in C++ using std::string. I'm not a big fan of C++ but I do like streams. Strings in C++ are a disaster.

[zygot]

To all, I've updated the archive with a new version of the OCTAVE script that allows Linux users to change modes and waveforms, all from one place. Windows users now have a choice of using OCTAVE or Putty to use the demo. Unfortunately, Putty on Linux doesn't support pasting text or sending files.