Searching \ for '[EE] Hyperterminal' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/index.htm?key=hyperterminal
Search entire site for: 'Hyperterminal'.

Exact match. Not showing close matches.
PICList Thread
'[EE] Hyperterminal'
2010\10\02@100627 by John Chung

picon face
Hi guys,

Some very interesting facts on hardware debugging.

http://www.eetimes.com/electronics-blogs/other/4208931/Engineers-try-to-resist-finger-pointing-in-debugging-radar-jammer?cid=NL_EELife


>From the article comes the real need to have
a CRC check on the bootloader itself for the incoming image file.


Regards,
John





2010\10\02@133455 by Neil Cherry

flavicon
face
On 10/02/2010 10:06 AM, John Chung wrote:
> Hi guys,
>
> Some very interesting facts on hardware debugging.
>
> www.eetimes.com/electronics-blogs/other/4208931/Engineers-try-to-resist-finger-pointing-in-debugging-radar-jammer?cid=NL_EELife
>
>
>>From the article comes the real need to have
> a CRC check on the bootloader itself for the incoming image file.

Shouldn't that be a DUH! moment? First there was no software dump
protocol, next there was no crc check on boot or at least a debug
crc check. This sounds like someone asking for trouble. I don't
know maybe it comes from my modem days (line is never clean).

-- Linux Home Automation         Neil Cherry       spam_OUTncherryTakeThisOuTspamlinuxha.com
http://www.linuxha.com/                         Main site
http://linuxha.blogspot.com/                    My HA Blog
Author of:            Linux Smart Homes For Dummie

2010\10\02@155014 by Sean Breheny

face picon face
I agree with Neil. I think these guys should really have known better.
I think I discovered the kind of issues they met when I was about 14
years old.

Sean


On Sat, Oct 2, 2010 at 1:32 PM, Neil Cherry <.....ncherryKILLspamspam@spam@linuxha.com> wrote:
{Quote hidden}

>

2010\10\02@163502 by Olin Lathrop

face picon face
Sean Breheny wrote:
>>
http://www.eetimes.com/electronics-blogs/other/4208931/Engineers-try-to-resist-finger-pointing-in-debugging-radar-jammer?cid=NL_EELife
>
> I agree with Neil. I think these guys should really have known better.
> I think I discovered the kind of issues they met when I was about 14
> years old.

Yeah, this is really basic stuff.  What kind of idiot relies on Hyperterm to
upload code anyway!?  That also means this guy did a bootloader without a
checksum.  Duh!  I've done a lot of bootloaders, but I never once even
considered leaving out the checksum.  Even if you think the communications
channel is fine, what if power gets interrupted in the middle of a upload,
the line gets disconnected, the user kills the program, or any of a number
of sufficiently possible things that could cause a bad uploaded image?

It seems to me that reloading the previous working version would be one of
the first things you do to verify the hardware didn't break.  Another big
"duh" for waiting 3 days to do that!

This article is not really about some gotcha you have to watch out for, but
rather proof once again there's always another moron right around the
corner.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000

2010\10\02@171125 by Chris McSweeny

picon face
I'm loving all the smugness on this thread. Presumably nobody on here
has ever made a silly mistake?

Chris

On Sat, Oct 2, 2010 at 9:35 PM, Olin Lathrop <.....olin_piclistKILLspamspam.....embedinc.com> wrote:
{Quote hidden}

>

2010\10\02@174801 by Olin Lathrop

face picon face
Chris McSweeny wrote:
> I'm loving all the smugness on this thread. Presumably nobody on here
> has ever made a silly mistake?

We've probably all made dumb mistakes, but the difference is we realized it
was due to our own stupidity and didn't write up a web page making it sound
like a legitimate gotcha.  This software guy isn't a moron for making a
mistake or just forgetting a checksum.  He's a moron because he tried to get
away with something stupid, used poor debugging strategies, wasted 3 days as
a result, and still thinks he ran into a gotcha worth warning others about.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000

2010\10\02@182327 by Chris McSweeny

picon face
I'll give you that the first debugging step should have been to revert
to the last known good solution - though that's also worth reminding
people. But you're telling me that hyperterminal mangling 0D0A pairs
isn't useful information (it's the sort of thing I'd always check for,
but then I do a lot of moving between Windows and Unix domains where
such issues are normal, and I'd kind of expect HT to do that)? The
thing is, you seem to be suggesting that there is no useful
information in that webpage, when your own experience of people asking
you FAQs should suggest it's anything but - not everybody knows the
stuff you consider to be "basics".

On Sat, Oct 2, 2010 at 10:48 PM, Olin Lathrop <EraseMEolin_piclistspam_OUTspamTakeThisOuTembedinc.com> wrote:
{Quote hidden}

>

2010\10\02@195403 by William \Chops\ Westfield

face picon face

On Oct 2, 2010, at 1:35 PM, Olin Lathrop wrote:

>  What kind of idiot relies on Hyperterm to upload code anyway!?

To me, the bigger surprise is not using one of the standard HEX  formats for the data transfer.  Those carefully avoid putting binary  data in the data stream, and have the checksum per line that ought to  detect most errors...  (Though I wonder just how many of the  bootloaders I use actually check those checksums.)

In some sense, this is a sort of "standard mistake" for Desktop PC  programmers faced with their first example of "real" multi-vendor data  communications (not coddled over some consumer-grade shrink-wrapped  set of hardware and drivers (like USB))  But I would have expected  better based on the author's reported background...

I do have to admit that a lot of the software development practices I  used to think were "normal" early in my career, now seem extremely  primitive and naive...

BillW

2010\10\02@211027 by Neil Cherry

flavicon
face
On 10/02/2010 05:11 PM, Chris McSweeny wrote:
> I'm loving all the smugness on this thread. Presumably nobody on here
> has ever made a silly mistake?

I've lots of silly mistakes but I learn a long time ago that you can
never trust communications. I learned that in my college course
(where the experiments failed more than they succeeded - Wow I learned
a lot in those labs). This was an on the job moment, I only screwed up
big time there! ;-)

Okay so maybe I am being a little smug.

-- Linux Home Automation         Neil Cherry       ncherryspamspam_OUTlinuxha.com
http://www.linuxha.com/                         Main site
http://linuxha.blogspot.com/                    My HA Blog
Author of:            Linux Smart Homes For Dummie

2010\10\02@212149 by Neil Cherry

flavicon
face
On 10/02/2010 07:54 PM, William "Chops" Westfield wrote:
>
> On Oct 2, 2010, at 1:35 PM, Olin Lathrop wrote:
>
>>  What kind of idiot relies on Hyperterm to upload code anyway!?
>
> To me, the bigger surprise is not using one of the standard HEX  
> formats for the data transfer.  Those carefully avoid putting binary  
> data in the data stream, and have the checksum per line that ought to  
> detect most errors...  (Though I wonder just how many of the  
> bootloaders I use actually check those checksums.)

All the bootloaders I've worked with or written have though I haven't
worked with a boot loader in a while. I'm a network engineer, not an
embedded engineer anymore. Now this is my 'hobby'.

> In some sense, this is a sort of "standard mistake" for Desktop PC  
> programmers faced with their first example of "real" multi-vendor data  
> communications (not coddled over some consumer-grade shrink-wrapped  
> set of hardware and drivers (like USB))  But I would have expected  
> better based on the author's reported background...

Ah, I think you've hit it on the head. Though I would have expected
the hardware engineer to have some 'common sense'. Is it not normal
for a hardware engineer to know some software? Or am I expecting
too much? Don't hardware engineers work with software engineer or
is everything just thrown over the wall to the next team?

-- Linux Home Automation         Neil Cherry       @spam@ncherryKILLspamspamlinuxha.com
http://www.linuxha.com/                         Main site
http://linuxha.blogspot.com/                    My HA Blog
Author of:            Linux Smart Homes For Dummie

2010\10\02@213717 by Sean Breheny

face picon face
Hi Chris,

I once spent almost a month trying to figure out what was wrong with
an embedded computer system based on a 68000 processor, only to find
out eventually that my project partner and I had different definitions
of "upper" and "lower" when it came to the two 8-bit wide flash chips
which formed the 16-bit wide program memory for the processor. I would
program them using a homebrew flash programmer and then hand them to
him as the "upper" and "lower" ICs. I took this to mean upper and
lower significance, he took it to mean upper and lower address. In
other words, it was an endian problem.

However, I was a high-school senior working with almost no test
equipment - we eventually built a logic analyzer out of a FIFO chip
and discovered that the processor was fetching every instruction in
inverted byte order and we suddenly realized what was happening. We
swapped the two flash chips and it immediately ran most of the code
properly. I think this is a mistake that anyone can make, but I
wouldn't write an article about it for a trade journal and I would be
concerned if it took a professional engineer a month to figure it out,
especially an engineer who is working on military radar jamming
equipment!

Sean


On Sat, Oct 2, 2010 at 5:11 PM, Chris McSweeny <KILLspamcpmcsweenyKILLspamspamgmail.com> wrote:
> I'm loving all the smugness on this thread. Presumably nobody on here
> has ever made a silly mistake?
>
> Chris

2010\10\03@020421 by William \Chops\ Westfield

face picon face

On Oct 2, 2010, at 6:19 PM, Neil Cherry wrote:

> Though I would have expected
> the hardware engineer to have some 'common sense'. Is it not normal
> for a hardware engineer to know some software?

Well, it was a "radar jammer" or some such.  That sort-of implies the  sort of HW engineer that might not know much about SW.  While I claim  to know something about HW (being primarily a SW engineer), I might  draw the line before saying anything about "radio stuff"; that's a  class unto itself!

> Don't hardware engineers work with software engineer or
> is everything just thrown over the wall to the next team?

 :-(

BillW

2010\10\03@031944 by John Chung

picon face
What he has taught is a good lesson. Everyone makes mistakes. I do!
Anyway each mistake will be a lesson to learn from. I rather
learn from ppl's mistakes than from my own*which is expensive and time consuming*.

John


--- On Sun, 10/3/10, Sean Breheny <RemoveMEshb7TakeThisOuTspamcornell.edu> wrote:

{Quote hidden}

> -

2010\10\03@034148 by Michael Watterson

face picon face
 On 02/10/2010 22:11, Chris McSweeny wrote:
> I'm loving all the smugness on this thread. Presumably nobody on here
> has ever made a silly mistake?
>
> Chris
I'm sure I have made silly mistakes. But I don't think I'd try to make a rather contrived article out of it.

 Which seems to be suggesting "watch out for using wrong tools". It was their bootloader design that was wrong, not using Hyperterminal.

Poor example for what the article claimed to be trying to prove

2010\10\03@072431 by Olin Lathrop

face picon face
'William Chops" Westfield ' <westfwEraseMEspam.....mac.com wrote:
> To me, the bigger surprise is not using one of the standard HEX
> formats for the data transfer.  Those carefully avoid putting binary
> data in the data stream, and have the checksum per line that ought to
> detect most errors...  (Though I wonder just how many of the
> bootloaders I use actually check those checksums.)

That would certainly be better than a raw data dump, but it's rather verbose
and requires more decoding than necessary in the bootloader.  I usually try
to minimize the burden on the small embedded system.  So far I've sent the
new image mostly unencoded in binary, although there is always a checksum in
there somewhere.  Most of the time the data channel won't add errors, so a
single wide (like 32 bit) checksum at the end will be fine since the
probability of needing a re-transmit is small.

The important point is that the bootloader always does a checksum on the
main app image before running it.  If the main app program memory is the
only copy, then stay in the bootloader requesting or waiting for another
upload.  If there is a external copy, then maybe you can run the previous
image.  Never ever run corrupted code.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000

2010\10\03@074118 by Marechiare

picon face
> Yeah, this is really basic stuff.  What kind of idiot relies on Hyperterm to
> upload code anyway!?  That also means this guy did a bootloader without a
> checksum.  Duh!  I've done a lot of bootloaders, but I never once even
> considered leaving out the checksum.  Even if you think the communications
> channel is fine, what if power gets interrupted in the middle of a upload,
> the line gets disconnected, the user kills the program, or any of a number
> of sufficiently possible things that could cause a bad uploaded image?

I think you are over-reacting. The checksum and the self-check code
could be included into the uploaded image as microcontroller's extra
memory is not a problem now. The self-check code would run each time
the microcontroller is powered on. All the potentially dangerous
initializations would be done only after the self-check is ok.
Probably not as reliable as for the bootloader with a checksum in some
cases, but still should work well for most.

2010\10\03@074606 by Olin Lathrop

face picon face
Neil Cherry wrote:
> I've lots of silly mistakes but I learn a long time ago that you can
> never trust communications. I learned that in my college course
> (where the experiments failed more than they succeeded - Wow I learned
> a lot in those labs). This was an on the job moment, I only screwed up
> big time there! ;-)

