Спасибо всем за участие, попробую ответить, может натолкнет на что-то еще.
to
Dog PawlowaЦитата
В детали ... , но прерывание по передаче мне не нравится. Мне кажется, что должен быть запрет прерывания, если весь буфер передан. Может быть, мега передает больше буфера? (Проверить можно осциллографом или терминалкой)
Проверял терминалкой, в порт уходит нужное число байт.
Цитата
... - или память затирается (проверить, поставив останов в конце передачи), или индекс и длина массива портится во время передачи (проверить аналогично).
Смотрел, все остается как было, ничего не портится.
to
Александр КуличокЦитата
У Вас постоянно осуществляется передача по Uart1TXint(). Одновременно с этим после выставлении флага FrameReady1 в Uart1RXint() осуществляется вызов PrepareRespone1(), который тоже что-то пишет в UDR1 (функции readhr1() и sethr1() ).
Передача по TXint (по опустошению ВСЕХ регистров, участвующих в передаче) осуществляется столько раз сколько записано в UDR, т.е. после записи последнего байта, прерывание вызовется последний раз, и поскольку больше обращения к UDR не было, то и прерывание больше не возникнет. В readhr1 и sethr1 осуществляется первая запись в UDR которая и вызывает первое прерывание Uart1TXint().
to
LaksusЦитата
Хотя я бы для отправки байтов использовал прерывание UDRE,
а TXC для отключения передатчика, но, по моему, должно работать и так.
Ноги такой работы с уартом растут из моего опыта работы с 51. Хотя изначально в Меге я использовал прерывание по UDRE, мне не понравилось. что надо разрешать/запрещать прерывания и я "ушел" на TXC. Мне лично оно кажется более логичным.
Цитата
А не результат ли это работы АЦП? Типа какой-нибудь шум, наводки.
Пробовал, не помогает.
Цитата
И еще, а Вы пробовали делать ресет. А потом посылать запросы.
То есть, отличаются ли первые, вторые и тд ответы после сброса,
или только первый от второго, второй от третьего (после сброса)?
Мысль интересная,попробую проверить.
Цитата
Общий совет - надо упрощать пока не пропадет ошибка.
Если Вы, автор, не разберетесь, то постороннему тем-более трудно.
В общем то, расчет был на то что кто-нибудь сталкивался с подобным.
Цитата
но, по моему, так красивше...
99: tmp= ADC;/// А нормальный компилятор должен знать порядок чтения байт
Дело в том что ImageCraft трудно отнести к нормальным компиляторам :-), но за неимением гербовой...
А эту структуру они сами настоятельно рекомендуют использовать.
Цитата
И еще, в unsigned int crc16(void *ptr,unsigned int n) return ((crcl<<8)|crch);
может надо так? return ((crch<<8)|crcl);
В модбасе сначала идет младший байт срс, а потом старший.
Цитата
Совершенно мне не ясно, что получим в результате
sum[adc]=sum[adc]-(sum[adc]>>8)+tmp;
но это тоже навряд ли повлияет.
Не помню как это правильно называется, навскидку вспоминается "экспоненциальное слаживание" и "скользящее среднее". В данном случае получается усреднение по 256 выборкам (почти среднее, математики оспорят, но меня устраивает).
Еще раз хочу обратить внимание, что на все запросы чтения ответ идет правильный, и на отдельные запросы записи тоже. Битые ответы, идут на строго фиксированные запросы, т.е. на 511 - все ок, на 512 - битый. и еще на некоторые другие запросы (78, 1101).
проблема с уарт Mega64, атипичная проблема с передачей по UART
Jun 4 2007, 06:45
