И даже программные бреки поддерживают не все чипы.
Например, мы в последней разработке используем PIC32MX250F128B. На удивление, ни ICD3 ни REAL ICE не даёт мне программных брекпоинтов, только 6 аппаратных. Хотя в даташите на этот чип написано - "Unlimited program and six complex data breakpoints"
Добрый день! Задачка - по единственной ножке передать 16 бит от одного девайса в другой.
На приемнике свободна только RB7. Соотв, прерывания по изменению уровня присутствуют.
Передачу закодил по мотивам функции write_byte 1wire. На листинге "осциллограмма".
Как видите, даже если передаются подряд несколько битов с одним значением, в начале каждого бита присутствует смена уровня.
Как бы лучше сделать - я думаю, ловить начало фронта по прерыванию на RB7, посредством TMR задержка на полбита, и анализ состояния на ножке?
Я специально так сделал, чтобы начало бита всегда можно было прерыванием ловить.
Вопрос - правильная ли стратегия ловить середину бита по прерыванию от таймера?
После того, как начало словлено по прерыванию от уровня?
Вопросец, долго думал куда с ним - наверное все-таки сюда. )
Если в ДШ написано, что питание в диапазоне 3-5.5В это вероятно, может оказаться далеким от истины?
Я вот наблюдаю, из нескольких мелких БП устройство на 16F628А заводится только на стабилизированном 5В. На прочих - сначала искажаются данные по UART, а потом - и генерация RESET OW отваливается. Это уже при напряжении под нагрузкой 4,2В.
Правдоподобно ли это, или чего-то недопонимаю?
Не допонимаете. Дело не в том, что показывает вольтметр, а что творится на питании ВО ВРЕМЕНИ. Вольтметр может показывать и 4,5 вольта, а на самом деле там присутствуют просечки ниже 2 вольт, но короткие по времени. Среднее значение напряжения питания при этом почти не изменится.
Так что приведите ПОЛНУЮ СХЕМУ.
Если конкретно по 628-му в битах конфигурации прописать BOD ENABLE, то да, он при снижении напряжения до 4в уходит в сброс и не работает. Но если его не прописывать - прекрасно работает и при 3в.
Да, спасибо... Правы были вы оба)
Отключил BOREN - перестала падать генерация RESET. Припаял по входу электролит - UART стабилизировался.
Позор мне... я с эйфории что хоть что-то начал понимать совсем про это забыл.
Доброго времени!
В целом с UARTOM разобрался, за исключением одной "мелочи".
Прием на ПИКе делается через прерывание, бит за битом, до интервала тишины.
Потом я смотрю количество принятых байт в блоке, и наличие в 5-м байте сигнатуры 0х55).
Наблюдается эффект - посылаю я эти 5 байт через переходник из винды и линукса, в первом случае через утилитку, во втором - функцией write(); компилятора GСС.
Так вот,чем больше я байт отправляю с компа, тем сложнее их полностью словить ПИКу. 2-3 байта - без проблем. 5 байт - еще нормально. 10-12 байт - через раз. На моем USB-TTL_UART переходнике стоит FT232, с кварцем 6МГц. Пик 16Ф628А на самотактировании 4МГц. Может быть проблема в этом? Что данные посылаются быстрее, чем их успевает обработать МК?
При чтении функцией read() - обратный эффект. Посыл в 10 байт от ПИКа считывается в 2-3 прохода, треть посыла в 1-м(остальное ноликами заполняется), и еще по трети в последующих. Приходится читать не блоком в 10 байт, а в цикле из 10 итераций по 1 байту, что есть извращение.
Из описанного, следует 2 вопроса:
1. Поможет ли установка внешнего кварца на ПИКе?
2. Передачу-прием от компа заданного числа байт производит непосредственно контроллер UART (FT232) по собственному тактированию, или интервал обработки следующего байта в блоке может быть скорректирован программно?
Т.е в идеале хотелось бы добиться согласованной работы приемника и передатчика - сколько передано за цикл - столько принято за цикл.
Какая у Вас установлена скорость по UART у FTDI?
Вы не даете никаких параметров обмена и от того возникает обоснованное предположение, что Вы их вообще никак не устанавливали...
Кварц у FT232 определяет обмен по USB (ну и заодно тактирует все остальное). И этот кварц в конце концов создает 48 МГц именно в USB, а скорость обмена по UART определяется настройками.
Принцип программного приема по UART в МК состоит в чтении пина "приемника" с УТРОЕННОЙ частотой по отношению к baudrate UART. Значит нужно выбрать такую скорость обмена, с которой МК справится на программном UART.
И последнее. А кто Вам сказал, что использовать мост USB-UART можно без линии UART Rx (то есть только в сторону МК)?
Почему выбран программный UART для подобной задачи, да еще и через только одну ногу МК?
Никто не делает одну единственную синхронизацию вначале, затем принимает все байты по таймеру. Нарваться на несовпадение скоростей будет 100%-ая вероятность.
Всё делается очень просто. Синхронизация идёт каждого байта по спаду старт-бита. В этом случае, достаточно чтения одного раза в середине каждого бита.
Скорость 19200.
На МК она выставлена как положено через SPBRG, аппаратно, задействован и Rx и Tx. Частота 4 мега. SBRG=12. Высокоскоростной порт.
Вероятно поэтому ) оно маслает уже более суток, исправно передавая-принимая все, что генерируется-посылается.
На ПИК с компа непрерывно посылается запрос, и если ничего интересного - ответ следует в 1 байт. Все это исправно работает.
Но, если запрос я делаю более 5 байт - чем больше - тем чаще его ПИК не воспринимает правильно.
Т.е по сути прикручена логика похоже как в modbus, только 485 еще не прикрутил.
А в ответ, допустим, ПИК передает (HEX) 01 02 03 04 05 06 07 08 09 АА
Если я читаю с FT одним read()-ом, то сначала читается
01 02 03 04 00 00 00 00 00 00
Следующим read-ом
05 06 07 00 00 00 00 00 00 00
И следующим
08 09 АА 00 00 00 00 00 00 00
Согласитесь, если бы скорость не соответствовала, вообще бы хрень прочиталась.
А вот в цикле 10 раз по 1 байту - все ОК, только времени существенно больше отнимает.
Так и маслает уже более суток. Надо будет отключить все проверки, и сделать эхо-сервер, посмотреть, что-же ПРИНИМАЕТ ПИК по факту?
Это чуть позже.
>>Никто не делает одну единственную синхронизацию вначале, затем принимает все байты по таймеру.
Это другой вопрос... Это я программно другой ногой дергаю. УАРТ аппаратный, и к баловству с прерываниями по смене уровна которую я описывал ранее отношения не имеет.
Если честно, то я не понимаю использование достаточно не дешевого FTDI для моста USB-UART да еще и с костылями виртуального COM.
Есть простой и надежный HID USB, который легко обеспечивает скорость обмена 64 байта за 1 мс (64000 байт/сек).
Мост строится на гораздо более дешевом PIC18F14K50 с совершенно произвольным обменом в стыке мост-МК.
Коннект по USB происходит АВТОМАТИЧЕСКИ и НА ЛЕТУ.
У меня все устройства работают с таким мостом. В любой момент выдернул из одного прибора и воткнул в другой. Софт даже не обнаруживает подмены. Просто продолжает работать после паузы на время переключения.
Что до FT, то он похоже действительно тормознутый несколько....если речь идет о времени доступа к дескриптору, после открытия порта. Однако сравнить не с чем пока, это просто ощущения.
А вот по приему-передаче - ИМХО налицо предположение, что FT отрабатывает быстрее ПИКа.
Дано:
На FT скорость 19200
На ПИКе
4МГц,SPBRG=12, BRGH=1;
В обработчике прерываний необходимое и достаточное количество инструкций, ничего лишнего.
Может ли в этих условиях ПИКу не хватать скорости?
На всякий случай оговорюсь, что по питанию выравнено хорошим электролитом, без него замер был 4,3В с кондером - 5,2.
Настоятельно рекомендую не заниматься ерундой, а взять контроллер с дебагом.
Тогда Вы элементарно узнаете успевает он или нет...
Кстати, питание у МК нужно СТАБИЛИЗИРОВАТЬ. С таким подходом как у Вас, Вы быстро сошлете микросхему в царство волшебного дыма...
