cyg_drv_dsr_lock usage

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view

cyg_drv_dsr_lock usage

Michael Bergandi
Hi all,

I have recently written an eCos I2C driver for a Freescale mx27
processor. The driver is working. However, I have some questions
whether what I have done is the right way or if I have used some calls
incorrectly. cyg_drv_drs_lock and unlock are of particular interest. I
referenced the existing i2c_mcf52xx and i2c_lpc2xxx drivers as I was
developing mine.

The driver is pretty simple. It is probably most closely modeled after
the lpc2xxx driver in that I do most of my work in the ISR, which is
pretty minimal. Using a single byte TX as an example should give the
idea. The cyg_i2c_tx call is received by the driver with the usual
parameters. I2C module is setup and enabled with interrupts. The slave
address is shifted with the read/write bit set. Send the start signal.
Send the slave address. I2C module interrupts. In the ISR, if the
address was acked, I send the data byte, exit ISR. Get the next
interrupt from the ISR. Set the completion flag, signal the DSR to
notify the driver the transaction is finished.

After the transaction was kicked off by sending the address, the
driver then waits for the transaction to finish in this call:

static void wait_for_xfer_completion(cyg_mxc_i2c_extra_t *extra)
        /* lock the driver and dsr and wait for the transfer to complete */
    while (!(extra->i2c_flag & (I2C_FLAG_XFER_COMPLETE | I2C_FLAG_ERROR))) {

My questions are:
Does anyone see any problems with this?
Is the DSR lock really necessary?
Should this be ordered differently?

One more note that may affect responses. This driver is used to handle
both I2C buses with multiple devices on each bus.

Thank you for any information you can provide.

Reply | Threaded
Open this post in threaded view

Re: cyg_drv_dsr_lock usage

Michael Bergandi

Reply | Threaded
Open this post in threaded view

Re: cyg_drv_dsr_lock usage

Sergei Gavrikov-4
On Thu, 6 Oct 2011, Michael Bergandi wrote:

> Anyone?

[story entirely]

That's what I+Google found. There was one expert explanation by the
topic in the ecos-discuss list

It seems to me that in some cases you would get more help (=hands)
through the eCos discuss list and ... search engines :-)

Thus, I found/saw no issues with in the posted snippet of the code.