Page 1 of 1

Communicating with a PC

Posted: Thu Aug 07, 2008 5:19 pm
by Benj

When working with an embedded system it is often useful to connect the system up to a computer to allow for external monitoring of the system or to integrate an aspect of the embedded functionality into the PC itself. One of the simplest methods for achieving this is to use the hardware serial bus or UART that is built into most common microcontroller devices.

The Flowcode RS232 component provides users with this connectivity functionality.

Step 1: Configure the Flowcode RS232 component properties

The RS232 component properties can be found by clicking on the small menu at the top of the RS232 component and selecting properties from the list. There are several options: BAUD rate stands for bits per second so the actual byte throughput will always be 10 times lower then the baud rate. Hardware flow control will stop data from flowing out until the remote terminal has signalled that it is ready to receive. Echo mode will instantly retransmit any incoming data.


Step 2 Bridging the connections

To connect the embedded system to the computer there will need to be some kind of hardware bridge for the data to flow along. If your computer has a serial port on its motherboard (9-way D-type) then you will be able to use our EB015 RS232 E-block to connect to the PC via a straight through serial cable. Otherwise you will be able to use one of our many USB related products to connect to the PC via a USB cable.

Step 3 Configure the Computer

The computer side of things also needs to be configured. For demonstration purposes we will be using Hyperterminal, which is supplied as standard with most versions of Windows. Windows Vista does not include Hyperterminal as standard so you will have to download it seperatley.

To open Hyperterminal simply click on Start and Run, type in hypertrm and press OK. Create a new connection that uses the COM port that is assigned to your serial port or USB232 board. The COM port number can be found by looking under the Ports section of Windows device manager. Configure the PC so that it uses a BAUD rate to match that of the embedded system. Set the data bits to 8, the parity to none, the stop bits to 1 and the flow control should be set to none or hardware depending on your Flowcode settings.


Step 4 Programming Flowcode

Data can be sent to from the microcontroller to the PC by using the SendRS232 hardware macro and similarly data can be received by using the ReceiveRS232 hardware macro. The SendRS232 macro allows you to send bytes or strings to the computer. Each byte received by the computer will be interpreted as ASCII data so sending a byte value of 48 represents ASCII character “0”. The ReceiveRS232 macro will wait for a specific amount of time for an incoming byte. If a byte is received then the macro will return immediately with the byte data that has been received. However if a byte is not received then the macro will wait for the timeout (milliseconds) to end before returning. If the timeout is reached without an incoming byte then the macro will return the value 255. Therefore if the data returned from the recieveRS232 macro is less then 255 then an incoming byte has been received. A timeout of 255 makes the receive macro wait forever for an incoming byte, however this value of timeout is not recommended for a reliable system as it is essentially a blocking function.

Taking this further

You can take this further by adding interrupts to jump to specific macros when a byte has been detected on the incoming hardware buffer. For more details of this refer to the adding interrupts to FCD files application note available from here. ... =26&t=4797

Sending numbers as ASCII
To send numbers or variables as ASCII simply use the String function "ToString" located in the string manipulation icon to convert the numeric data to a string of ASCII characters.

Re: Communicating with a PC

Posted: Fri Oct 17, 2008 7:12 am
by goldwingers
Hi benj.
I have just read your article on communicating with a PC.. You mention using the tostring() function but it does not appear in the FCD file that is attached.

Could you send a new FCD file with an example of how to take an integer number and transmit it

Many thanks


Re: Communicating with a PC

Posted: Fri Oct 17, 2008 9:33 am
by Benj
Hello Ian

Here is an example of using the tostring() function.

Re: Communicating with a PC

Posted: Fri Oct 17, 2008 5:27 pm
by goldwingers
Hi Benj

Yea thats fine but yuo mention sending it via rs232?.....Mmmm the rs232 component does not allow strings?????? what is one to do on a Friday night.


Re: Communicating with a PC

Posted: Mon Oct 20, 2008 9:57 am
by Benj
Hello Ian

Sorry I thought string variables could be sent via the RS232 send macro but strings can only currently be sent if they are constant values.

Another way but not quite as neat would be to have a loop that incremented an index variable and then sent a byte of the string to the rs232.


String Manip: string = "some value"
Calc: index = 0
Calc: string_length = 10
Loop: index < string_length
Comp Macro: Rs232: SendChar: string[index]
Calc: index = index + 1

Re: Communicating with a PC

Posted: Fri Mar 01, 2013 2:29 am
by dan@ttl
Hi Ben,
I'm stomp on making my rs232 test programs to work on hardware. I don't have the EB039 and I got a usb to serial cable. Wired in a max232 circuit between cable and pic, but I can't get it to work.

Re: Communicating with a PC

Posted: Fri Mar 01, 2013 10:51 am
by Benj
Hi Dan,

Can you attach your Flowcode program and I will have a quick look.

Re: Communicating with a PC

Posted: Sat Mar 02, 2013 1:44 am
by dan@ttl
Hi Ben,
I've used the test programs from the site and change the xtal to 20MHz. When I connect the hardware, I received garbage on the port and am not displaying anything on the lcd when sending. Did I fry my pic?

Re: Communicating with a PC

Posted: Sat Mar 09, 2013 3:59 am
by dan@ttl
Hi Ben,
I continued working on the problem and was able to do the test using the hex file provided for the EB039. It works with my Prolific usb to rs232 cable connected to a max232 level converter. I have to use a specific terminal program though. If I try to use Hyperterminal, I can send, but the feedback to pc is garbled. If I use Terminal by Bray or MikroC terminal, or Jal's mini terminal, I can get all characters right, and only if I use xon/xoff control. The pic is wired with RTS and CTS connection. Hope you can shed some light on these. Thanks.

Re: Communicating with a PC

Posted: Sat Mar 09, 2013 11:34 am
by medelec35
Hi Dan,
Your flowchart did not have any configuration settings set.
For configuration settings you could take a look here: ... =26&t=6936

I have altered configuration settings for you,
I have also modified your flowchart so receive side is via RX interrupt.
This means you can expand on your program without missing RX transmission from PC.
I have testing on my hardware without Flow control and it works a treat with hyperterminal.
If you have got extra flow control connections then you will need to enable it again.

Since your using Flowcode V5 professional, So you can get help quicker can you please sign up for V5 section by following this link: ... =46&t=9958


Re: Communicating with a PC

Posted: Tue Mar 12, 2013 9:33 pm
by dan@ttl
Hi Martin,
You always come to my rescue. Appreciate it man.
It always happens when I change chips, I forget to check the config. I got it working now. Thank you. I'm still not clear on the flow control setting. As I mentioned in previous post, I'm using a Prolific usb-serial cable. When I tested the setup with the EB039 test hex, I could only make it work with the terminal set to xon/xoff. I don't know how the test file is done as there's no fcf file in the test package. Thanks again.

Re: Communicating with a PC

Posted: Tue Mar 12, 2013 11:44 pm
by medelec35
Your welcome.
Glad its working now, that's the main thing.

Just guessing, I did't think the test program used any handshaking, but of course I could be wrong.
I know the program I posted word as it should for me, with no flow control.
Also the rs232 echo flowcharts found here:
do not have any flow control.
The test file could be derived from these?


Re: Communicating with a PC

Posted: Sun Mar 31, 2013 11:18 pm
by attia
i have a problem with connection to pc using rs232
it simulate well in flowcode simulation but with proteus and 2010 ican recieve data but i cannot send any type of data
i used several program to send data but no thing happend??????????????
sending data from pc is the problem
what is the problem plz help me
this is my flowcode prog.

Re: Communicating with a PC

Posted: Mon Apr 01, 2013 5:42 pm
by attia
can you giving us any true exmple for sending data via pc to pic using flowcode and

How exactly use/simulate RS232 component??

Posted: Mon Dec 23, 2013 5:09 am
by victor336v
Someone, what am I missing please?

I try simple test from RS232 tutorial - sent and receive byte, using RS232 component.
Now, I load the flow chart, it appears along with this component. I press Simulate"
button, and nothing happens. No prompts, no instruction, no clue how to proceed.
(I'm suing FlowCode 3 but it's generic question that would apply to any version).

Empty "Variables" and "Call stack" windows appear. What am I suppose to do here?

Example - RS232_string_input chart. In the window titled RS232(0) there are 3 black fields:
characters sent, characters received, character4s in queue.

Placing a cursor in any if these and trying to type in a PC keyboard yields nothing.
I have no clue if a PC keyboard should even be used to simulate this chart.

How exactly does one "delivers" a character to the flowchart being simulated a character to be sent?

