Ubuntu: PNUt & Wine works fine! (only a com1 link is required)

Bill Henning · 2013-03-13 09:17

I wanted to move some Prop2 software development to my main workstation, which runs Ubuntu 12.04 64bit (the "Long Term Support" version)

PNut appeared to run fine under Wine, but it could not find the PropPlug, which was at /dev/ttyUSB0

The (easy) answer was to map /dev/ttyUSB0 to COM1 for Wine, which you can do from a terminal by executing the following line:

ln -s /dev/ttyUSB0 ~/.wine/dosdevices/com1

For a nice simple terminal program just use GtkTerm, which you can install from the Ubuntu software center. Just remember to close it before programming the P2 emulator.

Note:

Your PropPlug may show up on a different /dev/ttyUSBn

Peter Jakacki · 2013-03-13 14:25

Bill Henning wrote: »
I wanted to move some Prop2 software development to my main workstation, which runs Ubuntu 12.04 64bit (the "Long Term Support" version)

PNut appeared to run fine under Wine, but it could not find the PropPlug, which was at /dev/ttyUSB0

The (easy) answer was to map /dev/ttyUSB0 to COM1 for Wine, which you can do from a terminal by executing the following line:
ln -s /dev/ttyUSB0 ~/.wine/dosdevices/com1
For a nice simple terminal program just use GtkTerm, which you can install from the Ubuntu software center. Just remember to close it before programming the P2 emulator.

Note:

Your PropPlug may show up on a different /dev/ttyUSBn

Hi Bill, I've tried GtkTerm but I actually prefer the non-GUI minicom far better. Another trick I use with minicom to disconnect it is simply type a ^AP so that the comms parameter menu pops up and the port disconnects. After the download just hit the esc key to return back again.

BTW, you would think Wine would just setup symbolic links to the comports in the first place or at least link to ports at runtime.

jazzed · 2013-03-13 22:00

David's propeller loader has a simple terminal, can load pnut programs, and it's cross-platform.
You can even use the windows version

Bill Henning · 2013-03-14 18:14

Thanks Peter - I used to use minicom in the past, I don't know why I did not think of it now until you mentioned it!

Thanks Steve - right now I am using PNut directly, but once I use PropGCC, I will use David's nice loader - with its simple terminal.

evanh · 2016-04-16 09:11

DOH!!!! Face-palm! This works! I'd never even tried. Sigh, I just spent six months twiddling me thumbs.

Just tried with easy success using latest P123-A9 image file from http://forums.parallax.com/discussion/162298/prop2-fpga-files/p1

I even accidentally identified the embedded Prop1.

PS: Image loaded using the ported PX - http://forums.parallax.com/discussion/162989/lazarus-port-of-px/p1

ozpropdev · 2016-04-16 09:35

Great news Evan.

Have fun!

evanh · 2016-04-16 09:40

Hmm, I'm doing something wrong. I choose a spin source file and hit F11, PNut is saying "Loading Loader", Rx/Tx LEDs blink, then "Loading RAM", LEDs blink again, then that's it. PNut closes its pop-up and the FPGA doesn't seem to do anything.

Take the "all_cogs_blink.spin" program: There is no change in the red or green LED grid. Just the one RED0 LED is lit. It's like nothing has been sent. EDIT: The RED0 LED in the grid flashes once at the start of the download.

The PGM/RUN switch is in RUN position, I get a "No hardware found" message when in PGM position.

evanh · 2016-04-16 09:46

Ctrl-G response is "Propeller 2 - Parallax Propeller 1-2-3 FPGA -A9 (16/16 Cogs, 64/64 smart pin, 1024KB/1024KB Hub RAM, 80Mhz)"

mindrobots · 2016-04-16 10:58

I had similar results with later versions of wine. PX works to load the image and PNUT ctrl-g works but the actual load fails. With some older version of wine, circa P2-hot, it all worked. Now, not so much.

From my un-successful research, they (wine guys) changed the way serial ports were handled or implemented a new wine feature and broke it for some programs. I found people reporting similar problems with other programs using serial but no solutions.

The point that PX works and PNUT doesn't is frustrating and misleading.

Hope to hear from other P2 folks to see if they are having success with the latest wine and p2.

evanh · 2016-04-16 11:07

Yeah, I'm just discovering that PX.exe under wine with the comport assignment is no problem. Never needed to port it after all.

Bother, so I'm not doing anything wrong then. That sucks.

evanh · 2016-04-16 11:24

Just tried rolling Wine back to v1.6.2 - January 2014. No change in result for PNut.exe. Slight change in the progress bar for PX.exe, it flickers a little.

Don't have a quick roll back for further ...

cgracey · 2016-04-16 11:33

evanh wrote: »

Yeah, I'm just discovering that PX.exe under wine with the comport assignment is no problem. Never needed to port it after all.

Bother, so I'm not doing anything wrong then. That sucks.

Try this version of PNut.exe. You must rename PNut.txt to PNut.exe.

I was changing the baud rate without closing and reopening the port. Maybe wine didn't like that. Now I close the port and reopen it with the 2M baud rate.

This runs on my machine. If this works with wine, that will be great.

evanh · 2016-04-16 12:10

cgracey wrote: »

I was changing the baud rate without closing and reopening the port. Maybe wine didn't like that. Now I close the port and reopen it with the 2M baud rate.

RED0 LED now blinks twice instead of once. Once at the start, same as before, but also right at the end when the blue Rx led goes out.

Still not working though.

cgracey · 2016-04-16 12:33

evanh wrote: »

cgracey wrote: »

I was changing the baud rate without closing and reopening the port. Maybe wine didn't like that. Now I close the port and reopen it with the 2M baud rate.

RED0 LED now blinks twice instead of once. Once at the start, same as before, but also right at the end when the blue Rx led goes out.

Still not working though.

Thanks for testing that. I wonder what else could be the issue. If ctrl-G works okay, the rest should be able to work, too, if we could figure out where the problem is occurring.

evanh · 2016-04-16 12:59

Ah, a little more detail on the differences: I was testing with all_cogs_blink.spin just before. When using the VGA_640x480_16bpp program instead I get two bursts of Rx, code and data presumably, and the second flash of RED0 happens at the end of first burst rather than right at the end.

mindrobots · 2016-04-16 13:02

I had notes and links as to what changed in wine. If I can find them, I will post them.

It worked on p2hot so I don't think it is anything you changed in pnut. If I recall, Propeller Tool also used to work on old wine but fails on new wine. We know Propeller Tool hasn't changed. :0)

evanh · 2016-04-17 10:48

This gets hard work at times ... Compiling 32bit targeted sources on a 64bit host system is not fun! Reading up on it, the recommended way ended up being bring up a virtual machine and do a full distro install on it. Funnily, installing an old distro meant I no longer needed to do the compile because the older distro had the older Wine 1.4 binaries also.

So, I've now tested Wine 1.4 - June 2012. Still no cigar. The P123 board behaved the same it did with both versions of PNut.

evanh · 2016-06-19 04:36

Just having another poke at this ... I've wired up - NOT EASY TO DO! - the Tx/Rx UART pins (20 and 4 respectively) of the FT231X chip on the Prop123-A9 development board so that I can see full detail of the comms going between PNut and the Prop2 emulation in the Cyclone FPGA.

See attached screen shots. Orange is Tx (pin20) and Green is Rx (pin4).

This scope capture is from a [F11] run program command from within PNut_v10.exe. The program selected is the small "all_cogs_blink.spin2" program. Transferring at the PNut end looks fine. Progress bar happens and there is no errors. It seems to complete okay.

The Program never runs on the Prop2 though. As per previous posts, the single red Cog activity LED blinks out twice during transfer and that's it. Nothing further happens.

evanh · 2016-06-19 04:41

I've hand decoded - the scope can't do it - the 64 byte obj data in the last blip of that trace and get an exact match of the obj file itself, byte for byte, nothing in error, nothing missing. Bitrate is 2Mb/s. Obj data occurs 46.65ms after end of the big burst.

0c 04 e4 fc fe 05 dc f9 0f 00 00 00 01 0e 60 fd
07 f6 63 f4 07 fa 23 f4 10 0e 04 f1 12 0e 64 f0
28 0e 60 fd e4 ff 9f fd 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

evanh · 2016-06-19 05:59

