Author Topic: fnStartBreak  (Read 4171 times)

Offline hervé

  • Jr. Member
  • **
  • Posts: 98
    • View Profile
fnStartBreak
« on: October 19, 2011, 03:05:35 PM »
Hi Mark,

I wanted to use fnStartBreak
Unfortunatly there is no line code for this function, only calls to it.
Can you publish fnStartBreak and fnStopBreak source code?

BTW: How can I retrieve the chanel with tty QUEUE_HANDLE only ?
on fnStartBreak() I know it but not on fnStopBreak()...
Thanks
« Last Edit: October 19, 2011, 03:21:33 PM by hervé »

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3069
    • View Profile
    • uTasker
Re: fnStartBreak
« Reply #1 on: October 20, 2011, 12:59:25 AM »
Hi Hervé

The break control is presently not in the NXP projects.
However it looks to be quite easy to do:
- fnStartBreak() needs to set UxLCR |= BREAK_CONTROL; (where x is the UART channel)

The code would probably be

extern void fnStartBreak(QUEUE_HANDLE Channel)
{
    LPC23XX_UART_CONTROL *uart_reg = fnSelectChannel(Channel);
    uart_reg->LCR |= BREAK_CONTROL;
}

extern void fnStopBreak(QUEUE_HANDLE Channel)
{
    LPC23XX_UART_CONTROL *uart_reg = fnSelectChannel(Channel);
    uart_reg->LCR &= ~BREAK_CONTROL;
}


I haven't tested this on the HW though (yet)!


The channel associated with a queue handle is:

que_ids[driver_id - 1].qHandle, where driver_id is the queue handle number

However it may be best to have a function in Driver.c which returns this value (with some checking in case it is called with the wrong handle).

Also it may be best to be able to be able to control the break state via the fnDriver(driver_id, x, y); routine, as the RTS line can be controlled.

I'll look into adding these functions for future versions but you can probably very easily do all controlling that you need using the details above.


Note that the UART driver offers a mode (BREAK_AFTER_TX) #define UART_BREAK_SUPPORT which automatically sets the transmit line to the break state when transmission of a 'message' completes. This is useful in certain protocols. The length of tiem that the state remains then needs to be controlled at the application layer.

Regards

Mark

Offline hervé

  • Jr. Member
  • **
  • Posts: 98
    • View Profile
Re: fnStartBreak
« Reply #2 on: October 20, 2011, 02:27:01 PM »
Hi Mark,

Thanks, it was no so difficult but I prefer not to write allready written code. Specially when doing the update.

The function works fine
I add as you said :
Code: [Select]
QUEUE_HANDLE fnGetQueueHandle(QUEUE_HANDLE DriverId) {
return (que_ids[DriverId - 1].qHandle);
}

I wanted to activate UART_BREAK_SUPPORT
but I got an error :  #136: struct "stTTYQue" has no field "ucDMA_mode"
on 
Code: [Select]
extern void fnSciRxMsg(QUEUE_HANDLE channel)                             // {11}

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3069
    • View Profile
    • uTasker
Re: fnStartBreak
« Reply #3 on: October 20, 2011, 03:15:55 PM »
Hi Hervé

It looks as though there is a part of DMA code in the break support (this is recognising the end of a reception frame due to a break condition) that is not conditional on the DMA operation (the NXP devices don't support DMA on their UARTs).

            if (rx_ctl->ucDMA_mode & UART_RX_DMA) {
                rx_ctl->tty_queue.put = ptrNextHalfBuffer;               // set to next half of buffer
                rx_ctl->msgchars = halfBufferLength;                     // reset for next message
            }
            else {
                rx_ctl->msgchars = 0;                                    // reset for next message
            }


If you set

#ifdef SERIAL_SUPPORT_DMA
            if (rx_ctl->ucDMA_mode & UART_RX_DMA) {
                rx_ctl->tty_queue.put = ptrNextHalfBuffer;               // set to next half of buffer
                rx_ctl->msgchars = halfBufferLength;                     // reset for next message
            }
            else {
                rx_ctl->msgchars = 0;                                    // reset for next message
            }
#else
            rx_ctl->msgchars = 0;                                    // reset for next message
#endif


it will solve this. Probably you are however not interested in the receive break support, so the routine extern void fnSciRxMsg(QUEUE_HANDLE channel) could be removed.
In this case I will need to look at maybe being able to activate rx and tx break operation independently for general use. Until now it has only been used in the Coldfire project where both were needed.

Regards

Mark
« Last Edit: October 20, 2011, 03:17:40 PM by mark »