Перейти к содержанию

    

jcxz

Свой
  • Публикаций

    5 462
  • Зарегистрирован

  • Посещение

Репутация

0 Обычный

Информация о jcxz

Контакты

  • ICQ
    311337544

Информация

  • Город
    Омск

Посетители профиля

13 585 просмотров профиля
  1. Предлагаю объявить конкурс на лучшее название. C призовым фондом! Моя заявка на конкурс: mirror
  2. Вроде и то и то должно работать. Хотя сам я чаще применяю DMB. ;) А при чём тут память? Разговор о записи в регистры IO. Как я понимаю любые буферы в МК на пути записываемых данных (если они есть) должны влиять на эти команды. Может и так, но сколько я разных МК перепробовал на Cortex-M - нигде с этим не сталкивался. Но про STM32 слышал, что люди сталкиваются. Подозреваю, что в других МК ядро может автоматом выполнять аналог одной из этих инструкций при выходе из прерывания (при переходе по адресу 0xFFFFFFXX), а в STM32 - нет.
  3. Значит написать надо примерно так: if (EXTI_GetITStatus(EXTI_Line0) != RESET) { EXTI_ClearITPendingBit(EXTI_Line0); __ISB(); /* Do your stuff when PD0 is changed */ /* Clear interrupt flag */ // Запуск таймера } Но таймаут всё равно нужен для стабильной работы.
  4. "Стандартная ISR" со стандартным багом :) : сбрасывать флаг прерывания нужно сразу поле его обнаружения, а не как у Вас - где-то в хвосте ISR. Писали уже не раз про этот фиче-баг в STM32. Или использовать ISB после сброса флага. А лучше - и то и другое (переместить в начало и добавить ISB). Подумайте сами почему. У Вас же не AVR всё-таки..... Ну да. Точно так же борятся с дребезгом контактов кнопок. Там тоже таймер как бы и не нужен. Ну если конечно Вас этот дребезг не устраивает. Значит можно упростить, обойдясь без прерывания по спаду, добавив только таймаут (как я писал выше) - "мёртвую зону".
  5. А после этого сброса выполняется какая-нить команда синхронизации: DSB или DMB или ISB? Если нет, то вполне возможно что входите Вы по несброшенному флагу, как заметил VladislavS. И обнаружить это легко зафиксировав времена входов по какому-нить таймеру. Вообще с такими временами (5 мс) сделано у Вас не совсем правильно. По идее делать нужно примерно так: 1) Изначально разрешаем прерывание по фронту; 2) в ISR по фронту, запрещаем прерывание по фронту, разрешаем по спаду; 3) в ISR по спаду, запрещаем прерывание по спаду, разрешаем прерывание по истечению некоторого таймаута по таймеру (время выберем такое, чтобы было заведомо меньше длительности высокого уровня сигнала, но больше времени дребезга); 4) в таймерном ISR запрещаем прерывание по таймеру, разрешаем по фронту (как в п.1); и далее - с пункта 2. Вот так должно работать надёжно. Если заранее известна длительность низкой фазы сигнала, то можно пп. 2 и 3 объединить, убрав прерывание по спаду и запустив сразу после фронта отсчёт таймаута по таймеру.
  6. Хех! Теперь чудит не IAR, а резистор! Что-то новенькое Впрочем - не ошибусь, если предположу, что проблема там же, где была и в случае с IAR-ом
  7. Тогда и "со стороны пина" тоже будет ~ 0.
  8. st8l051 Uart детектирование FE.

    Ну значит - продолжайте думать. Пока не поймёте почему надо: 1) сперва читать регистр статуса; 2) потом анализировать его состояние, и только уже после этого, по результатам этого анализа - 3) читать или не читать DR (согласно мануала на МК) - не сможете написать что-то действительно стабильно работающее без всяких неожиданностей. Все ответы "зачем и почему" есть в моих сообщениях и в мануале. А с 1997-го или с какого другого Вы там что-то пишете - здесь пальцы гнуть бессмысленно. Здесь каждый имеющий глаза и голову сможет сам оценить ваш "код"
  9. Почему при вставке в сообщение фрагмента кода, подсветка синтаксиса по умолчанию == HTML, а не си? И зачем там в списке куча всяких SQL, Ruby и прочего PHP, но при этом отсутствует Assembler? Здесь вроде форум о embedded-программировании, а не о сайто-строительстве....
  10. st8l051 Uart детектирование FE.

    Не надо гадать о том, о чём Вы понятия не имеете. Вот пример ISR UART.RX из одного моего проекта на STM8, может он хоть чему-то Вас научит? SECTION `.near.noinit`:DATA:REORDER:NOROOT(0) bufRx DS8 UART_RBUF_SIZE SECTION `.tiny.bss`:DATA:REORDER:NOROOT(0) uartSizRx DS8 1 rposRx DS8 1 wposRx DS8 1 SECTION `.near_func.text`:CODE:REORDER:NOROOT(0) CODE ISR IRQ_UART_RX RxISR: CLRW X LD A, L:UART_SR LD XL, A BCP A, #B5 JREQ pri_01 LD A, L:UART_DR EXG A, XL BCP A, #B1 | B2 | B3 JRNE pri_01 LD A, S:uartSizRx CP A, #UART_RBUF_SIZE JRNC pri_01 INC S:uartSizRx LD A, S:wposRx INC A AND A, #UART_RBUF_SIZE - 1 LD S:wposRx, A EXG A, XL LD (L:bufRx, X), A BSET S:work, #WF_UART pri_01: IRET "Только по приёму"? ;) Значит не читаете док - это Вы. Так как оно не "только по приёму", но и по разным ошибкам приёма. И с чего вы вообще решили, что флаг FE и флаг наличия данных RXNE должны выставляться одновременно, а не скажем "сперва RXNE", а потом FE? Или наоборот? И что по такому вашему колхозу на BREAK-е, будет только одно прерывание, а не 2 подряд? Где такое вычитали в доке? "Не работает" - у вас, а не у меня. У меня с UART STM8 вообще проблем не возникло - сразу UART заработал как было задумано. Но при этом почему-то Вы учите меня как его готовить. Как-то странно, не находите? Прежде чем начинать хамить на замечания, хотя-бы на минуту включите голову и подумайте - что будет если между volatile unsigned char srreg = USART1->SR; и следующей строчкой вашего "кода" в UART.RX придёт новый байт? Ну если всё так запущено, и за столько лет можете наплодить только такое.... тогда больше вопросов нет. Продолжайте в том же духе, флаг в руки.
  11. st8l051 Uart детектирование FE.

    Вы бы лучше поизучали все эти методы, которые тут перечислили. Потому что там описаны механизмы кадровой синхронизации. Проверенные грамотными людьми. Почитали и попытались понять. Прежде чем лепить свой колхоз. В Вашем "коде" кадровой синхронизации нет как таковой. Что будет если фоновый процесс не успеет обработать предыдущий кадр и придёт новый? Что будет если возникнет помеха на линии? Также подозреваю что ещё целая куча багов в реализации. А все эти стандартные методы лучше уже хотя бы отсутствием граблей на которые Вы уже наступили - они не зависят от аппаратной реализации UART в МК. Детектируется там FE или нет - будут работать всё равно. Изучите хотя-бы байт-стаффинг - реализованный прямыми руками он будет много оптимальнее и быстрее чем этот ваш код
  12. st8l051 Uart детектирование FE.

    С таким "кодом" любые чудеса возможны. Хотя-бы почитайте как работает UART и примеры работы с ним посмотрите. Из этого "кода" видно что Вы не понимаете как работает UART. Читать из DR нужно только после анализа содержимого SR и обнаружения там флага "наличие RX-данных". Но никак не так безусловно как у Вас. Подумайте почему. И зачем там эти volatile? И что находится в ClearRecv()? Подозреваю что там ещё один баг.
  13. Программирования LPC1788

    Какой программатор? Вы о чём?? Для прошивки LPC17xx никакие программаторы не нужны. Скачайте FlashMagic и прошивайте по UART. Написал же выше...