[ECOS] i2c questions

[ECOS] i2c questions

[Grant Edwards]

I'm trying to use the i2c (with a bit-banged driver).  I've run
into a couple glitches so far:

1) The "delay" that's specified appears to be just added on to
   the intrinsic overhead of a bit-banged driver.  Is this the
   Specifying a delay of 10,000ns on my platform results in an
   actual clock period of about 59,000ns.  The description of
   the delay parameter in the reference manual appears to
   assume that there is zero overhead involved in the driver.
   Is this the expected behavior?

2) There doesn't seem to be any way to determine when writing
   zero bytes of data with cyg_i2c_tx() whether the operation
   was successful or not, since it returns 0 for both cases.  I
   presume one should use the lower-level "transaction"
   routines for this case?

-- 
Grant Edwards                   grante             Yow!  Yow! I'm having a
                                  at               quadraphonic sensation
                               visi.com            of two winos alone in a
                                                   steel mill!


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Re: i2c questions

[Grant Edwards]

On 2007-02-18, Grant Edwards <grante@visi.com> wrote:

> 2) There doesn't seem to be any way to determine when writing
>    zero bytes of data with cyg_i2c_tx() whether the operation
>    was successful or not, since it returns 0 for both cases.  I
>    presume one should use the lower-level "transaction"
>    routines for this case?

That doesn't seem to work.  i2c_transaction_tx always seems to
write an extra byte.  If I tell it to send 1 byte, it sends 2.

How do I send a single byte on the i2c bus??

-- 
Grant Edwards                   grante             Yow!  .. the MYSTERIANS are
                                  at               in here with my CORDUROY
                               visi.com            SOAP DISH!!


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Re: i2c questions

[Grant Edwards]

On 2007-02-18, Grant Edwards <grante@visi.com> wrote:
> On 2007-02-18, Grant Edwards <grante@visi.com> wrote:
>
>> 2) There doesn't seem to be any way to determine when writing
>>    zero bytes of data with cyg_i2c_tx() whether the operation
>>    was successful or not, since it returns 0 for both cases.  I
>>    presume one should use the lower-level "transaction"
>>    routines for this case?
>
> That doesn't seem to work.  i2c_transaction_tx always seems to
> write an extra byte.  If I tell it to send 1 byte, it sends 2.

Apparently the "start" flag also causes an address byte to be
sent?

> How do I send a single byte on the i2c bus??

I found a work-around that allows me to send 2 bytes, so I've
got my part talking -- but it bugs me that there's always an
extra useless byte being sent.

It would be quite useful if one were able to dermine the
difference between success and failure when calling tx/rx
functions with a zero byte-count.

Why not return -1 on failure?  That way you can tell the
difference between failure and successfully reading or writing
0 bytes.

-- 
Grant Edwards                   grante             Yow!  That's a decision
                                  at               that can only be made
                               visi.com            between you & SY SPERLING!!


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] building and debugging

[Laurie Gellatly]

Hi All,
I've been using eclipse to develop my arm based system for some time.
The application runs multiple threads and I had been able to debug them
reasonably well (the program did not always flow the way I expected when
single stepping and sometimes local variables are not able to be displayed).
What I have now is that although the main thread seems to be able to be
debugged, the other threads have problems.
I can set a breakpoint in a thread and it will stop, but single stepping or
trying to display local variables etc no longer works.
I've tried various things to fix it including reducing the size of the app
(down to 300K), but without any luck.

Is this a GDB or Eclipse limit or have I had a configuration issue?

BTW the indexer has always complained that the #include s for the OS files
could not find yet C does find them.
Anyone suggest what might be wrong?

Thanks             ...Laurie :{)


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] building and debugging

[Andrew Lunn]

On Mon, Feb 19, 2007 at 06:22:56PM +1100, Laurie Gellatly wrote:
> Hi All,
> I've been using eclipse to develop my arm based system for some time.
> The application runs multiple threads and I had been able to debug them
> reasonably well (the program did not always flow the way I expected when
> single stepping and sometimes local variables are not able to be displayed).

Try disabling the optimizer, i.e. remove the -O2 flag. It will then
flow in a more logical, but less efficient way.

> What I have now is that although the main thread seems to be able to be
> debugged, the other threads have problems.
> I can set a breakpoint in a thread and it will stop, but single stepping or
> trying to display local variables etc no longer works.

Part of the problem is that gdb is not fully thread aware. It cannot
stop a thread context change at a time slice. It cannot stop a higher
priority thread taking over, it cannot stop a timer tick happening
etc. So when every you do a single step something else can take over
control from the current thread. What you can do is run the thread you
are trying to debug at a higher priority than anything else. That will
reduce the likelihood of it being preempted. However if you are
looking for a race condition this is not going to help you...

        Andrew

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

RE: [ECOS] building and debugging

[Laurie Gellatly]

Hi Carlos,
Just before you sent this message I found the problem.
Yes, you're right with the fix.
Appreciate your reply.

Thanks			...Laurie:{)

-----Original Message-----
From: Carlos Losada [mailto:itel9cl1@yahoo.com]
Sent: Wednesday, 21 February 2007 7:58 PM
To: Laurie Gellatly
Subject: Re: [ECOS] building and debugging


Laurie I had the same problem with the indexer until I
provided the path to ecos include directory directly.
Try the following:
Eclipse->Project->Properties
C/C++ Build->GCC C Compiler->Directories

Then type in the absolute path to the ecos include
directory.  For example:
C:\cygwin\home\carlos\...\ecos_install\include

Good Luck
Carlos

--- Laurie Gellatly <laurie.gellatly@netic.com> wrote:

> Hi All,
> I've been using eclipse to develop my arm based
> system for some time.
> The application runs multiple threads and I had been
> able to debug them
> reasonably well (the program did not always flow the
> way I expected when
> single stepping and sometimes local variables are
> not able to be displayed).
> What I have now is that although the main thread
> seems to be able to be
> debugged, the other threads have problems.
> I can set a breakpoint in a thread and it will stop,
> but single stepping or
> trying to display local variables etc no longer
> works.
> I've tried various things to fix it including
> reducing the size of the app
> (down to 300K), but without any luck.
>
> Is this a GDB or Eclipse limit or have I had a
> configuration issue?
>
> BTW the indexer has always complained that the
> #include s for the OS files
> could not find yet C does find them.
> Anyone suggest what might be wrong?
>
> Thanks             ...Laurie :{)
>
>
> --
> Before posting, please read the FAQ:
> http://ecos.sourceware.org/fom/ecos
> and search the list archive:
> http://ecos.sourceware.org/ml/ecos-discuss
>
>




____________________________________________________________________________
________
Don't pick lemons.
See all the new 2007 cars at Yahoo! Autos.
http://autos.yahoo.com/new_cars.html


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss