Send data to PC (C#) via DB9 Serial?

I've been searching through the large amounts of threads in here, but haven't quite found what I'm looking for.

My project is fairly simple - a large array of temperature sensors muxed into our HCS12's (Axiom CML12SDP256) ATD ports, whose values are then sent to our PC for graphical/numerical display.

The code on both ends is complete, its the code that drives the middle that I can't quite understand.

In class, about a year ago, we learned some basic serial communications using SCI0, via Port S, if i recall correctly. I built a 2-way communication system using the built-in MON12. But it doesn't seem applicable here, unless its way simpler than I'm thinking. I'd like (and i would think need) to use the main serial port on the board, but I'm not sure how to take advantage of it. I think its just the JP1 jumper that allows user programs to use that port

Finally, I'm not really sure how to get a C# program to extract data from a serial/com port. I believe there is a library for it but haven't yet found much information on it.

The communication needs only to be 1-way (board to PC), but two-way I could probably find use for.

Any pointers in the right direction for documentation or previous examples along these lines would be extremely helpful. Deadline is fast approaching :)

Thanks,
Ben Start a New Thread

--- In 6..., subscriptions@... wrote:
>
> I've been searching through the large amounts of threads in
> here, but haven't quite found what I'm looking for.
>
> My project is fairly simple - a large array of temperature
> sensors muxed into our HCS12's (Axiom CML12SDP256) ATD ports,
> whose values are then sent to our PC for graphical/numerical
> display.
>
> The code on both ends is complete, its the code that drives
> the middle that I can't quite understand.
>
> In class, about a year ago, we learned some basic serial
> communications using SCI0, via Port S, if i recall correctly.
> I built a 2-way communication system using the built-in MON12.
> But it doesn't seem applicable here, unless its way simpler
> than I'm thinking. I'd like (and i would think need) to use
> the main serial port on the board, but I'm not sure how to take
> advantage of it. I think its just the JP1 jumper that allows
> user programs to use that port
[...]
> The communication needs only to be 1-way (board to PC), but
> two-way I could probably find use for.

Dear subscriptions,

I've seen a few good discussions about using the SCI port, and even
with a serial monitor which uses the same port. You'd have to be more
specific to know what needs done.

It looks simple to me (way simpler than you're thinking?). What's the
problem with using the SCI port?

?You don't have a serial port available because it's used by MON12?
?You can't remember how you wrote the driver code a year ago?
?Not sure whether to use SCI0 or SCI1?
?You know how to implement bi-directional but not one direction?

Heck, sending output on SCI0 is one of the easiest things on the MCU:

;;; Example; send over SCI0 (DP256)
org $2000

;;; configure SCI0 for output (no need if monitor already did)
movw #52,$c8 ; 9600 baud (bus 8MHz)
bset $cb,#%00001000 ; enable TE (transmit)

;;; check status until TC is 1
WT1:
brclr $cc,#%01000000,WT1

;;; write the character 'a'
movb #$61,$cf

bra WT1 ; send again

END

Now for the C# stuff... I've never used it but I would try opening a
file named "COM1", and read from it. Start a New Thread

On the microcontroller side: I am not familiar with MON12 and cannot
exactly tell whether you are using it of if it is available to you. I
have used DBUG-12 to communicate serially, but I don't believe the C
source code is available for use as an example. However, the assembler
source code is available for the 68HC11 BUFFALO monitor and should be
relatively easy to port to the S12.

On the PC side: I cannot help you there.

Emmett Redd Ph.D. mailto:E...@missouristate.edu
Professor (417)836-5221
Department of Physics, Astronomy, and Materials Science
Missouri State University Fax (417)836-6226
901 SOUTH NATIONAL Dept (417)836-5131
SPRINGFIELD, MO 65897 USA

A bad day doing research is better than a good day doing something else.

________________________________

From: 6... [mailto:6...] On
Behalf Of s...@styx66.net
Sent: Tuesday, September 25, 2007 9:58 PM
To: 6...
Subject: [68HC12] Send data to PC (C#) via DB9 Serial?

I've been searching through the large amounts of threads in
here, but haven't quite found what I'm looking for.

My project is fairly simple - a large array of temperature
sensors muxed into our HCS12's (Axiom CML12SDP256) ATD ports, whose
values are then sent to our PC for graphical/numerical display.

The code on both ends is complete, its the code that drives the
middle that I can't quite understand.

In class, about a year ago, we learned some basic serial
communications using SCI0, via Port S, if i recall correctly. I built a
2-way communication system using the built-in MON12. But it doesn't seem
applicable here, unless its way simpler than I'm thinking. I'd like (and
i would think need) to use the main serial port on the board, but I'm
not sure how to take advantage of it. I think its just the JP1 jumper
that allows user programs to use that port

Finally, I'm not really sure how to get a C# program to extract
data from a serial/com port. I believe there is a library for it but
haven't yet found much information on it.

The communication needs only to be 1-way (board to PC), but
two-way I could probably find use for.

Any pointers in the right direction for documentation or
previous examples along these lines would be extremely helpful. Deadline
is fast approaching :)

Thanks,
Ben Start a New Thread

Hi,
About C#: download .NetFramework SDK or search Microsoft - .Net SDK
comes with a sample for serial communication on PC - I have used it to
develop
an internal tool - the sample has all the project, so is very easy to
modify it.
One word of caution: try to implement a communication protocol for your
application. Keep in mind that PC should be master and your board should be
the slave and not vice-versa; this is because PC is not a real time
tool, all interrupts
inside are serialized and processed when the operating system has the
time to do that.
Regards,
Yoan

s...@styx66.net wrote:
>
> I've been searching through the large amounts of threads in here, but
> haven't quite found what I'm looking for.
>
> My project is fairly simple - a large array of temperature sensors
> muxed into our HCS12's (Axiom CML12SDP256) ATD ports, whose values are
> then sent to our PC for graphical/numerical display.
>
> The code on both ends is complete, its the code that drives the middle
> that I can't quite understand.
>
> In class, about a year ago, we learned some basic serial
> communications using SCI0, via Port S, if i recall correctly. I built
> a 2-way communication system using the built-in MON12. But it doesn't
> seem applicable here, unless its way simpler than I'm thinking. I'd
> like (and i would think need) to use the main serial port on the
> board, but I'm not sure how to take advantage of it. I think its just
> the JP1 jumper that allows user programs to use that port
>
> Finally, I'm not really sure how to get a C# program to extract data
> from a serial/com port. I believe there is a library for it but
> haven't yet found much information on it.
>
> The communication needs only to be 1-way (board to PC), but two-way I
> could probably find use for.
>
> Any pointers in the right direction for documentation or previous
> examples along these lines would be extremely helpful. Deadline is
> fast approaching :)
>
> Thanks,
> Ben
>
> Start a New Thread