If I load a hex file supplied with EB015 block, it works beautifully - I type a character on a PC keyboard
(in Windows HT) and it appears on the LCD. I want to see a flow chart of this test program, that's exactly
what I'm trying to do - just press a key on a PC keyboard and it appears on the LCD screen.

Anyone got a flow chart to do this?
Can Matrix supply a flowchart they used to generate the RS232.hex test file for EB015 block?

What I ultimately need to do is to build a simple gadget converting a character sent from PC to
a pre-defined SPI command that will be sent to some other gadget to test it. SO for now I just want
to be able to receive a character from PC and display it. Can't even do (simulate) this demos...

Any help? A video tutorial (not just for me) how to use/simulate RS232 component would be great as well !

Re: Communicating with a PC

Posted: Thu Dec 26, 2013 1:38 pm
by medelec35
Hi victor336v,
You should find a Flowcode V3 to do just what you described here:
If you download:
EB039 - USB232 Board - Example Files Flowcode v3
The the flowchart your after is called rs232.fcf

If you get stuck, just let me know


Re: Communicating with a PC

Posted: Sat Dec 28, 2013 1:27 pm
by medelec35
Hi victor336v,
Did the link help you?
Would you mind letting us know either way please?

Re: Communicating with a PC

Posted: Thu Jan 02, 2014 7:08 am
by victor336v
Hi Martin,

Yes, and No,

Yes, your link pointed me to the flow chart I already have downloaded before but after looking google'ing and
watching YouTube for some related projects I figured out what's going on. May be my experience will be valuable
to other newbies [to the Flowcode, not to uProcessors in general).

If you load the flowchart, the TS232 component is hidden by default - you have to View->Attached Components->RS232(0)
first. It may sound silly, but THIS IS NOT OBVIOUS TO A FIRST TIME USER AT ALL. Why hide a critical component? That's
just beyond me.

Another question I had when I did try to create a flow chart on my own with RS232 component visible. It ended up
looking different that the example you cited, but the simple lack of instructions made me waste few days. To elaborate:

As with bunch of other examples (LED flashers, :Hello World" on LCD etc), you see the result of the code working as soon
as you press "Simulate" button. Naturally one expects similar behavior of the RS232 chart. Well, as I explained, I press
the "Simulate" button, and nothing happened except appearance of "Variables" and "Call Stack" windows popped up.

So how the hell do I send a character? Since in RS232 window there are 3 areas and the top says "Characters Sent",
I assumed they're sent already (gone), but how do they get there to be "gone" in a first place?

First of all, in this window is it "Characters sent" by your hardware toward the PC (and will appear on windows HT)
or sent by PC and will appear on the LCD? This is NOT obvious, and no word to explain. Same applies to "Characters
Received": by the controller or by PC?

It didn't take very long to figure out which way data flows, but one doesn't have to scramble - it should say somewhere.

But the main time waster for me was to figure out how to put a character in queue - evidently this character gets picked
up by the software and being sent to the PC. OBVIOUS (to me) way was to click on the black window labeled "Characters
in queue" and type characters on a PC keyboard to place in queue. After clicking a cursor blinks on the black background
as if inviting to type something, but typing doesn't place characters into this window - this drove me nuts for 2 days trying
asking and searching. OF course the correct way ended up to be click on a "+" sign above the trash can and type in the
character(s) one wants to place in queue. BUT, to tell you the truth, I didn't notice the "+" sign as NOWHERE IN ANY
HELP FILES OR INSTRUCTIONS it says this is how a character is placed in queue. Thus was my question on this forum.

And the answer I was expecting should have been "Click on a "+" sign, then you will see simulation working and a character
appeared in a hyper-terminal window". That's all.

No one told me that. Again, nowhere there I could find there is mention what the "+" sign above the trash can is for.

In this sense, no your answer did not help me, if I wouldn't figure this all out, I'd be still get stuck staring at the screen after
clicking "Simulate" button and not knowing how a character is being sent.

Suggestion to Matrix' software developers: in this instance the way it should work if some places a cursor in a black
"Characters in queue" window and types, an error message pops up saying "click the "Plus sign to place a character in queue"
instead of allowing a cursor to blink as if one can type right there. That's just being "user friendly" otherwise developers
just assume too much.

Anyway, now it is working and I'm glad I can do something useful. HOWEVER, my next stumbling block is again not
obvious to me and no mention about it anywhere. May be you or someone would be kind enough to fill the void:

I'm trying to make a simple jig which converts a character sent by a PC to an SPI command to be sent to another project
I want to test. That project has standard SPI interface. Not FRAM, not DAC. So when it sends a few bytes over SPI in response
to my SPI Commands, I just want to display received raw data on the hyperterminal window. I may assign meaningful labels
to received bytes to describe their meaning, but at least I should get raw data. So it's basically a two way RS232<->SPI translator.
Press a key (on PC) - a predefined hard coded SPI command (a byte or few bytes) gets out. A byte is received on SPI interface,
it gets sent over RS232 to the PC screen. That's it.

For this to work, I inserted an SPI component into working RS232 comm flowchart and inserted one component macro to
initialize SPI interface. Everything compiles and loads in the chip just fine, but RS232 no longer works just because
SPI is initialized. I'm trying this with PIC18F2680 (and getting the same result is with 4680).

Obvious suspicion is that HW interfaces on the port C cannot work as UART and SPI simultaneously, I read some blurbs about
pins being shared, so one interface at the time, but not both. However, this is my guess, and as before NOWHERE I can find
info that this is doable. Moreover, I found a project on the forum that has both SPI and RS232 components at the same time,
also if I do that it simulates beautifully, I can redirect a character from RS232 interface to the SPI and it works as simulation
(I also display it on simulated LCD screen to prove). But - not in real hardware. One would think that if there is no way SPI and
UART can be initialized and actually work OK independently, the simulation should also fail, but it doesn't as if everything is good.

If one looks at SPI component properties it allows selection of NVM enable pin and also DAC enable pin. IT's just labeled
Pin 0, Pin 1 etc. on the drop down list. It is not clear to me which pin are they talking about - is it a pin of the target processor
(like RC0 or RC1)? If so, one can guess that if these pins are chosen such that they don't overlap RC6 and RC7 taken by UART,
The SPI should work just fine, but it doesn't. Basically, is it possible to re-map CLK, SDI, SDO and CS I/Os of the
target (PIC18F2680 or 4680) chip to the physical pins other than RC6 and RC7, so they don't overlap and so work simultaneously?

NO ANSWER TO THAT I could find so far despite examples of both RS232 and SPI components used simultaneously in flow charts.
Can you enlighten me? If this is not possible, I've heard about "software SPI" which I suppose is bit banging some I/Os to match
SPI protocol and timing. This is next best thing, but can I pass a character or a byte to this "software SPI" to get sent out
just like I would to the port implemented on silicon? And vice versa - if the prototype I'm testing sends something over SPI,
how do I capture it and redirect to the PC screen? As I understand the data does not appear in the internal SPI buffer as it
would in case of using true HW SPI of the chip.

May be there is another way to make a RS232-SPI translator like this, so I'm all ears for ideas.

This post is way long, so since you've read this far, thanks for the patience! Basically ability for a non-programmer
like me to come up with seemingly simple jig defines usefulness of the Flowcode as a product for someone like me
it is meant for. But I should admit, so far it was NOT user friendly to me. A Flowcode is just like Linux: it is friendly,
but it's very picky about its friends.

Anyway, any thoughts, comments or ideas (incl. flow charts readable by v3) are greatly appreciated!

Portland, USA

Re: Communicating with a PC

Posted: Thu Jan 02, 2014 10:44 am
by kersing

Flowcode currently is at version 6. Many improvements have been made to it since version 3, so some of the issues you are experiencing with regards to the user interface not being clear may have been addressed. (Also, keep in mind support for version 3 ended some time ago)

Glancing at the data sheet of the device you are using (that is the source to check for any conflicting pins or other issues regarding limits of the device) I don't see any reason you should not be able to use both the hardware SPI and UART at the same time.

Regarding your SPI issue, if you select any unused pin for DAC and NVM you should be fine. To access the device just use any I/O pin, set it to the appropriate level for the chip select (don't forget to initialize it to the opposite level at the start of your program) and issue a read/write command as required. Reset the chip select once you are done.
Software/hardware SPI should be transparent, both send/receive 8 bit values. Also SPI requires to issue read/write commands from the controller. The device will not send any data to the controller unsolicited. For your converter you need to know what information the device will send given the provided input as (most) SPI devices will not provide data to a random read command. (SPI is not like serial communication where you just wait for data to become available)
I hope this makes sense to you, if not feel free to ask.

Good luck with your project!

Re: Communicating with a PC

Posted: Fri Jan 03, 2014 6:24 am
by victor336v
Hi kersing

Thanks for reply, Yes I know the support for v3 is phasing out and considering upgrading, but
now my issue is not about flowcode features - it's about how chip works as the same flow chart
created in any version and any version will download into the chip the same hex file.

You wrote:
"Regarding your SPI issue, if you select any unused pin for DAC and NVM you should be fine".

Unused pin of what, of my target 18F2680 chip? I did try to choose pin 1 and pin 2 instead of default
pin 6 and pin 7, but I don't really understand what I'm doing. Are Pin 1 and 2 the same as RC1 and RC2
(e.g. physical pins 12 and 13) of the chip?

I don't get it: SPI uses 4 pins for communication: CLK, SDI, SDO and CS. But in the properties
of SPI component there are only two pins selectable - something called NVM enable and DAC enable.
So how in the world do I assign four physical pins of my chip unused for RS232 communication to the SPI?
As I understand it, the RS232 pins used by RS232 component are RC7 and RC6 of the chip - something
I cannot change. The chip's SPI pins are RC3=CLK, RC4=SDI, RC5=SDO and RA5=SC - something
I also cannot change since it is HW implemented on the silicon (again what these I/Os have to do with
two pin selections in SPI component property window?

Anyway, these chip I/Os do not overlap RC6 and RC7 used for RS232, so it appears like both port
types should work simultaneously and independently. Well, it does when I simulate the chart after
adding SPI component and only one macro to initialize it, but the RS232 stops working in actual
hardware when I compile to the chip. Again, the difference is - I only placed SPI component in flowcode
and inserted only one macro to initialize it.

Attached is my flow chart (before introducing SPI component) which works as RS232 both ways.
Can you tell me why introducing SPI and just initializing it (anywhere on the flow chart) breaks RS232
communication? Effect is the same for 18F2680 and 18F4680.

If someone can fix my flow chart so I can learn from it, I'd greatly appreciate it!

About SPI in general: an SPI can work only one way (only transmit data) can it?
Like in case of DAC - you don't need anything from DAC, you only supply data to it.
Or acknowledgement from the slave is a requirement even though useful data flow one way ?

If you curious, my project will ultimately need to talk to is the LTC3300 (write only) and later -
to the LTC6804 (read/write). Both are specialized chips, have SPI port, but neither one is anything
close to an FRAM or a DAC.

Thank you all for any useful advise,
You can see these questions really got little to do with v3 vs v6.


Re: Communicating with a PC

Posted: Fri Jan 03, 2014 10:23 am
by Benj
Hi Victor,

With the SPI component it provides two chip select pins to help drive the bits on our SPI E-block. If your not using the specific SPI functions associated with these then you shouldn't have to worry at all about these connections. Set these pins to unused I/O if you can. You will however have to use an output icon to control the CS pin to your external device whenever you talk to the device. Before you initialise the SPI component please can you set the CS pin (RA5) high and see if this helps at all. I can't think why initializing the SPI would cause the UART to fail but then we've come a long way since v3 so there could potentially be an issue lingering down in the code.
About SPI in general: an SPI can work only one way (only transmit data) can it?
A single SPI transaction is normally bi-directional but usually only one of the values has any meaning. Therefore there are read and write functions to either send out a byte or read in a byte.
Like in case of DAC - you don't need anything from DAC, you only supply data to it.
Yes a DAC is generally an output only and you would probably only have to send single byte or multiple byte packets to the DAC.
Or acknowledgement from the slave is a requirement even though useful data flow one way ?
This isn't usually required with SPI. Some device may echo back the last send command just as a sanity check.

Simulate MAX 232 in proteus

Posted: Sun Sep 21, 2014 12:57 am
by Genilsonsa
Good night I made a simple program to send a string "A" with RS 232 but simulate the Flowcode works just right, but when I try to simulate in PROTEUS VIRTUAL TERMINAL and the 232 MAX STRING certain he never gives 'A'. Attachment is the Thank programa.Muito


Posted: Sun Sep 21, 2014 1:06 am
by Genilsonsa
Leveraging the circuit also send Proteus

Re: Communicating with a PC

Posted: Sun Sep 28, 2014 11:36 pm
by Genilsonsa
Hello solved my problema.Estava sending different characters because I was not sending the value in HEX.Muito Thanks to all