programming

[phrogg]

I've been working on an autonomous industrial testing robot. I like the isopod v2, its a nice little board.

I do have a problem though. The contract requires one piece of software to upload and download from the machine and analyse all of the data.

Is there a way to communicate with the isopod using c++?

[RMDumse]

Do you mean, can a PC be programmed in C++ to communicate in strings with the 'Pod? Certainly.

Can the 'Pod be programmed in C++? Only to the extent Code Warrior is C++ like.

The 'Pod can be programmed with Code Warrior, Small C, and IsoMax(TM). These are the only development tools we have used for the DSP chip. There may be more out there now, we heard of some packages in the past few months, but we have no first hand experience with them.

The 'Pod can generate strings, and receive strings. I'm working on an IsoMax(TM) program right now which does that very thing. I'm communicating on SCI0 for development, receiving a stream on SCI1 in, modifying it according to quadrature encoder inputs, and again retransmitting the modified string on SCI1 out.

[phrogg]

No, I'm programing the pod with isomax (although it's still a little alien), I need a c++ program on the PC.

Is there some documentation for c++. Mainly to upload and download formatted strings.

[RMDumse]

Well, I'm not much of a PC or a C++ programmer. Maybe someone else has a useful comment, Pete maybe?

[petegray]

Hello phrogg,

If I'm reading this correctly, you want a c++ program on a PC to communicate with an IsoMax program running on the IsoPod, yes?

What is the OS running on the PC? and have you decided which version of c++ you'll be using?
(I'm assuming also that you'll be transferring the data via the RS232, yes?)

-Pete.

[phrogg]

Thanks Pete,

Yes, I'm using an rs-232 connection.

I'm comfortable with Dev 4.0 but I can use Visual C++.

My contract requires interoperability with all three Windows platforms (98/me/xp).

Jesse

[petegray]

Jesse,

Basically, at a high level, you'll need to define an application-level protocol which determines the overall communication pattern between the PC and the IsoPod. For example, a simple 'handshaking' sequence of messages from one to the other... "I'm here", "Send me data element X" etc. This protocol should also define the message format and content.

At a lower level, you'll need to examine serial port communications - and this will probably be part of the compiler documentation (assuming, of course, that the compiler vendor has done a good job).

With respect to populating the messages sent between the PC and the IsoPod - I'm not sure what you're asking... something beyond the standard C/C++ null-terminated character arrays? You don't even *need* to use this - particularly if your application-specific protocol defines the message format to contain fields / data-elements with a fixed / pre-determined length.

Hope this helps,
-Pete.

[petegray]

Jesse,

as a follow-up to my previous response, MarshallSoft produce a Windows Standard Serial Communications Library for C/C++ which you can find here...

http://www.marshallsoft.com/wsc4c.htm

... it supports Microsoft, Borland, Watcom, or Lcc-Win32 Windows C/C++ compilers and can be used in the development of Win16 and Win32 applications running under Windows 3.1, Windows 95/98/Me, and Windows NT/2000/XP. The shareware version of WSC4C is fully functional.

I've used it with Open Watcom under XP (GUI and DOS-box), and it works fine.

I hope this helps.
Regards,
-Pete.

[phrogg]

Thank you, that takes care of half of what I was looking for.

The other question, does the IsoPod follow handshaking protocols or do I need something else.

Jesse

[petegray]

Jesse,

the IsoPod can communicate via the RS232 using the SCI module, and your C++ program could communicate via the RS232 using the Serial Comms Library.

At a higher level - the "application level" - you need to decide how the PC program and the microcontroller software are going to communicate. For example, you probably wouldn't want to design your application such that both programs are waiting for the other to send data. Nor would you want both programs trying to send data to each other at the same time. So, at the application level, the programmer invents a protocol which will allow back-and-forth communication in a controlled manner. A "good" design strategy is to designate one side of the communications link (i.e. the RS232) as the "master" and the other side as the "slave". Or, if you prefer distributed computing terminology, a "client" and "server". Adopting this strategy allows a neat, simple design like this...

Pseudo-code for the server:
repeat until done
wait for data request
send data

Pseudo-code for the client:
repeat until done
send request for data
receive data

...which is, in effect, a very simple application-level communication protocol.

The trick is to remember that communications work at many different levels. Bits and bytes are sent/received because low-level code tells the microcontroller or microprocessor to read/write a byte of data to/from the serial port (the programmer codes at this level using the SCI and the Serial Comms Library). At a higher level, the application programmer must decide *when* to send and receive the data, what format the data is in, and how to process it when it arrives (i.e. the code that you - as the programmer - write at a higher level to control how the application works).

-Pete.

[phrogg]

I apologize if I sound ignorant, I'm a self taught programmer (a much better Physicist) and have issues with terminology.

I understand and greatly appreciate your comments on the construction of a basic algorithm.

To clarify a portion of your last post. With the SCI and Serial Comms Library, my C++ program should communicate with the IsoPod by controlling bit by bit instead of having the Serial Comms establish the connection and communicate by sending text back and forth.

Please tell me I misunderstood.

Jesse

[rob]

I've used a simple serial protocol over the years which works quite well with serial links. A writeup on Small Frame A
synchronous Protocol (SFAP) can be grabbed from:

http://www.ee.ualberta.ca/~rchapman/Cmpe401/pdfs/sfap.pdf

I've implemented on a number of platforms in Forth and in C.

Rob

[petegray]

Jesse,

you're almost there...

Your C++ program will - typically - construct and format the data as and when you require it, and it then calls the Serial Comms Library routines to send this data byte by byte.

-Pete.

[petegray]

Jesse,

here's an example which should (hopefully) demonstrate the various things we've discussed...

Let's say that there's this scientist, conducting a particular experiment which requires him to take barometric pressure readings every 10 minutes over a 24 hour period.

He's a smart cookie, so he's searched the lab and got hold of an electronic barometer, a microcontroller, a PC, and a RS232 cable.

Checking the electrical tolerances, he's hooked-up the barometer (which has an output voltage proportional to the measured pressure) to the analog/digital converter of the microcontroller.

He's plugged one end of the RS232 cable into the PC, and the other end into the microcontroller.

Now, in order to get his readings, every 10 minutes, he needs to write a program to run on the PC which periodically asks the microcontroller for the data, waits for the response, and stores the information received.

At the same time, he needs a program on the microcontroller which waits for a request for data from the PC, reads the voltage from the barometer, and sends the data to the PC.

The program on the PC looks like this:

Repeat for 24 hours
Request data from microcontroller
Receive data from microcontroller
Store data on the PC hard drive
Wait 10 minutes

The program on the microcontroller looks like this:

Repeat forever
Wait for data request from PC
Read the pressure (i.e. voltage from the analog/digital converter)
Send the data to the PC

So, the high-level application protocol would be very simple. One 'message' sent from the PC to the microcontroller which the microcontroller recognises as a request for data, and another 'message' sent from the microcontroller to the PC which contains the requested data. These 'messages' could have a very simple format too.
The 'Request for Data' message could be a single byte, with a value 'R'. The data itself could be contained in 2 bytes (a word) containing the reading from the analog/digital converter on the microcontroller.

Assuming that the protocol above is adopted, the program is written on the PC to send a 'R' to the microcontroller and then wait for a 2-byte response. The program is written on the microcontroller to wait for a 'R' from the PC and then send a 2-byte response.

At this point, we've got our hardware ready, we have our high-level application design, and we've defined our simple communication protocol. What we haven't determined is the method used for the physical communication of the 'R' (Request for Data) message or the passing of the data itself. This is where the PCI on the microcontroller and the Serial Comms Library on the PC come in. The Serial Comms library is used by the PC to transfer bytes to/from the RS232. The PCI module is used on the microcontroller to transfer bytes to/from the RS232.

So, a 'request for data' message is sent from the PC to the microcontroller by calling one of the Serial Comms Library routines and saying send 'R'. The data is received on the PC by calling one of the Serial Comms Library routines and saying 'read 2 bytes'.

You might ask - "Why not just have the PC constantly receiving and the microcontroller constantly sending?"
For a number of reasons. Firstly, the scientist only needed a reading every 10 minutes. Secondly, if there were a constant stream of data, the PC's hard drive would fill up. Finally, the adoption of a protocol is very flexible and scalable. Should the scientist so desire, he could attach a wide range of measurement and control devices to the microcontroller. Then, by using the same protocol, he could request data from each device as-and-when he required it. For example, sending a 'R' would cause the microcontroller to read the pressure. Sending a 'T' might cause the microcontroller to measure the temperature, a 'S' to measure some distance via sonar and so on.

-Pete.

[phrogg]

Pete,
You are a scholar and a gentleman.

You have definitely earned your salary.

Jesse