Is there software available to write variables to the propeller through a GUI f

turbosupra

Has anyone written a software GUI to write variable values to either the prop or an external memory chip, that the props firmware can read?

Mike Green

Hanno's ViewPort will do that among other things. You can download it from Parallax's Propeller Downloads web page

turbosupra

Thanks Mike.

I actually own a copy of viewport, but haven't had time to experiment with using it enough I guess. I was looking for something a little more open source that I could customize. Maybe Hanno will chime in? I'd like to know how he got around the prop chip hanging when the serial to usb converter is connected? Maybe because the serialout object is not loaded?

Mike Green said...
Hanno's ViewPort will do that among other things. You can download it from Parallax's Propeller Downloads web page

Mike Green

ViewPort uses the programming port (I/O pins 30, 31, and any USB to serial converter) for its connection to the PC. You can't use it for your own program when you're using ViewPort. You probably need to go through the ViewPort documentation and experiment with it. It's really very powerful.

localroger

turbosupra, the way you state the problem is so generic that there are many ways to approach it. This pretty much describes what I do all day long, but I use many different techniques depending on what is actually going on at the PC and Propeller.

On the Propeller end you could generally devote a cog to running fullduplexserial and some Spin code to receive commands and stuff the received values into variables. Or you if you need more serial ports you could use one of the four channels of the four-port object. At the computer end you have to build the GUI in some language and execute commands to send the data; in Visual Basic you could use the mscomm1 control to do this.

Another approach is to use a terminal program like HyperTerminal as your PC-end user interface and have the Prop put up user prompts, such as press X key for Y function or enter a command:. This is a bit clunkier but eliminates the need to write code at the PC.

Or you could use an ENC28J60 ethernet chip and Harrison's TCP code to put up a little webpage and use a browser at the PC end; this is much more complicated at the Prop end but still gives you no programming at the PC and a snazzier more graphical interface than Terminal.

Or you could use something like ViewPort and just paste the suggested code into the Propeller app to let you manipulate variables from the PC, but this means you have to use the ViewPort program at the PC and it might be overkill for what you're trying to do.

The Prop chip hangs with the serial-USB converter because one of the handshake lines, generally RTS, is connected to the Prop's reset pin so it can be used to initiate a program download, and some PC applications and serial-USB drivers leave this pin in the resetted state which locks up the chip. Some Prop products have a jumper to disconnect the reset pin for this reason. If you're using a PropPlug you could make an extender that doesn't pass the RST pin through to the prop, and it will eliminate the problem.

turbosupra

Hi localroger,

I guess I'm approaching it generically at first, so that I can figure out which approach I'd like to take specifically. At least I know I've come to the right person [noparse]:)[/noparse]

Realistically I'd like to be able to write an end user GUI that can communicate to the prop and alter variables in the firmware. That seems to be easier then building hardware to do this. The part I am least familiar with is how to send the data to the prop once I have had the end user enter it into the gui.


Regarding the prop chip hanging, I have the protoboard breadboard version ... would putting a jumper in between the reset pin and the prop serve the same purpose? Something similar to what is pictured below? Or maybe an push button no [noparse][[/noparse]nc] switch in between the RST pin and the prop? Is it the RES pin in the bottom picture?

localroger said...
turbosupra, the way you state the problem is so generic that there are many ways to approach it. This pretty much describes what I do all day long, but I use many different techniques depending on what is actually going on at the PC and Propeller.

On the Propeller end you could generally devote a cog to running fullduplexserial and some Spin code to receive commands and stuff the received values into variables. Or you if you need more serial ports you could use one of the four channels of the four-port object. At the computer end you have to build the GUI in some language and execute commands to send the data; in Visual Basic you could use the mscomm1 control to do this.

Another approach is to use a terminal program like HyperTerminal as your PC-end user interface and have the Prop put up user prompts, such as press X key for Y function or enter a command:. This is a bit clunkier but eliminates the need to write code at the PC.