One time in college I was building a device to interface with the I/O bus of
a minicomputer (sortof like a PIC, but slower, larger, more expensive, and
required its own room with dedicated power transformer and air conditioner)..
One of the signalling lines was open collector to be pulled down by the
device as part of some handshake.  The minicomputer manual specified a
surprisingly high max sink current, something like 50mA.  All I had at the
time as I was wire wrapping this late one night in the dorm was a open
collector NAND gate that could sink a lot (7438?), but not quite as much as
the worst case spec.  I'd always gotten away with "close" before, and
figured there was margin built in on both ends.

By the time I got the rest of the device built and got time on the
minicomputer (you had to sign up for a 2 hour slot days in advance) to test
it, I had forgotten about the late night shortcut.  I got the driver
working, wired it into the OS, and things actually worked fine.  Then days
later people were reporting flakiness.  As I'm sure you guess by now, I
eventually traced it back to the NAND gate not always pulling the signal
line low enough.  I had to add a whole extra chip on the board just to get
enough current sink.  Everything worked reliably after that.

There wasn't the web at the time, but I still wouldn't have written up a
page telling people how I ran into this gotcha trying to make what I did
somehow sound reasonable and it was just that Murphy got me.  What I did was
stupid, and I got caught.  In fact, I don't think I ever told anyone until
now what exactly I did to fix the flaky behavior.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000

2010\10\03@075547 by Olin Lathrop

face picon face
'William Chops" Westfield ' <EraseMEwestfwspammac.com wrote:
> Well, it was a "radar jammer" or some such.  That sort-of implies the
> sort of HW engineer that might not know much about SW.

I thought the article described a team of two people, one software the other
hardware.  It mentioned something about finger pointing between the hardware
and software guy.  In a case like that, it is more forgivable that the
hardware guy knows less about software.  Or even if he did, he wasn't the
one that wrote the code.  Perhaps the hardware guy should have suggested
trying the previous working code to verify the hardware was still working,
but otherwise the problem looks to be squarely due to the stupidity of the
software guy.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000

2010\10\03@075835 by Olin Lathrop

face picon face
John Chung wrote:
> What he has taught is a good lesson.

Yes.  Never hire that guy.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000

2010\10\03@080037 by Marechiare

picon face
> One time in college I was building a device to interface with the I/O bus of
> a minicomputer (sortof like a PIC, but slower, larger, more expensive, and
> required its own room with dedicated power transformer and air conditioner).
> One of the signalling lines was open collector to be pulled down by the
> device as part of some handshake.

Was it PDP-12 ? What was the power transformer for

2010\10\03@080425 by Olin Lathrop

face picon face
Marechiare wrote:
> I think you are over-reacting. The checksum and the self-check code
> could be included into the uploaded image

Then you're screwed if the self-check part of the upload image got
corrupted.

Also, this guy clearly didn't have any checking.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000

2010\10\03@082203 by Olin Lathrop

face picon face
Marechiare wrote:
> Was it PDP-12 ?

No, it was a Varian 620-I with IDIIOM vector graphics display.

> What was the power transformer for?

It was a "contant voltage" transformer, essentially a power conditioner,
surge suppressor, and somewhat of a regulator.  It may also have stepped
down from a higher voltage, I don't remember.  It was definitely a big hunk
of iron that was bolted to the floor and required a jig like a engine hoist
to lift.

The Varian was a 16 bit machine that was outfitted with the maximum 32K
16-bit words of core memory that it could address.  The memory cycle time
was 1.8uS, so a immediate add to a register took 3.6uS.  The instruction set
was more primitive than a dsPIC, although it did have multiply and divide
instructions.  It had no stack.

The main console was the size of a desk, with the vector graphics unit
another half a desk wide.  This computer was used for image processing
research until the late 1970s.  The plaque on the inside of the front panel
said it was manufactured in March of 1969.

The operating system that came with it was apparently designed before disk
drives were common.  It was intended to be used with tape drives.  We did
have a disk, but the OS treated it as 16 logical tape drives.  In the summer
of 1975 I wrote a new operating system for it, which was in use at least
until I left RPI in 1980.  My operating system had named disk files (wow,
what a concept), device independent I/O, and a few other nice things the
original didn't have.

2010\10\03@082915 by Marechiare

picon face
>> I think you are over-reacting. The checksum and the self-check
>> code could be included into the uploaded image
>
> Then you're screwed if the self-check part of the upload image
> got corrupted.

You're too in this case of corrupted upload image. The self-check part
may be only a small part of the image, say 5%. So, 1 screwed of
1000000, or 1.05 of 1000000 for this reason would not make big
difference. Just code self-check part the way it won't burn anything
in case it gets corrupted. And, yes, bootloader with a checksum
probably would be a better choice.


> Also, this guy clearly didn't have any checking.

Yes, that's not good at all, considering the fact that MS VB6 (5) had
been for 5 years on the market at that time. In VB6 one can easily
develop quite intricate data communication over RS-232. Just sending
the image, getting it back and comparing would work

2010\10\03@083154 by Marechiare

picon face
>> Then you're screwed if the self-check part of the upload image
>> got corrupted.
>
> You're too in this case of corrupted upload image.