The pink trace in this capture is of the RED0 Cog active LED. The two mentioned blinks are visible there. The first one presumably on the reset from the DTR line. The second one is more interesting in that it is occurring when the obj file gets downloaded.

There is also some tiny glitch like pulses that appear to be a single instruction execution time in length - maybe up to 50ns long, the scope is struggling with them. They also occur at notable times.

It looks like the Prop2 is responding to each phase of the download ... not sure what else I can glean at this stage ...

Peter Jakacki · 2016-06-19 06:15

evanh wrote: »

The pink trace in this capture is of the RED0 Cog active LED. The two mentioned blinks are visible there. The first one presumably on the reset from the DTR line. The second one is more interesting in that it is occurring when the obj file gets downloaded.

There is also some tiny glitch like pulses that appear to be a single instruction execution time in length - maybe up to 50ns long, the scope is struggling with them. They also occur at notable times.

It looks like the Prop2 is responding to each phase of the download ... not sure what else I can glean at this stage ...

I might have a need to use Wine so I might hookup my mso and see what I can see as I also want to make sure my temporary PIC serial second stage bootloader works correctly too.

evanh · 2016-06-19 06:23

Word of warning: Soldering those pins is delicate both in the precision needed and the fragile nature of the PCB bonding. Be sure to use hot glue or something to secure the wires before trying to attach a scope probe.

PS: Maybe there is proper probing tools for this, but I did a hack job.

Peter Jakacki · 2016-06-19 06:36

Yeah, I hate those parts that you can't get to. I usually pull a single strand of IDC cable, tin it, flux the pads, then just touch and go with the iron. The other end with maybe a loop can then attach to the probe. The other way is to make up a little pogo pin board to clip onto it. I use header sockets that have large enough holes to actually insert a pogo pin into rather than trying to solder them to an adapter board directly, like here.

edit: anyway, I have the BeMicroCV-A9 board with my own compatible PropPlug on pin headers so it's too easy to get to anyway.

oops - too large - did it again

evanh · 2016-06-19 07:56

Peter Jakacki wrote: »

edit: anyway, I have the BeMicroCV-A9 board with my own compatible PropPlug on pin headers so it's too easy to get to anyway.

Excellent. Will be good to verify you are getting the same behaviour.

Peter Jakacki · 2016-06-19 08:20

It looks like it's sending the correct stuff in Wine but it is reseting the line twice compared to only once when I run in VirtualBox WINXP.... I will be able to look at it better after dinner.
Actually looks like wine is opening and closing the port, that's always the trouble with using DTR lines.

evanh · 2016-06-19 08:37

I take it that isn't the same all_cogs_blink.spin2 program. I'm not seeing a comparable pattern to compare with mine.

A detail on the single vs double port open: Chip did change PNut a month or so back on that front. So, make sure you're using the latest PNut on all tests.

Peter Jakacki · 2016-06-19 08:42

Same latest pnut and just testing with my tachyon kernel. Details later when I get back to it.

evanh · 2016-06-19 09:33

I've added a wire to the DTR reset line too. New trace colour is the blue one. Yep, there is a double reset at the start and a third one before sending the obj data. RED0 blinks out each time.

It would seem the Prop is not listening when the obj data is being sent.

EDIT: Trace colours are:
Blue is DTR/reset to the Prop2/FPGA
Pink is the RED0 LED indicating Cog0 activity
Orange is Tx data from the PC
Green is Rx data to the PC

evanh · 2016-06-19 10:03

Almost 33.4ms from last stop bit of the large burst until the unexpected DTR/reset occurs.

Tor · 2016-06-19 10:11

From Linux, what's the output of

stty -a < /dev/ttyUSB0

(replace /dev/ttyUSB0 with whatever actual device is used).

">Actually looks like wine is opening and closing the port, "
Wine will do an open() and a close() on the port, although it's strange if it's doing that more than once.

evanh · 2016-06-19 10:14

Yep, using USB0

$ stty -a < /dev/ttyUSB0
speed 2000000 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = <undef>; eol = <undef>; eol2 = <undef>; swtch = <undef>;
start = <undef>; stop = <undef>; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts
ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
-isig -icanon -iexten -echo echoe echok -echonl noflsh -xcase -tostop -echoprt echoctl echoke

Ubuntu: PNUt & Wine works fine! (only a com1 link is required)

Comments