Searching \ for 'HI-TECH C I2C functions' 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/i2cs.htm?key=i2c
Search entire site for: 'HI-TECH C I2C functions'.

Truncated match.
PICList Thread
'HI-TECH C I2C functions'
1999\03\06@141625 by Gerhard Fiedler

picon face
At 00:03 03/07/99 +1000, Clyde Smith-Stubbs wrote:
>On Fri, Mar 05, 1999 at 02:26:45PM -0800, Gerhard Fiedler wrote:
>> i haven't had problems with the long math. but the i2c master (single
>> master only) example provided works only in some very rare (of course
>> undocumented) circumstances. it is easily fixable though. i don't know why
>> they don't do it. i sent a message regarding this to them without response.
>
>Actually you did get a response, but because your comment about the
>I2C code problem was phrased as an afterthought to another question, and
>mentioned only "a potential problem", I think it was overlooked by the
>programmer who handled the question.

just to put the record straight here: this is correct, i got a response to
my email (with some other questions), but not to this item. and the only
time i really needed a fast response with a (rather serious) compiler bug,
i got a fixed version the next day.

still this is something i often wonder. when i send an email to tech
support (this is not anymore specifically about hitech) with a number of
questions, i expect a response in the style like

> 1) bla bla
ok, this is...
> 2) bla bla
here you do...
> 3) blla bla
that's your fault, you just need to...

ie. =some= comment to each question (even if it is "i don't have anything
to say here"). what i often get is some response loosely related to one or
some of my questions but not straight answers to each of the questions. i
just don't understand this, seems strange to me. the citation feature of
email clients seems to make it so easy to do it right.


>The code certainly worked when we tested it, but it's quite possible
>that it doesn't under all circumstances. That's one reason we provide
>the source code for it, in case we've made a mistake.

more specifically, it only worked if the SDA and SCL lines were on
different ports and no port read (or read-modify-write) accesses occured
during an i2c command. that's rather restricting -- especially if not
documented :)  the old read-modify thingie. but since it was not some wierd
bug but a consistent misconception, it was rather easy to fix.

ge

1999\03\06@190311 by steve

flavicon
face
> still this is something i often wonder. when i send an email to tech
> support (this is not anymore specifically about hitech) with a number of
> questions, i expect a response in the style like
>
> > 1) bla bla
> ok, this is...

I agree, but I have also sat on the other end of the phone and can
appreciate why not all answers are given long, extended answers.
I'd have to say that I have found Hi-tech support to be pretty
good. There seem to be intelligent life forms on the other end (which
makes a pleasant change) and there is also a users mailing list.

What I would really like to see from embedded tools vendors, is a
listing of known bugs. I know that any marketing type would faint at
the idea but if it is restricted access to people who already have
bought the product, they aren't loosing anything. After all, they
provide source code for the bugs, why not save us the time of digging
them out ?
It is very frustrating to eventually discover a bug and then be told
that they've known about it for months and a fix will be available
about a week after your product ships.

Steve.
======================================================
Steve Baldwin                Electronic Product Design
TLA Microsystems Ltd         Microcontroller Specialists
PO Box 15-680, New Lynn      http://www.tla.co.nz
Auckland, New Zealand        ph  +64 9 820-2221
email: spam_OUTstevebTakeThisOuTspamtla.co.nz      fax +64 9 820-1929
======================================================

1999\03\08@081445 by Caisson

flavicon
face
> Van: Gerhard Fiedler <.....listsKILLspamspam@spam@HOME.COM>
> Aan: PICLISTspamKILLspamMITVMA.MIT.EDU
> Onderwerp: Re: HI-TECH C I2C functions
> Datum: zondag 7 maart 1999 12:44
>
> At 12:59 03/07/99 +1200, Steve Baldwin wrote:
> >What I would really like to see from embedded tools vendors, is a
> >listing of known bugs.
>
> i don't know why this shouldn't be required by law from all software
> vendors. in fact i don't quite understand why it isn't already required
--
> withholding knowledge of bugs seems rather close to some kind of deceit
or
> fraud or however you may call it.

I second that.  I would allso like to see such a list for computer
break-ins in Banks (so I can choose the savest company to deposit my
money), troubles with aeroplanes (so I can choose the savest company to fly
with), and gouverments (so I can choose the the savest future to live in).
I'm afraid that none of those list will ever be public, because the
credability of above "companies" will make a nose-dive (pun intended), and
that will not be good for the benefits ....

Greetz,
 Rudy Wieser

1999\03\08@104816 by Andy Kunz

flavicon
face
>i don't know why this shouldn't be required by law from all software
>vendors. in fact i don't quite understand why it isn't already required --
>withholding knowledge of bugs seems rather close to some kind of deceit or
>fraud or however you may call it.

Simply tell them you are using their product to develop a life-support
system and ask if there are any things you need to know.

Andy

  \-----------------/
   \     /---\     /
    \    |   |    /          Andy Kunz
     \   /---\   /           Montana Design
/---------+   +---------\     http://www.montanadesign.com
| /  |----|___|----|  \ |
\/___|      *      |___\/     Go fast, turn right,
                              and keep the wet side down!

1999\03\08@134550 by Gerhard Fiedler

picon face
At 10:41 03/08/99 -0500, Andy Kunz wrote:
>>i don't know why this shouldn't be required by law from all software
>>vendors. in fact i don't quite understand why it isn't already required --
>>withholding knowledge of bugs seems rather close to some kind of deceit or
>>fraud or however you may call it.
>
>Simply tell them you are using their product to develop a life-support
>system and ask if there are any things you need to know.

i guess many woud just tell me to read the license.

but in any case this wouldn't help a lot to stay current. it's not that
they find a bug or two in a year -- bugs are a reality, there is a constant
flow of bugs reports for most bigger packages, and all the software
licenses acknowledge that by excluding them from any kind of warranty :),
but they don't acknowledge them when it comes down to let you know what
they know. i would even go so far as not to require that they publish bugs
=they= find, but that they publish bugs =others= find (and report to them).

ge

1999\03\08@161036 by William Chops Westfield

face picon face
As a somewhat useful (?) example, cisco publishes a buglist that is visible
(searchable, even, over the web) for all customers.  However - there are
valid reasons for not publishing some of the bugs.  For example:

1) Internal issues.  For example, if there is a relatively simple way to
  speed up some aspect of operation, found by source inspection or whatever,
  that isn't likely to be published.  "xxx could be faster" isn't really
  a bug, anyway.

2) bugs found in unreleased software.  These should get updated if the
  software is released before the bug is fixed.

3) bugs that have a significant security impact.  There is a well-established
  procedure for security-related bugs, and it does NOT envolve telling the
  world how to exploit the bug before there is a fix in place.

Publishing all your bugs isn't necessarilly a great thing.  I see about
4000 bugs "open" at the moment, so it's not exactly bedtime reading...

BillW

1999\03\08@190110 by Gerhard Fiedler

picon face
At 13:09 03/08/99 -0800, William Chops Westfield wrote:
>As a somewhat useful (?) example, cisco publishes a buglist that is visible
>(searchable, even, over the web) for all customers.  However - there are
>valid reasons for not publishing some of the bugs.  For example:
>
>1) Internal issues.  For example, if there is a relatively simple way to
>   speed up some aspect of operation, found by source inspection or whatever,
>   that isn't likely to be published.  "xxx could be faster" isn't really
>   a bug, anyway.

as you say, this is not what most consider a "bug," at least not in the
sense we've been talking about -- unless "xxx" is =specified= to be faster
than it actually is. then it is a bug -- or a wrong spec.

>2) bugs found in unreleased software.  These should get updated if the
>   software is released before the bug is fixed.

i don't consider unreleased software existent, for most cases. in any case,
unreleased software is beta test software, and all participating in a
decent beta test program should of course have access to a complete (beta)
bug list. it's no fun to hunt down a bug when 20 people do the same thing
without knowing of each other.

>3) bugs that have a significant security impact.  There is a well-established
>   procedure for security-related bugs, and it does NOT envolve telling the
>   world how to exploit the bug before there is a fix in place.

in that case, the bug fix should of course have such a high priority that
it'll be available almost by the time the bug would've been published :)


>Publishing all your bugs isn't necessarilly a great thing.  I see about
>4000 bugs "open" at the moment, so it's not exactly bedtime reading...

since the above cases address either cases where it's not about bugs (1) or
not about the software with which the company's customers work (2) or not
about bugs that are left to "hang around" until they find the time to fix
them (3) -- why should it =not= be a great thing to publish =bugs= of
software with which people actually =work= which don't get =immediately= fixed?

or would you like to spend two days hunting a bug in a system, and when you
finally find it, you discover that it's a compiler bug, and when you go
tell the compiler's manufacturer, they tell you: "oh yes, we know that for
about two months now. it's a bug in our compiler. we have a workaround for
it. here you go"...  i guess most people would consider it a
=really=great=thing= to have not spent these two days finding something out
that probably 15 people have spent their two days before to find out the
same. talking about collective efficiency :)

ge

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