You have checksum and can repare the code, sorry. Still, it may be one
for millions, if this is a LED controller, who would care

2010\10\03@083457 by Marechiare

picon face
> Just sending the image, getting it back and comparing
> would work.

Would work even for Hyperterminal, if I'm not mistaken. :-

2010\10\03@084040 by sergio masci

flavicon
face


On Sun, 3 Oct 2010, Marechiare wrote:

> > Just sending the image, getting it back and comparing
> > would work.
>
> Would work even for Hyperterminal, if I'm not mistaken. :-)

So Hyperterminal converts the 0D0A to 0D when sending it TO the embedded system then converts the 0D back to 0D0A when receiving FROM the embedded system.

Yeah that would work - what you sent would compare with what you received :-)

Regards
Sergio Masc

2010\10\03@084536 by Olin Lathrop

face picon face
Marechiare wrote:
> Just code self-check part the way it won't burn anything
> in case it gets corrupted.

You have no way of knowing what it might do if it gets corrupted.

Having the suspect code check itself is frankly a silly idea.

> And, yes, bootloader with a checksum
> probably would be a better choice.

Just probably?


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000

2010\10\03@084713 by Marechiare

picon face
>> > Just sending the image, getting it back and comparing
>> > would work.
>>
>> Would work even for Hyperterminal, if I'm not mistaken. :-)
>
> So Hyperterminal converts the 0D0A to 0D when sending it TO the embedded
> system then converts the 0D back to 0D0A when receiving FROM the embedded
> system.
>
> Yeah that would work - what you sent would compare with what you received
> :-)

I assume the bootloader would do byte-level processing on-fly if needed

2010\10\03@084737 by Olin Lathrop

face picon face
Marechiare wrote:
> You have checksum and can repare the code, sorry. Still, it may be one
> for millions, if this is a LED controller, who would care?

It was a radar jammer for the Navy.  It unexpectedly not working could very
well mean dead sailors.  I expect they care.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000

2010\10\03@085737 by Marechiare

picon face
> The main console was the size of a desk, with the vector
> graphics unit another half a desk wide.

Yes, these vector  graphics units were terrific creatures, a lot of
precise analog stuff inside the monitor and a huge number of 74 logic
PCBs under the desk

2010\10\03@091029 by Marechiare

picon face
>> Just code self-check part the way it won't burn anything
>> in case it gets corrupted.
>
> You have no way of knowing what it might do if it gets
> corrupted.
>
> Having the suspect code check itself is frankly a silly
> idea.
>
>> And, yes, bootloader with a checksum
>> probably would be a better choice.
>
> Just probably?

Yes, probably, cause if the communication channel is as reliable as
the microcontroller flash memory, you have basically the same
probability for the bootloader to get corrupted in case if it is in
the memory already, or is just loaded to the memory. You said "Navy",
I'm not sure flash is always the most reliable choice in this case.
Here comes R, I bet :-

2010\10\03@101008 by alan.b.pearce

face picon face
> On Oct 2, 2010, at 1:35 PM, Olin Lathrop wrote:
>
> >  What kind of idiot relies on Hyperterm to upload code anyway!?

Too many words Olin ...

In my mind it should read " What kind of idiot relies on Hyperterm" as
it is such a pig of a thing to configure sensibly that I always avoided
it. Why Microsoft ever included it I don't know. I always grabbed a copy
of the Win 3.1 Terminal, and copied that over to use. Only limitation
that I found was the restriction to COM 1-4. More recently there have
been other suitable programs listed in this community.
-- Scanned by iCritical.

2010\10\03@174716 by William \Chops\ Westfield

face picon face

On Oct 3, 2010, at 12:41 AM, Michael Watterson wrote:

> I don't think I'd try to make a rather contrived article out of it.

It's "teacher mode."  For every idiot willing to document their silly  mistakes, you have at least a chance of some large number of people  learning SOMETHING.  Such idiots are valuable.  If they learned from  their own mistakes, they might not even be idiots any more...

There are worse in the blogosphere, and I gather that trade journals  are really hurting these days, given the constantly shrinking paper  copies I get...

BillW

2010\10\04@103846 by Herbert Graf

picon face
On Sat, 2010-10-02 at 16:35 -0400, Olin Lathrop wrote:
> It seems to me that reloading the previous working version would be one of
> the first things you do to verify the hardware didn't break.  Another big
> "duh" for waiting 3 days to do that!

I am constantly amazed by how many people just don't know how to debug.

Missing the "load the prior version to see if the hardware is gone" is a
COMMON mistake I see.
Fact is people get so focused on something they ignore the big picture.
Stepping back for a moment and considering that maybe adding that NOP to
your code DID break the code somehow opens you to seeing that yes, you
just crossed a certain address that exposed a bug in the compiler.

Unfortunately, there is a certain level of debugging that cannot be
taught, some people have it, some people don't.

TTYL

2010\10\04@113141 by M. Adam Davis

face picon face
On Sat, Oct 2, 2010 at 7:54 PM, William "Chops" Westfield
<RemoveMEwestfwEraseMEspamEraseMEmac.com> wrote:
> I do have to admit that a lot of the software development practices I
> used to think were "normal" early in my career, now seem extremely
> primitive and naive...

Exactly, and further how would we expect people new to embedded
development to understand, nevermind plan for, these problems?

A lot of embedded code is written by programmers who are used to
deterministic systems programming - where the memory never fails, the
processor never goes off into the weeds, and TCP/IP gaurantees data
transmission without errors, or at least notice that the socket has
closed.

The article points to a fairly basic error that would easily be caught
quickly by a seasoned engineer carefully plodding through the
debugging process, but that doesn't mean it doesn't bear mentioning.

Experience is what someone gains when they don't listen to advice.

-Ada

2010\10\04@121508 by alan.b.pearce

face picon face
> Unfortunately, there is a certain level of debugging that cannot be
> taught, some people have it, some people don't.

