ASCII codes ands Windows Hyperterminal

Go To Last Post
13 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi

I wondered if anyone can help.

Using windows hyperterminal you can send ASCII code 69 by using an old DOS trick:

hold the alt key down
type 069 on the numeric keypad
release the alt key

which is great, but does anyone know how to send ASCII code 0, i.e a null character? by any method?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Use the same method. Alt key, press 0, release alt key. BTW, this is specific to Windows not just Hyperterminal. So you can do this in any Windows application. And also, you don't have to type any leading '0' either.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi!

I had an elusive bug once that is worth mentioning in this context: I used the hyperterminal log function to capture binary 16-bit data sent as two consecutive bytes (i.e. receiving, not sending) Once in a while the data was messed up completely.... When sending a NULL (ASCII charachter 0) to hyperterminal and other terminal programs, it just don't show up anywhere! I figured it's best to use text only :?

BTW, anyone know the reason for this?

/Björn

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

"BTW, anyone know the reason for this? "

I can take a crack at it. It is actually a feature to ignore NULLs or not. It is usually a setup feature in the terminal program or programming driver. I do not know if Hyperterminal exposes this option or not. You may be able to set the configuration option to pass through all characters, especially when doing binary data trasfer.

Back when I was your age, when men were men and a computer could not keep up with a commo line, nulls were often inserted as placeholders to keep characters going down the line while a response was being formulated. It was like telling the receiver "Hold on..." or "Can you hear me now?" continually. It was especially important in synchronous commmunications.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well, nulls are a problem in all sorts of programs and systems.
Hyperterminal treats NULL's as reall NULL's or nothing. Thus if your trying to send a real zero numerical value you have a problem.
If the program receives a NULL, is it a real NULL, or a Zero number, or a ZERO ASCII (ascii 30)character, and so on? The NULL tends to be a pain in the butt all the time. So then if you send only ASCII a zero number would appear as a ASCII 30 character and a ASCII Zero would be a real NULL.
NULL's like he mentioned above were used as placeholders on older systems to allow the sending and receiving units to synchronize without losing data.
Another popular problem is a lot of programs treat text strings as an array with a null denoting the end of the string. So receiving a null when you aren't supposed to is a problem. In this case you might be trying to send a string from one system to another a NULL tells the receiving program that that is the end of the string. So you suddenly have messed up data appear too.
Nowadays, When I send data, I always use ASCII text, but on bigger systems I now have to use things like UNICODE as well. But then a more modern approach is to use XML too.
What I do now, most of the time, is to always send data as ASCII comma delimmitted text, then the receiving program simply has to save it out to a file. Later you can open it up and view it in a Spreadsheet easily, or import it into a database quickly too. In this case a zero number would look like comma zero comma (,0,) a zero text character would look like comma quote zero quote comma (,"0",) and a real null would look like comma comma (,,) with nothing in between. Thus you eliminate the ambiguity that occurs in data transfer. The other aproach is to use XML and send the data over that way as well, which solves the problem as to how to tell them all apart too.
The only real problem with XML is the data stream becomes a lot bigger with all of the extra stuff you have to send over. This isn't a problem if your dynamically creating the data to be transferred over though. The receiving systems are usually larger computers with losts of datastorage and RAM, so they don't choke like a MCU would. But nowadays sending the data over as XML allows you to use the newest programs and systems to advantage. Being in XML format makes it easier to display quickly in a webpage too.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

BTW check out Bray's Terminal as well - IIRC it can send/recieve hex/binary without needing to translate... as well as ASCII text (all at once in fact!).

-Colin

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think we are mixing up a REAL null which is hex 00 or Control@ and a ZERO which is hex 30.... or am I getting confused? :?

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Cheers peeps, but no luck yet.

I still can't get the dos trick to work for the ASCII nul character i.e. hex code 00. I also tried Bray's terminal, but it doesn't seem to send in hex, although it does receive in hex.

earlwb is right "nulls are a real problem" I would change the protocol, but unfortunately I have to use a pre-defined protocol, for consistency with past work.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Try the 'serial device Tester' by www.hackconsulting.com - it sends 00h and lots of other stuff, too ...

Andreas

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

sparkymark567 wrote:

I also tried Bray's terminal, but it doesn't seem to send in hex.

To send raw data from Bray's terminal, you need to use the "Transmit Macro" section (right bottom corner). You need to use the '$' or the '#' character. '$' is used for hexadecimal, and '#' for decimal. For instance, to send a NULL , followed by a LF and a CR you place

$00$0A$0D in the text box, and press the M1 button (or press F1 in your keyboard), or if you prefer, place #000#010#013 in the text box.

Regards,
Alejandro.
http://www.ocam.cl

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

earlwb wrote:
Well, nulls are a problem in all sorts of programs and systems.
Hyperterminal treats NULL's as reall NULL's or nothing. Thus if your trying to send a real zero numerical value you have a problem.

Interesting, I have successfully sent nulls through hyperterminal with no problem. I load audio data to a flash for one of my applications, via a plaintext file that is dumped out to the terminal (not using any form of transfer protocol or encoding) using hyper terminal. The nature of the audio data contains long run's of NULLS, I have yet to have any problems.

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I know the latest version of the tool on freaks called superterm, can handle nulls being sent and being received and displayed.
sending a null -- define a function key, tell it to send character with a data string of 0. then that function key sends null.
receiving -- you must turn on hex display. the null character does not display in the character display.
Carel is great at fixing these oddbal problems.
HTH,

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gskinner wrote:
sending a null -- define a function key, tell it to send character with a data string of 0. then that function key sends null.

Why is the above necessary? 0x00 (Null) is Control, Shift, 2 in the keyboard or Control @. So unless the O/S (windows?) or the terminal program does something strange with that key combination it is just another key, like for example Control J will send a line feed char (0x0a). But then again I may be missing something :)

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly