M
Mac
Guest
On Wed, 08 Jun 2005 03:52:06 -0600, Guy Macon wrote:
ITYM "Newsgroups."
--Mac
ITYM "Newsgroups."
--Mac
Navigation
Install the app
How to install the app on iOS
Follow along with the video below to see how to install our site as a web app on your home screen.
Note: This feature may not be available in some browsers.
More options
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
G
Guy Macon
Guest
Kelly Hall wrote:
(Power On Self Test) code should be omitted.
[1] When the I/O is so limited that you simply don't have a way of
conveying the result of the POST. One embedded system I worked on
had as it's only output a doll moving her hand in a somewhat random
manner. It didn't make a lot of sense to write a POST that waved
one way if it passed and another when it failed and then expecting
the average toy buyer to understand that.
[2] When there is nothing that the customer can do if it fails.
Another embedded system I worked on was a toy that had one button
as the only input, and a voice as the only output. The button
simply applied power to the electronics, which then turned on a
transistor to supply power after the button was released, said
the phrase, then turned itself off. That was a case where neither
a POST or a watchdog made any sense The watchdog resets the CPU
and that is being done anyway, and the POST checks the hardware,
but hearing the phrase does that. Other examples where where
there is nothing that the customer can do if it fails come to mind,
such as the electronics that makes a bomb go off when it reaches
the target.
[3] When you need very rapid recovery from a power-on reset. This
is a surprisingly common situation in small embedded systems that
sit powered off, are turned on by another part of the system to do
some work and then turned off when they are done. not having a
POST can easily double the battery life if the run time is short.
Note that in the above cases it may still be appropriate to have
a self test, but started with some special key combination or
triggered by holding an unused pin high during power-up.
I do agree that in most cases there should be a POST, and that it
should be the first thing the software folks write. Doing it that
way allows them to understand any quirks in the hardware, and also
makes it less likely that a hardware change with undesirable side
effects gets through to production.
It's also a great way to resolve finger-pointing between hardware
and software engineers. Whenever a "that's a hardware problem!
No it's software problem!" dispute happens, I ask the software
engineer to add a test to the POST that makes it fail when the
hardware failure occurs. (It is important when doing this to
let the POST loop all night or all weekend to catch intermittents)
If they can do that, it's a lot easier for the hardware engineer
to address a problem that causes a POST failure. If they *can't*
do that, it is likely to be a software problem.
Just for completeness, I can think of other situations where POSTThat said, I think POST code ought to be nearly free because
the software folks should have written that code early on if
only to verify >that the first runs of the hardware performed
adequately. Better to ship that stuff, hidden from the user,
unless you absolutely have no room in the ROMs for it.
(Power On Self Test) code should be omitted.
[1] When the I/O is so limited that you simply don't have a way of
conveying the result of the POST. One embedded system I worked on
had as it's only output a doll moving her hand in a somewhat random
manner. It didn't make a lot of sense to write a POST that waved
one way if it passed and another when it failed and then expecting
the average toy buyer to understand that.
[2] When there is nothing that the customer can do if it fails.
Another embedded system I worked on was a toy that had one button
as the only input, and a voice as the only output. The button
simply applied power to the electronics, which then turned on a
transistor to supply power after the button was released, said
the phrase, then turned itself off. That was a case where neither
a POST or a watchdog made any sense The watchdog resets the CPU
and that is being done anyway, and the POST checks the hardware,
but hearing the phrase does that. Other examples where where
there is nothing that the customer can do if it fails come to mind,
such as the electronics that makes a bomb go off when it reaches
the target.
[3] When you need very rapid recovery from a power-on reset. This
is a surprisingly common situation in small embedded systems that
sit powered off, are turned on by another part of the system to do
some work and then turned off when they are done. not having a
POST can easily double the battery life if the run time is short.
Note that in the above cases it may still be appropriate to have
a self test, but started with some special key combination or
triggered by holding an unused pin high during power-up.
I do agree that in most cases there should be a POST, and that it
should be the first thing the software folks write. Doing it that
way allows them to understand any quirks in the hardware, and also
makes it less likely that a hardware change with undesirable side
effects gets through to production.
It's also a great way to resolve finger-pointing between hardware
and software engineers. Whenever a "that's a hardware problem!
No it's software problem!" dispute happens, I ask the software
engineer to add a test to the POST that makes it fail when the
hardware failure occurs. (It is important when doing this to
let the POST loop all night or all weekend to catch intermittents)
If they can do that, it's a lot easier for the hardware engineer
to address a problem that causes a POST failure. If they *can't*
do that, it is likely to be a software problem.
G
Guy Macon
Guest
Mac wrote:
Oops. You are, of course, correct. My apologies,Guy Macon wrote:
(Note for those who dislike moderated newsgroups; you may wish
to check your Subject header and edit it to your liking.)
ITYM "Newsgroups."
T
Tobias Brox
Guest
[Guy Macon]
--
Tobias Brox
So, we are waiting ;-)I have my own opinion about
how the author of the page should have handled this, but I would
like to hear some other opinions first.
--
Tobias Brox
J
John Larkin
Guest
On Thu, 9 Jun 2005 06:05:57 CST, Tobias Brox <tobias@stud.cs.uit.no>
wrote:
kickstart his personal newsgroup, he's better come up with a few less
boring subjects.
John
wrote:
Maybe some of us are. If Guy wants to hijack posts from s.e.d. toI have my own opinion about
how the author of the page should have handled this, but I would
like to hear some other opinions first.
So, we are waiting ;-)
kickstart his personal newsgroup, he's better come up with a few less
boring subjects.
John
G
Guy Macon
Guest
Tobias Brox wrote:
technical problems should contain a cut and paste section saying:
[1] Feel free to contact us by telephone at 1-800-555-5555,
by email at support@example.com, or on the web at
[ http://www.example.com/support/ ].
[2] We offer a money back guarantee; if for any reason you are
not satisfied with your purchase, feel free to return it for a
full refund, including shipping both ways. See
[ http://www.example.com/support/ ] for details on how to return
the product.
[3] We have a FAQ page with information about operating and
troubleshooting our product. The answer to your problem may
be there.
A happy customer tells a friend. An unhappy customer tells
all of his friends. An unhappy customer who is clearly in the
wrong might respond to your pointing that fact out by putting
up a [Your Company Name]sucks.com website. Apologize, refund,
block all purchases from that person, and then stop responding
to them. Not very satisfying, but it maximizes profits over
the long run.
That's my opinion.
To my way of thinking, every communication with a customer havingGuy Macon wrote:
I have my own opinion about
how the author of the page should have handled this, but I would
like to hear some other opinions first.
So, we are waiting ;-)
technical problems should contain a cut and paste section saying:
[1] Feel free to contact us by telephone at 1-800-555-5555,
by email at support@example.com, or on the web at
[ http://www.example.com/support/ ].
[2] We offer a money back guarantee; if for any reason you are
not satisfied with your purchase, feel free to return it for a
full refund, including shipping both ways. See
[ http://www.example.com/support/ ] for details on how to return
the product.
[3] We have a FAQ page with information about operating and
troubleshooting our product. The answer to your problem may
be there.
A happy customer tells a friend. An unhappy customer tells
all of his friends. An unhappy customer who is clearly in the
wrong might respond to your pointing that fact out by putting
up a [Your Company Name]sucks.com website. Apologize, refund,
block all purchases from that person, and then stop responding
to them. Not very satisfying, but it maximizes profits over
the long run.
That's my opinion.
J
Jim Kingdon
Guest
Well, the vendor insulted the customer when he had no need to. (Sure,
the customer deserved it, but what does that have to do with anything?)
Once the vendor figured out that the customer wasn't going to figure
out how to use the product successfully, he should have just gotten it
returned and a refund issued, without future attempts to troubleshoot
or try to point out what had gone wrong. And no, he shouldn't have
tried to retain the customer.
Is that what you were asking?
Y
Yzordderrex
Guest
I would have handeled the guy wurse. I have little time avalable to
deal with inkompetant dolts. God bles my wife and anyone else who
works in retail and has to deael with the armys of morons on a daily
basis. I want to know why we can't just kill stoopid people on site.
If abortion is legal, and capitol punishment is ok, then wtf can't I
just shoot the imbeciles?
regards,
BOb
ps pleese ignor spel errors cuz I kan't spel good,
deal with inkompetant dolts. God bles my wife and anyone else who
works in retail and has to deael with the armys of morons on a daily
basis. I want to know why we can't just kill stoopid people on site.
If abortion is legal, and capitol punishment is ok, then wtf can't I
just shoot the imbeciles?
regards,
BOb
ps pleese ignor spel errors cuz I kan't spel good,
Guest
Guy Macon wrote:
Good points there.
I'm more inclined to side with the customer on this one, even though he
wasnt a very bright bulb. If I sell something that doesnt work, its my
responsibilty to get it to the point of working. If the customer takes
part in that process theyre helping me do it. Yes, when you sell
something, it is required to work. If your products have a failure
rate, as all do, its your can to carry.
Not all products can be made plug and play, when theyre not, the
customer needs to be advised at purchase time that some setup will be
needed, that tronics knowledge is required, etc, whatever it is. If you
dont advise them, unsuitable buys happen, and things go wrong.
I can understand the customer reaching the point of 'ive really had
enough of this, take it back,' sometimes there are really more
important things to do with ones life than help the seller try to get
their thing going. The customer really does not owe it to you to do all
that.
If there are common issues with a product, enclose or link to a fault
finding FAQ.
And as Guy says, always offer some speedier way to deal with it, like
exchanging for a new one etc.
And, at the end of the day, if your product never worked, as is the
case here, yes the customer is entitled to a full refund. Sorry, but
they are.
The seller never asked if the customer was willing to help them work
thru it, just assumed. The seller insulted the buyer re their Eng qual
- and I saw nothing to tell us the buyer wasnt an engineer. I've met
the odd bozo that somehow managed to qualify, and even the brightest
have times of duh. And I expect not all engs understand IR, basic and
syllabus-ic as it may be.
In short I'd say the seller has a whole set of wrong ideas about the
seller/buyer relationship, obligations, legal standing, the whole
thing.
And ultimately, the question isnt whose fault is it, its how can we
avoid this next time.
Regards, NT
To my way of thinking, every communication with a customer having
technical problems should contain a cut and paste section saying:
[1] Feel free to contact us by telephone at 1-800-555-5555,
by email at support@example.com, or on the web at
[ http://www.example.com/support/ ].
[2] We offer a money back guarantee; if for any reason you are
not satisfied with your purchase, feel free to return it for a
full refund, including shipping both ways. See
[ http://www.example.com/support/ ] for details on how to return
the product.
[3] We have a FAQ page with information about operating and
troubleshooting our product. The answer to your problem may
be there.
Good points there.
I'm more inclined to side with the customer on this one, even though he
wasnt a very bright bulb. If I sell something that doesnt work, its my
responsibilty to get it to the point of working. If the customer takes
part in that process theyre helping me do it. Yes, when you sell
something, it is required to work. If your products have a failure
rate, as all do, its your can to carry.
Not all products can be made plug and play, when theyre not, the
customer needs to be advised at purchase time that some setup will be
needed, that tronics knowledge is required, etc, whatever it is. If you
dont advise them, unsuitable buys happen, and things go wrong.
I can understand the customer reaching the point of 'ive really had
enough of this, take it back,' sometimes there are really more
important things to do with ones life than help the seller try to get
their thing going. The customer really does not owe it to you to do all
that.
If there are common issues with a product, enclose or link to a fault
finding FAQ.
And as Guy says, always offer some speedier way to deal with it, like
exchanging for a new one etc.
And, at the end of the day, if your product never worked, as is the
case here, yes the customer is entitled to a full refund. Sorry, but
they are.
The seller never asked if the customer was willing to help them work
thru it, just assumed. The seller insulted the buyer re their Eng qual
- and I saw nothing to tell us the buyer wasnt an engineer. I've met
the odd bozo that somehow managed to qualify, and even the brightest
have times of duh. And I expect not all engs understand IR, basic and
syllabus-ic as it may be.
In short I'd say the seller has a whole set of wrong ideas about the
seller/buyer relationship, obligations, legal standing, the whole
thing.
And ultimately, the question isnt whose fault is it, its how can we
avoid this next time.
Regards, NT