No they need to buy the book available here
http://www.debuggingrules.com/ but even then with the poster on the wall
(downloaded from the first link on that page) they still wouldn't
remember ...
-- Scanned by iCritical.

2010\10\04@131509 by Dwayne Reid

flavicon
face
At 02:35 PM 10/2/2010, Olin Lathrop wrote:
>Sean Breheny wrote:
> >>
>http://www.eetimes.com/electronics-blogs/other/4208931/Engineers-try-to-resist-finger-pointing-in-debugging-radar-jammer?cid=NL_EELife
>
>Yeah, this is really basic stuff.  What kind of idiot relies on Hyperterm to
>upload code anyway!?
>
>This article is not really about some gotcha you have to watch out for, but
>rather proof once again there's always another moron right around the
>corner.

I was going to let this slip by but find that I just can't.

I think that this article teaches several important things and I applaud the author for sharing his mistakes - it well may help others avoid similar problems.

1) He is obviously an old hand at this - he mentions having worked with his software developer for 20 years.  Yet he took a shortcut that wound up biting him on his rear.

In fact, he says that he was so focused that he neglected to do the simple checks first.  He readily admits that WAS a mistake.

2) He was developing something for the Armed Forces.  I strongly suspect that he is anything but a moron. As far as I know, you have to prove yourself pretty thoroughly before you get selected to work on projects such as the one that the author mentioned.

3) I, for one, had NO idea that Hyperterminal would mangle 0D0A pairs.  This IS useful information, contrary to what Olin Lathrop thinks.

Olin - again you are acting like a twit.  There was simply no need to use words like "idiot" and "moron" when discussing the author of this article.  He made a mistake, 'fessed up to it, and explained what he did wrong.  This IS a useful story.

dwayne

-- Dwayne Reid   <RemoveMEdwaynerspam_OUTspamKILLspamplanet.eon.net>
Trinity Electronics Systems Ltd    Edmonton, AB, CANADA
(780) 489-3199 voice          (780) 487-6397 fax
http://www.trinity-electronics.com
Custom Electronics Design and Manufacturing

2010\10\04@135303 by Olin Lathrop

face picon face
Dwayne Reid wrote:
> He made a mistake, 'fessed up to it,

Not exactly.  He made the problem sound obscure and unexpected and his
methods reasonable.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000

2010\10\04@153637 by Chris McSweeny

picon face
On Mon, Oct 4, 2010 at 6:15 PM, Dwayne Reid <RemoveMEdwaynerTakeThisOuTspamspamplanet.eon.net> wrote:
> 2) He was developing something for the Armed Forces.  I strongly
> suspect that he is anything but a moron. As far as I know, you have
> to prove yourself pretty thoroughly before you get selected to work
> on projects such as the one that the author mentioned.

IME that's not necessarily the case (I'm not going into further details here!)

Chris

2010\10\04@154033 by Chris McSweeny

picon face
On Mon, Oct 4, 2010 at 4:31 PM, M. Adam Davis <EraseMEstienmanspamspamspamBeGonegmail.com> wrote:
> A lot of embedded code is written by programmers who are used to
> deterministic systems programming - where the memory never fails, the
> processor never goes off into the weeds, and TCP/IP gaurantees data
> transmission without errors, or at least notice that the socket has
> closed.

Could you let me know what environment you're talking about - I want
to work with that rather than fixing problems with embedded, PC, Linux
and Solaris systems I currently get paid for.

Chri

2010\10\04@154152 by Richard Prosser

picon face
Just out of interest, I came upon a similar problem with a program I
wrote way, way back in CPM days. (IIRC it was a BASIC varient on an
HP125). The "printer" driver automatically changed 0x09 (tab) to 4
spaces. This was fine for printing, but you had to use the print
statement for file saves also So binary saves got corrupted.

It took a while to find, figure out, and work around.

RP

On 5 October 2010 06:52, Olin Lathrop <RemoveMEolin_piclistKILLspamspamembedinc.com> wrote:
> Dwayne Reid wrote:
>> He made a mistake, 'fessed up to it,
>
> Not exactly.  He made the problem sound obscure and unexpected and his
> methods reasonable.
>
>
> ********************************************************************
> Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
> (978) 742-9014.  Gold level PIC consultants since 2000.
>

2010\10\04@192706 by Lorenzo Luengo

flavicon
face
 I'd like to get some suggestion on terminal emulators, to avoid running into this problem.

Any ideas?

For linux i know minicom

And for windows?

I have heard of TeraTerm, but never used it. Any comments con this one? Is there another (free) one?

El 04-10-2010 11:31, M. Adam Davis escribió:
{Quote hidden}

-- Lorenzo Luengo Contreras
Ingeniero Civil Electrónico
Laboratorio MIDGEO (LF-106)
Facultad de Ciencias Físicas y Matemáticas
Universidad de Concepción
Concepción - Chile
+56-41-2207400
http://midgeo.udec.cl

2010\10\04@194220 by Carl Denk

flavicon
face
Windows I use Realterm with Windows XP and ME.
http://realterm.sourceforge.net/

It is free, I like the ability to quickly set up a string, option the LF and CR and then with a mouse click send it . The incoming can be displayed in a variety and combinations of ASCI, Hex, etc.  Plus lots of other captures, and other features I haven't needed. :)

On 10/4/2010 7:26 PM, Lorenzo Luengo wrote:
{Quote hidden}

>

2010\10\04@194722 by Marcel Duchamp

picon face
On 10/4/2010 4:26 PM, Lorenzo Luengo wrote:
>    I'd like to get some suggestion on terminal emulators, to avoid
> running into this problem.
>
> Any ideas?
>
> For linux i know minicom
>
> And for windows?
>
> I have heard of TeraTerm, but never used it. Any comments con this one?
> Is there another (free) one?

Brays Terminal program; it's my go-to for terminal programs:
https://sites.google.com/site/terminalbpp

2010\10\04@195204 by PICdude

flavicon
face
Last week I was experimenting with the trial version of "RS232 Hex Com  Tool", from here... http://rs232pro.com/ .  For $40, I'm probably  going to just buy it.

