[let's see 0]

Не знаю, как там с lpc17 с CAN, но с UART-ом проблема не в прерываниях, а в некотором неудобстве работы с ним из-за отсутствия флага, показывающего что FIFO не до конца заполнено.

Это решается добавлением в программу пары десятков строк (ну может чуть больше).

 

 

Думаете у других производителей будет качественно лучше? Скажите тогда кто эти производители.

Кроме как у Phillips прерывания по фронту для флага стстус-регистра ни у кого не встречал.

Если приложению надо мютекс с обработчиком прерывания, прерывание по фронту ликвидирует возмоцность маскирования и требует более сложных и вязких методов. Мне в корне непонятна сама идея такого прерывания. Подчеркиваю, не внешнего, а именно для флага стстус-регистра. Проблему с FIFO я решил достаточно просто: обработчик из HAL, освободив FIFO перезагружает его до завершения сообщения, а если и оно завершено, находит следующее ожидающее своей очереди, а если и очередь пустая, то упираюсь в проблему как инициировать прерывание из приложения, которой бы не было если бы не прерывание по фронту...

[Артём__ 0]

Кроме как у Phillips прерывания по фронту для флага стстус-регистра ни у кого не встречал.

Возможно есть у кого-нибудь, кто сделал совместимый с 550 UART. А может и нет.

 

Мне в корне непонятна сама идея такого прерывания. Подчеркиваю, не внешнего, а именно для флага стстус-регистра.

Несколькими сообщениями выше было высказано предположение, что это ошибка, ставшая стандартом.

 

Проблему с FIFO я решил достаточно просто: обработчик из HAL, освободив FIFO перезагружает его до завершения сообщения, а если и оно завершено, находит следующее ожидающее своей очереди, а если и очередь пустая, то упираюсь в проблему как инициировать прерывание из приложения, которой бы не было если бы не прерывание по фронту...

Не буду утверждать ничего насчёт типа прерывания THRE, потому что нет под рукой платы с LPC - проверить не могу.

 

Алгоритм проверки простой:

InitUart();
    __disable_irq();
    LPC_UART->IER=0;
    LPC_UART->THR='1';
    Delay1s();
    LPC_UART->IER=(1<<LPC_UART_IER_THRE_EN);
    NVIC_EnableIRQ(UART_IRQn);
    __enable_irq();

THRE станет равным 1 когда буфер опустеет. Если прерывание не возникнет, значит оно по фронту.

 

Почему-то кажется что возникнет...В любом случае никто не мешает разрешать прерывание по THRE перед посылкой байта.

 

[let's see 0]

мне не нужен тест, я уже убедился. С CAN еще не убедился, но с большой уверенностью предполагаю. С прерываниями по фронту, прерывания маскировать нельзя вообще, а запрещать глобально очень дурная манера.

Изменено 21 октября, 2012 пользователем pitt

[Артём__ 0]

мне не нужен тест, я уже убедился

Мне нужен - я не убедился. :)

Спасибо, что указали мне на этот новый нюанс.

 

С CAN еще не убедился, но с большой уверенностью предполагаю.

CAN и UART, как мне кажется имеют очень мало общего между собой - бессмысленно обобщать.

 

С прерываниями по фронту, прерывания маскировать нельзя вообще,

Можно запрещать прерывания только UART-а.

 

а запрещать глобально очень дурная манера.

Или понижать его приоритет.

 

И мало ли ещё что можно придумать...

 

[let's see 0]

Мне нужен - я не убедился. :)

Спасибо, что указали мне на этот новый нюанс.

 

 

CAN и UART, как мне кажется имеют очень мало общего между собой - бессмысленно обобщать.

 

 

Можно запрещать прерывания только UART-а.

 

 

Или понижать его приоритет.

 

И мало ли ещё что можно придумать...

Общее между CAN и UART производитель и его концепт. Я работал с CAN IP для FPGA от Phillips и там столкнулся с их, простите, идиотским прерыванием по фронту...Когда сейчас тот же концепт от того же производителя в другом месте - это становится системой. Если доберусь(в смысле не переключимся на другой MCU) сообщу результат.

Запрещать все прерывания опасно: в RTOS могут вытеснить, чтобы не приходится включать критическую секцию и прочиее прочее прочее и все из-за непонятно чего... Обидно.

[Артём__ 0]

Общее между CAN и UART производитель и его концепт.

Производитель - NXP, да.

Но ядро от ARM, UART - чей-то стандарт (не от NXP).

 

Я работал с CAN IP для FPGA от Phillips и там столкнулся с их, простите, идиотским прерыванием по фронту...Когда сейчас тот же концепт от того же производителя в другом месте - это становится системой. Если доберусь(в смысле не переключимся на другой MCU) сообщу результат.

Не знаю, кокой процент прерываний у NXP от edge, какой от level... пишут, что есть и те и другие.

 

 

Запрещать все прерывания опасно:

 

Запрещайте не все прерывания, а только от UART (NVIC_DisableIRQ). Или скажите, что может не сработать?

 

 

[let's see 0]

Производитель - NXP, да.

Но ядро от ARM, UART - чей-то стандарт (не от NXP).

Не знаю, кокой процент прерываний у NXP от edge, какой от level... пишут, что есть и те и другие.

Запрещайте не все прерывания, а только от UART (NVIC_DisableIRQ). Или скажите, что может не сработать?

Ядро ядром, а периферия у всех своя и в этом главная разница. Я в данном конкретном случае про UART.

Я об'яснил почему запрещать прерывания в реальном времени очень плохо, даже если только UART: application task is preemptable, locking could cause priority inversion and as a result - data loss. Я в предыдущем посте писал по-русски, но видимо, непонятно.

[Артём__ 0]

Алгоритм проверки простой:

    InitUart();
    __disable_irq();
    LPC_UART->IER=0;
    LPC_UART->THR='1';
    Delay1s();
    LPC_UART->IER=(1<<LPC_UART_IER_THRE_EN);
    NVIC_EnableIRQ(UART_IRQn);
    __enable_irq();

Проверил - прерывание возникает сразу после __enable_irq.

[Артём__ 0]

Я об'яснил почему запрещать прерывания в реальном времени очень плохо, даже если только UART:

Да, в запрете прерываний ничего хорошего.

 

application task is preemptable, locking could cause priority inversion and as a result - data loss.

То есть ни FIFO, на DMA (у вас LPC17, кажется) не спасают?

А нельзя тогда не запрещать прерывания от UART?

 

 

[let's see 0]

Да, в запрете прерываний ничего хорошего.

То есть ни FIFO, на DMA (у вас LPC17, кажется) не спасают?

А нельзя тогда не запрещать прерывания от UART?

Артем, если хотите, я могу Вам по skype в выходные ответить. У меня все работает, но совершрнно непонятно зачем я должен прилагать столько услий из-за дурацкого фронта! Я под RTX и все что я делаю: запрещаю переключение контекста: это просто флаг, никаких прерываний не запрещаю, затем:

if (((LPC_UART->LSR & (1<<THRE))&&((LPC_UART->LSR & (1<<THRE))) {
  // тут файфо пустое и никаких прерыаний по пустому файфо не будет
  // посылаю первый байт нового сообщения 
}
else {
  // а тут инициировать нельзя: обработчик сам увидет, что надо посылать новое сообщение
}

Пояснение: обработчик по пустому файфо или заполняет его текущим сообщением, а если оно закончилось пытается взять следущее. Если его нет, то тогда код выше начнет посылать его когда оно появится.

А вот зачем я два раза подряд один и тот же регистр читаю - догадайтесь сами ;)

Изменено 22 октября, 2012 пользователем pitt

[Артём__ 0]

Артем, если хотите, я могу Вам по skype в выходные ответить.

Отвечайте. Если можно сюда или Личные сообщения.

 

У меня все работает, но совершрнно непонятно зачем я должен прилагать столько услий из-за дурацкого фронта!

А что остаётся делать - всегда находятся какие-нибудь недостатки...

 

Я под RTX и все что я делаю: запрещаю переключение контекста: это просто флаг, никаких прерываний не запрещаю, затем:

if (((LPC_UART->LSR & (1<<THRE))&&((LPC_UART->LSR & (1<<THRE))) {

// тут файфо пустое и никаких прерыаний по пустому файфо не будет

// посылаю первый байт нового сообщения

}

А вот зачем я два раза подряд один и тот же регистр читаю - догадайтесь сами ;)

Пока не понял зачем 2 раза читать...достаточно одного чтения. Или нет?

 

[let's see 0]

Отвечайте. Если можно сюда или Личные сообщения.

А что остаётся делать - всегда находятся какие-нибудь недостатки..

Пока не понял зачем 2 раза читать...достаточно одного чтения. Или нет?

Не люблю печатать, особенно по-русски...Лучше голосом, потому скайп

Обычно, есть причина, чтобы сделать так, а не иначе. Вот и пытаюсь ее отыскать, ну не от балды же так сделано!

Все имеет смысл, думайте, догадывайтесь, я не NXP, читаю 2 раза с умыслом, хотя приходится так делать именно из-за NXP :)