Hello,

The .Net framework 2.0 and onwards has a new serialport class (in
System.IO.Ports namespace) which makes it easier to use the comport.

A few notes:

Writing data to the port is synchronous. The write don't return until all data
is written. If you use RTS/CTS handshaking the data may not be sent at all and
then the write returns after the write timeout. If this is done in the UI
thread, the app is unresponsive during this time (can't move or resize or even
close the window). This is assuming it is a Forms based application (using
windows/dialogs instead of the console). This may not be a problem if you don't
use handshaking, have relaitvely high baudrate and relatively small data chunks
to send. If you need the write to be asynchronous (from the UI point of view)
either do it in a background thread or use the underlaying stream in the port
class (SerialPort.BaseStream.BeginWrite()) which will call a callback when
done.

The events that are fired by the serialport class receive functions ends up in
a thread different than the UI thread. Do not modify any UI controls from this
event method. I normally use a StringBuilder that I add incomming characters to
in the DataReceived event. When a complete message is received (terminated by
CR perhaps) I then call the UI thread with BeginInvoke with a new string
created from the StringBuilder.ToString() function and then clear the
StringBuilder object so it is ready to receive again. This way the same data
buffer isn't used in the receiving thread as in the higher level data parsing
functions that normally lives in the UI thread.

As mentioned before, use a master slave protocol where the PC is the master
with commands for reading data and writing settings to the slave. The debugging
process is also a lot easier if the data strings sent back and forth between
the master and the slave is in human readable form. Instead of sending binary
data, convert it to ASCII text and send the text. This takes more bytes but it
is much easier to analyse with a port sniffer since you can directly read what
is sent on the port.

If you are going to talk to several slaves from one PC you can use RS485
instead of RS232. Then you need an address in the commands and means to set
different addresses for the slaves (hardware switches or eeprom settings).

RS485 can be either half or full duplex. In full duplex the master TX lines is
connected to the RX lines in all slaves and all the slaves TX lines are
connected to the master RX line. This way the master can have the transmitter
enabled all the time and only the slaves have to switch on and of the
transmitter when it sends. With half duplex there is only one RX/TX pair and
the PC also has to switch on and off the transmitter. The switching of the
transmitter can be done with the RTS signal from the PC side. This is not so
easy though since there is no way to know exactly when data has been
transmitted from the PC and the transmitter has to be shut off. Even if the
synchronous write functions in the serialport returns it may not mean that all
data has been sent (because of the fifo buffers in the uart). This can be
handled with an RS232 to 485 converter that automatically handles the
switching. If it is going to be handled by the PC, I have found that using a
high resolution timer (such as the multimedia timer or the thread timer) can be
used to tell when data has been sent. Even so, there is quite a lot of jitter
(up to about 20ms perhaps) so I have also introduced a delay between when the
command is received in the slave and when the reply is sent back in order to
give the PC time to safely switch of the transmitter before the slave replies.
I have found that the delay needs to be somewhere around 50-70ms in order for
this to work with most PC's I have tried (old 100MHz 486 Windows98 to modern
with XP and Vista).

This got a bit longer than I intended so I will shut up now...

Good luck / Ruben

> Hi,
> About C#: download .NetFramework SDK or search Microsoft - .Net SDK
> comes with a sample for serial communication on PC - I have used it to
> develop
> an internal tool - the sample has all the project, so is very easy to
> modify it.
> One word of caution: try to implement a communication protocol for your
> application. Keep in mind that PC should be master and your board should be the
> slave and not vice-versa; this is because PC is not a real time tool, all
> interrupts inside are serialized and processed when the operating system has the
> time to do that. Regards, Yoan
>
> s...@styx66.net wrote:
> >
> > I've been searching through the large amounts of threads in here, but
> > haven't quite found what I'm looking for.
> >
> > My project is fairly simple - a large array of temperature sensors
> > muxed into our HCS12's (Axiom CML12SDP256) ATD ports, whose values are
> > then sent to our PC for graphical/numerical display.
> >
> > The code on both ends is complete, its the code that drives the middle
> > that I can't quite understand.
> >
> > In class, about a year ago, we learned some basic serial
> > communications using SCI0, via Port S, if i recall correctly. I built
> > a 2-way communication system using the built-in MON12. But it doesn't
> > seem applicable here, unless its way simpler than I'm thinking. I'd
> > like (and i would think need) to use the main serial port on the
> > board, but I'm not sure how to take advantage of it. I think its just
> > the JP1 jumper that allows user programs to use that port
> >
> > Finally, I'm not really sure how to get a C# program to extract data
> > from a serial/com port. I believe there is a library for it but
> > haven't yet found much information on it.
> >
> > The communication needs only to be 1-way (board to PC), but two-way I
> > could probably find use for.
> >
> > Any pointers in the right direction for documentation or previous
> > examples along these lines would be extremely helpful. Deadline is
> > fast approaching :)
> >
> > Thanks,
> > Ben
=============================Ruben Jsson
AB Liros Electronic
Box 9124, 200 39 Malm Sweden
TEL INT +46 40142078
FAX INT +46 40947388
r...@pp.sbbs.se
============================= Start a New Thread

Check Freemaster software package. It is very nice package and you
can download it from Freescale website free of charge.
It is very easy to communicate with the target board. You can use
the software and its graphical environment or even write your own
software by using its library (mbcc12.dll) for communicating with
the target board via a serial port.
There is an object module which should be linked with your embedded
application then everything is ready for retrieving data from target
board.

Regards,
Reza
--- In 6..., subscriptions@... wrote:
>
> I've been searching through the large amounts of threads in here,
but haven't quite found what I'm looking for.
>
> My project is fairly simple - a large array of temperature sensors
muxed into our HCS12's (Axiom CML12SDP256) ATD ports, whose values
are then sent to our PC for graphical/numerical display.
>
> The code on both ends is complete, its the code that drives the
middle that I can't quite understand.
>
> In class, about a year ago, we learned some basic serial
communications using SCI0, via Port S, if i recall correctly. I
built a 2-way communication system using the built-in MON12. But it
doesn't seem applicable here, unless its way simpler than I'm
thinking. I'd like (and i would think need) to use the main serial
port on the board, but I'm not sure how to take advantage of it. I
think its just the JP1 jumper that allows user programs to use that
port
>
> Finally, I'm not really sure how to get a C# program to extract
data from a serial/com port. I believe there is a library for it
but haven't yet found much information on it.
>
> The communication needs only to be 1-way (board to PC), but two-
way I could probably find use for.
>
> Any pointers in the right direction for documentation or previous
examples along these lines would be extremely helpful. Deadline is
fast approaching :)
>
> Thanks,
> Ben
> Start a New Thread

--- In 6..., "Edward Karpicz" wrote:
> I see it not the first time when someone communicating to PC via
> COM port is waiting for TC bit but not for TDRE bit. I think that
> TC (transfer complete) bit should be used in half duplex
> communications like RS485. RS485 transmitter should be active while
> transfer isn't complete, so we are using TC.
> Using full duplex COM port, I think it's better to use TDRE. TDRE
> (transmit data register empty or Tx buffer empty) allows to buffer
> trasnmitted data and send data back to back. Is there reason, I
> don't see, why are you using TC bit? Thanks
>
> [cut]
>
> Edward

Good eye, but this is beginner's code. It is the most general purpose
code, not written for speed, but for the widest use without the newbie
understanding why. In other words, this example is small-n-sturdy and
avoids many caveats that advanced developers have to work around.

1. this is a good base for all tx, because it works even with RS485

2. this avoids trouble if the MCU has errata related to TDRE

3. this turns on TE without affecting other bits, in case other
parameters

4. this is written to be portable and direct, tested on the free as12
version 1.2e (distributed by Eric Engler). I used $61 instead of 'a'
to avoid parsing trouble. In as12, you could say 'a instead but I
don't see that in other assembly code. Doesn't that drive you crazy,
missing the close quote mark?

BTW: Eric is hoping someone wants to take over as12 so he can work on
other projects. If someone wants to improve as12, that would be quite
useful. I've added some features to it (comparison in expressions),
but I don't have the capacity to take the whole project.

===== the example we're talking about ======;;; Example; send over SCI0 (DP256)
org $2000

;;; configure SCI0 for output (no need if monitor already did)
movw #52,$c8 ; 9600 baud (bus 8MHz)
bset $cb,#%00001000 ; enable TE (transmit)

;;; check status until TC is 1
WT1:
brclr $cc,#%01000000,WT1

;;; write the character 'a'
movb #$61,$cf

bra WT1 ; send again

END Start a New Thread

--- In 6..., "Jeff Smith" wrote:
> 1. this is a good base for all tx, because it works even with RS485
>
> 2. this avoids trouble if the MCU has errata related to TDRE
>
> 3. this turns on TE without affecting other bits, in case other
> parameters
>
> 4. this is written to be portable and direct, tested on the free
> as12
> version 1.2e (distributed by Eric Engler). I used $61 instead of 'a'
> to avoid parsing trouble. In as12, you could say 'a instead but I
> don't see that in other assembly code. Doesn't that drive you crazy,
> missing the close quote mark?
5. using TC helps slow down transmission. This seems to be very
important for Microsoft or other hardware that was only tested with
Win. I kept losing chars when controlling the Rogue MP3 player, but
was not seeing any trouble monitoring the serial line with Linux.
Finally when I turned off interrupts and used TC, it started getting
all the bytes, and works great. Sometimes faster is what you DON'T
want :-/ Start a New Thread

Hi Jeff,

[skip]

>
> ;;; check status until TC is 1
> WT1:
> brclr $cc,#%01000000,WT1
>
> ;;; write the character 'a'
> movb #$61,$cf
>
> bra WT1 ; send again
>
> END
>

I see it not the first time when someone communicating to PC via COM port is
waiting for TC bit but not for TDRE bit. I think that TC (transfer complete)
bit should be used in half duplex communications like RS485. RS485
transmitter should be active while transfer isn't complete, so we are using
TC.
Using full duplex COM port, I think it's better to use TDRE. TDRE (transmit
data register empty or Tx buffer empty) allows to buffer trasnmitted data
and send data back to back. Is there reason, I don't see, why are you using
TC bit? Thanks

[cut]

Edward Start a New Thread

Jeff,

thanks.

Edward

----- Original Message -----
From: "Jeff Smith"
To: <6...>
Sent: Thursday, September 27, 2007 5:28 PM
Subject: [68HC12] Re: Send data to PC (C#) via DB9 Serial?
> --- In 6..., "Jeff Smith" wrote:
>> 1. this is a good base for all tx, because it works even with RS485
>>
>> 2. this avoids trouble if the MCU has errata related to TDRE
>>
>> 3. this turns on TE without affecting other bits, in case other
>> parameters
>>
>> 4. this is written to be portable and direct, tested on the free
>> as12
>> version 1.2e (distributed by Eric Engler). I used $61 instead of 'a'
>> to avoid parsing trouble. In as12, you could say 'a instead but I
>> don't see that in other assembly code. Doesn't that drive you crazy,
>> missing the close quote mark?
> 5. using TC helps slow down transmission. This seems to be very
> important for Microsoft or other hardware that was only tested with
> Win. I kept losing chars when controlling the Rogue MP3 player, but
> was not seeing any trouble monitoring the serial line with Linux.
> Finally when I turned off interrupts and used TC, it started getting
> all the bytes, and works great. Sometimes faster is what you DON'T
> want :-/ Start a New Thread