Cheers,
-Neil.



Quoting Lorenzo Luengo <KILLspamlluengospamBeGonespamdgeo.udec.cl>:

{Quote hidden}

2010\10\04@200427 by PICdude

flavicon
face
Nice.  Thanks.


Quoting Marcel Duchamp <EraseMEmarcel.duchampspamEraseMEsbcglobal.net>:

> Brays Terminal program; it's my go-to for terminal programs:
> https://sites.google.com/site/terminalbpp/
> --

2010\10\04@201157 by Chris McSweeny

picon face
On Tue, Oct 5, 2010 at 12:26 AM, Lorenzo Luengo <@spam@lluengo@spam@spamspam_OUTdgeo.udec.cl> wrote:
>  I'd like to get some suggestion on terminal emulators, to avoid
> running into this problem.

I use Putty - no idea how performance compares,  but it works well
enough for what I use it for.

Chris

2010\10\04@203037 by Harold Hallikainen

face
flavicon
face

>> Any ideas?
>>
>> For linux i know minicom
>>
>> And for windows?
>>
>> I have heard of TeraTerm, but never used it. Any comments con this one?
>> Is there another (free) one?
>
> Brays Terminal program; it's my go-to for terminal programs:
> https://sites.google.com/site/terminalbpp/


I've used Brays Terminal, but the most recent version seems to use up all
the resources in the machine.

I use Tera Term A LOT. I think it's excellent. There's a version that does
SSH, but, last I saw, it was out of date and does not work with current
SSH servers. But, for RS232 and USB emulation of RS232 and for plain old
TCP, it's great.

If I want to see the hex codes going back and forth, I use RealTerm. It
supports RS232 and TCP.

Harold




-- FCC Rules Updated Daily at http://www.hallikainen.com - Advertising
opportunities available

2010\10\04@222719 by Neil Cherry

flavicon
face
On 10/04/2010 11:31 AM, M. Adam Davis wrote:
> On Sat, Oct 2, 2010 at 7:54 PM, William "Chops" Westfield
> <spamBeGonewestfwspamKILLspammac.com> wrote:
>> I do have to admit that a lot of the software development practices I
>> used to think were "normal" early in my career, now seem extremely
>> primitive and naive...
>
> Exactly, and further how would we expect people new to embedded
> development to understand, nevermind plan for, these problems?

Yes, I guess we were all beginners. My big mistake was not knowing
that some lines needed pull-ups on my first board design. I learned
not to do that again by having to solder the missing resistors
on 100 boards.

> A lot of embedded code is written by programmers who are used to
> deterministic systems programming - where the memory never fails, the
> processor never goes off into the weeds, and TCP/IP gaurantees data
> transmission without errors, or at least notice that the socket has
> closed.

Sorry I work with Windows, I do not know this world you speak of. ;-)

Seriously, I really hadn't given it much thought, the subjects you
mentioned because even in my 'desktop' programming I always expect
these kinds of problems. The embedded world creeps into my other
programming. This is not to say that I'm really a programmer or
good at it.

-- Linux Home Automation         Neil Cherry       .....ncherryspam_OUTspamlinuxha.com
http://www.linuxha.com/                         Main site
http://linuxha.blogspot.com/                    My HA Blog
Author of:            Linux Smart Homes For Dummie

2010\10\05@002645 by William \Chops\ Westfield

face picon face

On Oct 4, 2010, at 4:26 PM, Lorenzo Luengo wrote:

> I'd like to get some suggestion on terminal emulators, to avoid
> running into this problem.

You'll run into other problems.  Sometimes you want CRLF to become CR,  and sometimes you don't.  Any sort of raw unchecked byte stream is a  poor choice for binary code.  And then there's 17/19, and null, and  the 8th bit, and so on.   Terminal emulators are for emulating  terminals; if you're uploading code you really ought to be using a  special purpose program that uploads code...

(and then we get to Operating System mangling of Async Serial Data  Streams.)

BillW

2010\10\05@010549 by Sean Breheny

face picon face
One of my co-workers wrote a decent bootloader which works with the
xmodem file transfer option in Hyperterminal. As poor as it is,
Hyperterminal has the advantage that you know (or at least knew,
before Windows Vista) that it would always be installed on the vast
majority of Windows machines.

Sean

On Tue, Oct 5, 2010 at 12:26 AM, William "Chops" Westfield
<TakeThisOuTwestfw.....spamTakeThisOuTmac.com> wrote:
{Quote hidden}

>

2010\10\05@012240 by William \Chops\ Westfield

face picon face

On Oct 4, 2010, at 10:05 PM, Sean Breheny wrote:

> One of my co-workers wrote a decent bootloader which works with the
> xmodem file transfer option in Hyperterminal.

that's fine.  The "Xmodem file transfer" is distinct from the terminal  emulator.
Dangerous, but it ought already have been debugged with binary file  transfers.

("text mode" FTP file transfers between different operating systems.   Oh joy!
I guess the main point of the lesson is that "text" is pretty ill- defined.)

BillW

2010\10\05@121549 by Joe Koberg

flavicon
face

 I just use PuTTY



On 10/4/2010 6:26 PM, Lorenzo Luengo wrote:
{Quote hidden}

>

2010\10\06@033727 by KPL

picon face
I second that, putty seemed to be the most convenient. I'm using that
on linux, but I do not see an option to use serial connection in
windows version. Probably it's just old, can not compare versions now.


On Tue, Oct 5, 2010 at 7:15 PM, Joe Koberg <.....joespamRemoveMEosoft.us> wrote:
{Quote hidden}

>

2010\10\06@041053 by Michael Watterson

face picon face
 On 06/10/2010 08:37, KPL wrote:
> I second that, putty seemed to be the most convenient. I'm using that
> on linux, but I do not see an option to use serial connection in
> windows version. Probably it's just old, can not compare versions now.
>
Originally PuTTY on windows didn't have serial, it does now.

I use it a lot for ssh, but also use it for local RS232.

I've not had a problem with hyperterminal and its CR LF, but I never contemplated using it for Code. (since at least 1996 and NT4.0, I'm not sure if it was in NT3.5 or if we used it.)
Under settings there is an option to "Send Line ends with line feeds" and "Append Line feeds to incoming line ends" and to Echo local and Wrap screen.
You can also "force 7 bit" on receive.

By default it's on "automatic" for terminal emulation, TTY may be better if you don't want unexpected behaviour. I never found the VT100 or VT52 etc very good. Years ago I think we installed teraterm for DEC terminal emulation for  UNIX server applications (Insurance Quotes and Call Centres). There are various other settings for the unwary to fiddle with.

On test with terminals on embedded Linux devices and testing with other SW it doesn't do anything unexpected.
I can only conclude the original author was using some strange version of Hyperterminal apart from fact you shouldn't use a text terminal to upload code.

2010\10\06@084340 by Olin Lathrop

face picon face
Lorenzo Luengo wrote:
> I'd like to get some suggestion on terminal emulators, to avoid
> running into this problem.

Hyperterm is useable enough if what you really want is a terminal emulator.
The problem was that somebody tried to use it for more than that without
bothering to understanding it or apparently ASCII text interchange in
general.

That said, I find need for a true terminal emulator to be very rare.  Using
ASCII text as a communication protocol with a small embedded system makes
little sense.  Mostly you want a binary protocol, since that's much easier
to generate and parse in the resource-limited system.

Usually I use my TEST_SIO program for simple cases and maybe the early
stages of debugging.  It allows you to send and receive individual binary
bytes.  They can be specified in decimal, hex and other number bases, and as
ASCII text.  The received bytes are shown in decimal, hex, and ASCII.

Normally I write a dedicated test program for each project that needs to
communicate with a host.  This is easy to do, and provides a text based
command line interface to the binary protocol.  As a project evolves, extra
commands get added for testing and debugging, and this provides a natural
platform.  It also sets up the serial line exactly as needed.  You really
don't want to tell your customers to run Hyperterm and have to specify a
bunch of settings they have to make before things work.  If you give them
the dedicated test program instead, they only have to specify the serial
port (with default to COM 1 of course) and everything else just works.

Again, keep it as simple as possible in the small embedded system and push
the complexity of providing a user interface to the host where it's easy to
do.

2010\10\06@090902 by RussellMc

face picon face
> Usually I use my TEST_SIO program for simple cases and maybe the early
> stages of debugging.  It allows you to send and receive individual binary
> bytes.  They can be specified in decimal, hex and other number bases, and as
> ASCII text.  The received bytes are shown in decimal, hex, and ASCII.

Any comments on "escape sequences" / Syncing etc?.

If things never got lost and Murphy had died they might almost not be
needed :-).
But in real world use you are going to sync in some manner.
Conceivably as "raw" and simple as a single escape sequence that
otherwise lets the sender and receiver decide what to make of what's
on the channel. Possibly packets with known preamble and word count
and checksum/CRC or whatever. Proceeding upwards in complexity until
you arrive at X25 or more (obviously not in the context mentioned
here).
What do you do and why? [ "You" there is notionally Olin, but there
are liable to be a range of preferences and reasons].

     Russell

2010\10\06@095402 by Olin Lathrop

face picon face
RussellMc wrote:
> Any comments on "escape sequences" / Syncing etc?.
>
> If things never got lost and Murphy had died they might almost not be
> needed :-).
> But in real world use you are going to sync in some manner.
> Conceivably as "raw" and simple as a single escape sequence that
> otherwise lets the sender and receiver decide what to make of what's
> on the channel. Possibly packets with known preamble and word count
> and checksum/CRC or whatever. Proceeding upwards in complexity until
> you arrive at X25 or more (obviously not in the context mentioned
> here).
> What do you do and why? [ "You" there is notionally Olin, but there
> are liable to be a range of preferences and reasons].

This is rarely the problem you make it out to be.  Almost always, I send
commands starting with a opcode byte and followed by data bytes dependent on
the opcode.  This does mean both ends need to understand the command set
else they will get out of sync.  However, this is no different from any of a
100 other things that have to be right else they are bugs.  Usually you test
each command and response (I call these same packets coming from the small
system to the host "responses" as apposed to "commands", although they may
not all be in direct response to commands) individually right after having
written the code.  Once it works, it's going to stay working.  There is
really very little problem with this in practise.

That's doesn't mean I always totally ignore the problem though.  Very simple
things you can do is to make 0 and 255 unused opcodes or specifically define
them as NULL opcodes.  That means each end can tolerate any number of 0s or
255s without problem.  Most unwanted bytes due to startup or whatever will
be 0 or 255.

Sometimes I have deliberately used this to sync on startup.  The embedded
system may send out 16 NULLs on startup, knowing that the longest possible
response totals less than 16 bytes, for example.  If in doubt, send 256 0
bytes on startup.  Startup time is rarely a issue.

Another trick that I have used occasionally is to add a timeout.  If nothing
has been received for 100mS, for example, then the current packet will be
aborted and the next received byte interpreted as a opcode.  This means that
any command or response needs to be sent without a 100mS gap anywhere
between its bytes, but that usually happens anyway such that it would be
work to prevent it.  Even on a PC with a desktop operating system, the app
would generally be stuffing a command into its own buffer, then pass the
whole buffer to the OS to send.  The app might get interrupted for more than
100mS while stuffing the buffer, but once the low level driver deep in the
OS gets the buffer, it's going to get chugged out the serial line without
gaps.

In a few cases I did have to implement a packet protocol with checksums,
ACK, etc, for the reasons you cited.  This has been quite rare though.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000

2010\10\06@103519 by RussellMc

face picon face
>> ... in real world use you are going to sync in some manner.

> This is rarely the problem you make it out to be.

Pardonez moi?
I think I thought I just asked a question with a series of example
solutions escalating in complexity.

However, for a lack of problem ...

{Quote hidden}

you seem to have done an excellent job of suggesting various ways of
varying complexity of meeting the requirement.
So, thanks, that seems to have well addressed the problems I
apparently don't  have :-).

Others may also have different interesting and/or useful ad hoc ways
of achieving this.



        R

2010\10\06@162109 by Ruben Jönsson

flavicon
face
{Quote hidden}

For a master/slave protocol over a serial line there is no need to reinvent something new. Use the modbus (RTU) protocol.

<http://www.modbus.org/specs.php>

If this is for a RS485 network with a PC as the master you need a RS232 to RS485 converter with automatic turnaround between TXing and RXing on the PC side since the PC might not have time to do that manually (using RTS or DTR).

One of the benefits with using the modbus protocol is that you can use any of the modbus test/debug applications that exists out there to directly test the slaves before the master software is done.

Another benefit is if your slave device gets popular enough, there is always someone else that wants to handle the master side without your PC application. Almost all PLCs and SCADA applications can handle modbus out of the box and you don't have to write up a lot of protocol specifications for other programmers.

/Ruben
==============================
Ruben Jönsson
AB Liros Electronic
Box 9124, 200 39 Malmö, Sweden
TEL INT +46 40142078
FAX INT +46 40947388
spamBeGoneruben@spam@spamspam_OUTpp.sbbs.se
==============================

2010\10\07@063016 by Matt Rhys-Roberts

flavicon
face
 Let's not fight among ourselves, but rather see the article as kung fu practice. Spotting weakness in [other people's] strategy will hopefully prevent us from repeating it.

Matt


On 02/10/2010 23:23, Chris McSweeny wrote:
{Quote hidden}

>> -

2010\10\07@065011 by Matt Rhys-Roberts

flavicon
face
 I've repeatedly observed Hyperterminal toggling the last bit of every other character, in a stream of identical characters, when it was supposed to be in 8N1 mode. I always thought that the stop bit was supposed to be a definite bit, not something that alternates between characters. Re-starting the app with *exactly* the same configs seems to flush the problem. I expect this feature was included just to keep us on our toes, bring the online community together to talk about it, etc. Nice job!

Matt



On 03/10/2010 15:10, alan.b.pearceEraseMEspamstfc.ac.uk wrote:
{Quote hidden}

2010\10\07@074121 by Olin Lathrop

face picon face
Matt Rhys-Roberts wrote:
> I've repeatedly observed Hyperterminal toggling the last bit of
> every other character,

It all depends on what mode you configure it to.  I've seen modes that do
that, but also modes where the "parity" bit is fixed.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000

2010\10\07@120322 by Bob Blick

face
flavicon
face

On Thu, 07 Oct 2010 11:48:58 +0100, "Matt Rhys-Roberts" said:
>   I've repeatedly observed Hyperterminal toggling the last bit of every
> other character, in a stream of identical characters, when it was
> supposed to be in 8N1 mode. I always thought that the stop bit was
> supposed to be a definite bit, not something that alternates between
> characters. Re-starting the app with *exactly* the same configs seems to
> flush the problem. I expect this feature was included just to keep us on
> our toes, bring the online community together to talk about it, etc.
> Nice job!

I've seen that too, but tracked it down to the Prolific USB-RS232
adapter. When I changed to a different driver the problem went away.

And the newest driver from Prolific just doesn't work at all for some of
the adapters.

No wonder they are the cheapest and most prolific :)

Cheers,

Bob

-- http://www.fastmail.fm - Choose from over 50 domains or use your own

2010\10\09@110723 by Marechiare

picon face
{Quote hidden}

Small embedded system are not necessarily resource-limited system
nowadays. You can get a 32-bit microcontroller for under US$3.  You
could push the complexity of providing a user interface not to the
host, but to the very microcontroller, - developer's tools are quite
easy these days. Why not give a customer the possibility to test the
system with whatever tools he likes?
:-)

2010\10\09@120113 by Olin Lathrop

face picon face
Marechiare wrote:
> Small embedded system are not necessarily resource-limited system
> nowadays.

That's what I meant by "small", so in this case small embedded systems are
resource limited by definition.  These are generally processors that do not
run a operating system and where you have to at least occasionally think
about memory usage.  This is in contrast to most PC programs that use so
little of the processor, memory, and other resources that the amount of such
is no design consideration at all.

> You can get a 32-bit microcontroller for under US$3.

The bit-ness has nothing to do with the resource limitations.  For example,
I recently saw a 32 bit microcontroller for under $1, but it had very little
program and data memory.  You can get a 8 bit PIC 18 with a lot more
resources than that 32 bit micro.  It was from the line formerly from
Phillips if I remember right.

> You
> could push the complexity of providing a user interface not to the
> host, but to the very microcontroller, - developer's tools are quite
> easy these days. Why not give a customer the possibility to test the
> system with whatever tools he likes?

It all depends on the requirements, of course.  Nothing is free, and the
more high volume the design, the more carefully you have to consider what
you want to pay for.  If part of the device's job is to interface with end
users, then of course it needs a human interface.  If not, then you have to
consider whether you want to pay for that interface in every unit or how
much of it to push elsewhere at the expense of making testing and debugging
a little more complicated.  to use your example, perhaps the $3 micro could
be a $2 micro if it could push more of the user interface elsewhere.  If
you're making 10K of them, that's probably worth it.  If you're making 100K,
it's likely a no-brainer.

If the interface will be a text window on a PC, then it's unlikely a ASCII
terminal protocol makes sense.  Ultimately the embedded processor will deal
with binary information, so the conversion has to be performed someplace.
Doing it on the PC will take less work and will give you a better result
because the serial line and terminal setup can be done automatically.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000

2010\10\09@135653 by Marechiare

picon face
>> Small embedded system are not necessarily
>> resource-limited system nowadays.
>
> That's what I meant by "small", so in this case small embedded
> systems are resource limited by definition.

Your implicit definition of a small embedded system looks reasonable
for me, but Google's says "Small embedded system" can be quite
capable. World's moving on. New embedded developers generation may
even elect to start with
resource-rich-32-bit-3-bucks-microcontroller-based-system

More... (looser matching)
- Last day of these posts
- In 2010 , 2011 only
- Today
- New search...