| |
 LPC_UART (550-совместимый) |
|
|
|
|
 Oct 21 2012, 20:46
|
Местный
Группа: Участник
Сообщений: 328
Регистрация: 1-06-06
Из: USA
Пользователь №: 17 672
|
Цитата(_Артём_ @ Oct 21 2012, 14:31)  Не знаю, как там с lpc17 с CAN, но с UART-ом проблема не в прерываниях, а в некотором неудобстве работы с ним из-за отсутствия флага, показывающего что FIFO не до конца заполнено.
Это решается добавлением в программу пары десятков строк (ну может чуть больше).
Думаете у других производителей будет качественно лучше? Скажите тогда кто эти производители. Кроме как у Phillips прерывания по фронту для флага стстус-регистра ни у кого не встречал. Если приложению надо мютекс с обработчиком прерывания, прерывание по фронту ликвидирует возмоцность маскирования и требует более сложных и вязких методов. Мне в корне непонятна сама идея такого прерывания. Подчеркиваю, не внешнего, а именно для флага стстус-регистра. Проблему с FIFO я решил достаточно просто: обработчик из HAL, освободив FIFO перезагружает его до завершения сообщения, а если и оно завершено, находит следующее ожидающее своей очереди, а если и очередь пустая, то упираюсь в проблему как инициировать прерывание из приложения, которой бы не было если бы не прерывание по фронту...
--------------------
|
|
|
|
|
|
|
|
Oct 21 2012, 21:21
|
Гуру
Группа: Свой
Сообщений: 2 128
Регистрация: 21-05-06
Пользователь №: 17 322
|
Цитата(pitt @ Oct 21 2012, 23:46) Кроме как у Phillips прерывания по фронту для флага стстус-регистра ни у кого не встречал. Возможно есть у кого-нибудь, кто сделал совместимый с 550 UART. А может и нет. Цитата(pitt @ Oct 21 2012, 23:46) Мне в корне непонятна сама идея такого прерывания. Подчеркиваю, не внешнего, а именно для флага стстус-регистра. Несколькими сообщениями выше было высказано предположение, что это ошибка, ставшая стандартом. Цитата(pitt @ Oct 21 2012, 23:46) Проблему с 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 перед посылкой байта.
|
|
|
|
|
|
|
|
Oct 21 2012, 21:57
|
Гуру
Группа: Свой
Сообщений: 2 128
Регистрация: 21-05-06
Пользователь №: 17 322
|
Цитата(pitt @ Oct 22 2012, 00:27) мне не нужен тест, я уже убедился Мне нужен - я не убедился.  Спасибо, что указали мне на этот новый нюанс. Цитата(pitt @ Oct 22 2012, 00:27) С CAN еще не убедился, но с большой уверенностью предполагаю. CAN и UART, как мне кажется имеют очень мало общего между собой - бессмысленно обобщать. Цитата(pitt @ Oct 22 2012, 00:27) С прерываниями по фронту, прерывания маскировать нельзя вообще, Можно запрещать прерывания только UART-а. Цитата(pitt @ Oct 22 2012, 00:27) а запрещать глобально очень дурная манера. Или понижать его приоритет. И мало ли ещё что можно придумать...
|
|
|
|
|
|
|
|
Oct 21 2012, 22:35
|
Местный
Группа: Участник
Сообщений: 328
Регистрация: 1-06-06
Из: USA
Пользователь №: 17 672
|
Цитата(_Артём_ @ Oct 21 2012, 17:57) Мне нужен - я не убедился. Спасибо, что указали мне на этот новый нюанс. CAN и UART, как мне кажется имеют очень мало общего между собой - бессмысленно обобщать. Можно запрещать прерывания только UART-а. Или понижать его приоритет. И мало ли ещё что можно придумать... Общее между CAN и UART производитель и его концепт. Я работал с CAN IP для FPGA от Phillips и там столкнулся с их, простите, идиотским прерыванием по фронту...Когда сейчас тот же концепт от того же производителя в другом месте - это становится системой. Если доберусь(в смысле не переключимся на другой MCU) сообщу результат. Запрещать все прерывания опасно: в RTOS могут вытеснить, чтобы не приходится включать критическую секцию и прочиее прочее прочее и все из-за непонятно чего... Обидно.
--------------------
|
|
|
|
|
|
|
|
Oct 21 2012, 23:12
|
Гуру
Группа: Свой
Сообщений: 2 128
Регистрация: 21-05-06
Пользователь №: 17 322
|
Цитата(pitt @ Oct 22 2012, 01:35) Общее между CAN и UART производитель и его концепт. Производитель - NXP, да. Но ядро от ARM, UART - чей-то стандарт (не от NXP). Цитата(pitt @ Oct 22 2012, 01:35) Я работал с CAN IP для FPGA от Phillips и там столкнулся с их, простите, идиотским прерыванием по фронту...Когда сейчас тот же концепт от того же производителя в другом месте - это становится системой. Если доберусь(в смысле не переключимся на другой MCU) сообщу результат. Не знаю, кокой процент прерываний у NXP от edge, какой от level... пишут, что есть и те и другие. Цитата(pitt @ Oct 22 2012, 01:35) Запрещать все прерывания опасно: Запрещайте не все прерывания, а только от UART (NVIC_DisableIRQ). Или скажите, что может не сработать?
|
|
|
|
|
|
|
|
Oct 21 2012, 23:24
|
Местный
Группа: Участник
Сообщений: 328
Регистрация: 1-06-06
Из: USA
Пользователь №: 17 672
|
Цитата(_Артём_ @ Oct 21 2012, 19:12) Производитель - 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. Я в предыдущем посте писал по-русски, но видимо, непонятно.
--------------------
|
|
|
|
|
|
|
|
Oct 22 2012, 23:06
|
Гуру
Группа: Свой
Сообщений: 2 128
Регистрация: 21-05-06
Пользователь №: 17 322
|
Цитата(pitt @ Oct 22 2012, 02:24) Я об'яснил почему запрещать прерывания в реальном времени очень плохо, даже если только UART: Да, в запрете прерываний ничего хорошего. Цитата(pitt @ Oct 22 2012, 02:24) application task is preemptable, locking could cause priority inversion and as a result - data loss. То есть ни FIFO, на DMA (у вас LPC17, кажется) не спасают? А нельзя тогда не запрещать прерывания от UART?
|
|
|
|
|
|
|
|
Oct 22 2012, 23:36
|
Местный
Группа: Участник
Сообщений: 328
Регистрация: 1-06-06
Из: USA
Пользователь №: 17 672
|
Цитата(_Артём_ @ Oct 22 2012, 19:06) Да, в запрете прерываний ничего хорошего.
То есть ни FIFO, на DMA (у вас LPC17, кажется) не спасают?
А нельзя тогда не запрещать прерывания от UART? Артем, если хотите, я могу Вам по skype в выходные ответить. У меня все работает, но совершрнно непонятно зачем я должен прилагать столько услий из-за дурацкого фронта! Я под RTX и все что я делаю: запрещаю переключение контекста: это просто флаг, никаких прерываний не запрещаю, затем: Код if (((LPC_UART->LSR & (1<<THRE))&&((LPC_UART->LSR & (1<<THRE))) {
// тут файфо пустое и никаких прерыаний по пустому файфо не будет
// посылаю первый байт нового сообщения
}
else {
// а тут инициировать нельзя: обработчик сам увидет, что надо посылать новое сообщение
} Пояснение: обработчик по пустому файфо или заполняет его текущим сообщением, а если оно закончилось пытается взять следущее. Если его нет, то тогда код выше начнет посылать его когда оно появится. А вот зачем я два раза подряд один и тот же регистр читаю - догадайтесь сами 
Сообщение отредактировал pitt - Oct 22 2012, 23:39
--------------------
|
|
|
|
|
|
|
|
Oct 23 2012, 12:25
|
Гуру
Группа: Свой
Сообщений: 2 128
Регистрация: 21-05-06
Пользователь №: 17 322
|
Цитата(pitt @ Oct 23 2012, 02:36) Артем, если хотите, я могу Вам по skype в выходные ответить. Отвечайте. Если можно сюда или Личные сообщения. Цитата(pitt @ Oct 23 2012, 02:36) У меня все работает, но совершрнно непонятно зачем я должен прилагать столько услий из-за дурацкого фронта! А что остаётся делать - всегда находятся какие-нибудь недостатки... Цитата(pitt @ Oct 23 2012, 02:36) Я под RTX и все что я делаю: запрещаю переключение контекста: это просто флаг, никаких прерываний не запрещаю, затем: [code]if (((LPC_UART->LSR & (1<<THRE))&&((LPC_UART->LSR & (1<<THRE))) { // тут файфо пустое и никаких прерыаний по пустому файфо не будет // посылаю первый байт нового сообщения } А вот зачем я два раза подряд один и тот же регистр читаю - догадайтесь сами Пока не понял зачем 2 раза читать...достаточно одного чтения. Или нет?
|
|
|
|
|
|
|
|
Oct 24 2012, 00:35
|
Местный
Группа: Участник
Сообщений: 328
Регистрация: 1-06-06
Из: USA
Пользователь №: 17 672
|
Цитата(_Артём_ @ Oct 23 2012, 08:25) Отвечайте. Если можно сюда или Личные сообщения.
А что остаётся делать - всегда находятся какие-нибудь недостатки..
Пока не понял зачем 2 раза читать...достаточно одного чтения. Или нет? Не люблю печатать, особенно по-русски...Лучше голосом, потому скайп Обычно, есть причина, чтобы сделать так, а не иначе. Вот и пытаюсь ее отыскать, ну не от балды же так сделано! Все имеет смысл, думайте, догадывайтесь, я не NXP, читаю 2 раза с умыслом, хотя приходится так делать именно из-за NXP
--------------------
|
|
|
|
|
|
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|