Or you could use an ENC28J60 ethernet chip and Harrison's TCP code to put up a little webpage and use a browser at the PC end; this is much more complicated at the Prop end but still gives you no programming at the PC and a snazzier more graphical interface than Terminal.

Or you could use something like ViewPort and just paste the suggested code into the Propeller app to let you manipulate variables from the PC, but this means you have to use the ViewPort program at the PC and it might be overkill for what you're trying to do.

The Prop chip hangs with the serial-USB converter because one of the handshake lines, generally RTS, is connected to the Prop's reset pin so it can be used to initiate a program download, and some PC applications and serial-USB drivers leave this pin in the resetted state which locks up the chip. Some Prop products have a jumper to disconnect the reset pin for this reason. If you're using a PropPlug you could make an extender that doesn't pass the RST pin through to the prop, and it will eliminate the problem.

localroger

Hi turbosupra -- yes, it's the line labelled RES on the PropPlug. What I would do if that's what you're using is make a little extender with a 4-pin header and a 4-pin header plug, and either leave out or put a toggle switch in series with the RES line. That will prevent the PC from resetting the Prop if your driver or application decides to toggle RTS. A pushbutton won't work because there's timing involved; to do a download the PC needs to reset the Prop and then send it a download command within a fairly short time interval to start the download process.

By far the easiest and most natural way to communicate between a PC and Prop is serial. The PropPlug and other USB versions generally use FTDI USB to serial converters, so to your Windows application they look and act like serial ports. This does require you to be writing the GUI in an environment that has a way to control a serial port.

A very easy way to do this is to pick a start and stop character (you can even use different start or stop characters to indicate different destination variables) and follow this pseudocode at the Prop end:

Wait for a character
If it's start -- set output value to zero
elseif it's end -- put output value in variable
else multiply output value by 10, convert ASCII byte to numeric (& $F) and add to output value

At the PC end of course whenever you want to set a value you just send the start char, numeric value, and stop char.

turbosupra

Hi localroger,

Thanks for the reply, I like the toggle switch idea, I will probably do that shortly.

I will have to read up on the controlling of a serial port, I've never done anything like that and I'm a novice programmer. I'm not even sure what serial communication architecture that the prop uses ... I didn't see that in the prop plug documentation at least.

As for the code on the prop, I guess I should use a non standard character like | or \ or / and have the PC gui send that before and after the variable updates? I guess at this point I need to figure out how to actually get the bits out using the proper protocol and to pin 31 on the prop, within the proper protocol.

Would C# be decent for this?



I found this, is there timing involved with this? Is the hysteresis on the propeller from 0.1 to 3v as well?

localroger said...
Hi turbosupra -- yes, it's the line labelled RES on the PropPlug. What I would do if that's what you're using is make a little extender with a 4-pin header and a 4-pin header plug, and either leave out or put a toggle switch in series with the RES line. That will prevent the PC from resetting the Prop if your driver or application decides to toggle RTS. A pushbutton won't work because there's timing involved; to do a download the PC needs to reset the Prop and then send it a download command within a fairly short time interval to start the download process.

By far the easiest and most natural way to communicate between a PC and Prop is serial. The PropPlug and other USB versions generally use FTDI USB to serial converters, so to your Windows application they look and act like serial ports. This does require you to be writing the GUI in an environment that has a way to control a serial port.

A very easy way to do this is to pick a start and stop character (you can even use different start or stop characters to indicate different destination variables) and follow this pseudocode at the Prop end:

Wait for a character
If it's start -- set output value to zero
elseif it's end -- put output value in variable
else multiply output value by 10, convert ASCII byte to numeric (& $F) and add to output value

At the PC end of course whenever you want to set a value you just send the start char, numeric value, and stop char.

Kevin Wood

C# would be fine, as would pretty much any .Net language. You can even use scripting languages such as Perl, Python, Tcl, Powershell, etc.

Also, Delphi seems to be popular here, although it is expensive. You can, however, use Lazarus, which is basically an open source clone. It has the benefit of creating small native executables that don't rely on having the .Net framework installed. I believe that Brad's Spin Tool is created with Lazarus, and it weighs in at 906Kb.

Lastly, you can find all kinds of sample apps here, especially in the Basic Stamp forum.

localroger

You don't need to worry about the details of serial timing; at the Prop end just use the fullduplexserial object which does the heavy lifting for you, and at the PC end your development environment should have a tool for serial comms. At each end you basically have functions to send and receive characters or strings; you just need to match the settings (the "9600,n,8,1" stuff) so the two ends agree on the timing. Both the PC and fullduplexserial will buffer incoming characters so you don't have to process them the split second they arrive.

prof_braino

turbosupra wrote: »

I was looking for something a little more open source that I could customize.

If you want to interactively customize to view and alter variables, and set and monitor i/o pins interactively, using just a prop and a terminal program on your PC, you might consider propforth. Forth is all about that and Propforth is free.

turbosupra

Hi, thank you.


I'm going to read about this as much as possible, it may be over my head though. I've never seen forth before today so interpretation will take some learning.

Does it have a GUI, if so do you have screen captures of it? Or does it only use the serial terminal?

prof_braino wrote: »

If you want to interactively customize to view and alter variables, and set and monitor i/o pins interactively, using just a prop and a terminal program on your PC, you might consider propforth. Forth is all about that and Propforth is free.

prof_braino

turbosupra wrote: »

it may be over my head...GUI,...terminal?

to a guy with a hammer, everything looks like a nail; I'm a forth guy, to me forth is easier than spin and more powerful than basic.

The simple kernel is command line only, use tera term. The vga version does not need a pc, only a monitor, but than has not been released yet. PC side GUI etc can be written in forth (pygmy forth is my fav) or any other means; usually they are not needed (in the developer's opinion) I am working on a private package of PC-side support but this is not yet released.

The only thing that might be a challenge is thinking in terms of the stack which takes 5 seconds to understand and twenty minutes to master.

"Starting forth" and "Thinking forth" are available free on line.

The propforth thread and the google code site are active for support.

Hanno

First post on the new forum

It's pretty straightforward from any language to slowly send/receive serial data. FullDuplex or other objects let you decode that data so you can do something with it.

For non-trivial projects, Conduit simplifies this by letting you "share" Propeller variables with the PC at high speed. There is a development kit and an api for ViewPort that let you build on top of this. (Samples in python, vb, c#, matlab and more...)

12Blocks also uses the "Conduit". With 12Blocks you create a Propeller program from "code blocks". Then, you can use "interface blocks" (there's a separate development kit for that) to create a user interface. For example, create a program to measure something into a variable, then drag the "thermometer" to display the variable. You can "run" this inside 12Blocks and "debug" it. Finally, you can "save as exe"- this will package up your "firmware", your "user interface", and the runtime parts of 12blocks that program the propeller, establish and maintain the connection, and keep the interface updated.

The all-in-one "exe" file is typically 1MB.
Hanno

T Chap

If you want to create your own custom GUI from scratch I suggest looking at RealBasic, it allows you to build multi platform apps rather using basic type language that is not hard to learn. There are examples programs that will have you talking to the prop in minutes, you can extract what you want from those serial tutorial files and create your own look and feel to suit your needs. Add specific buttons with their own names and functions, add your logo or other graphics, it is a very flexible and powerful system. In most cases you can export to any platform, although keep in mind that a single platform is $100, adding another platform is another $100, but you can use the demo for free for a while, and export time limited versions of the other platforms just to test it out. There is a great forum for the software and you get fast response. I believe it would be one of the simplest fastest ways to get up and running for Prop communication as far as a custom GUI that you can have 100% control over the functions and look.

Rayman

I not 100% sure, but I think I've read that there's a free "robotics" student version of LabView that can communicate with the Prop over a serial link.

Also, I think there's a Microsoft Robotics SDK that has Parallax drivers...