beginer

Ничего не получилось. :( Контоллер на плате перепаяли, да не правильно (задели дорожки). Теперь новый ATmega128 на плате греется как печка. Где-то наверно к.з. Будем разбираться. Вообще по поводу TWI на ATmega. Потестили 4 контроллера ATmega8 на предмет реализации TWI (там ничего не перепаивали, только контроллеры в сокетах меняли). Так вот, только 2 из них оказались полностью рабочими (у одного вообще не работали порты, у другого - TWI). Такая вот нехорошая статистика. Так что при реализации подобных вещей нужно учитывать ещё и весьма высокую вероятность нерабочего контроллера.

Сергей Борщ Вообще, честно говоря, я программированием микроконтроллеров не занимаюсь. Моя роль в данном проекте - всего лишь написать программу для ПК, которая бы общалась с микроконтроллером посредством интерфейса RS-232. А программированием контроллера занимается другой человек. Однако все вопросы, что я здесь задаю - с его слов. Он хороший специалист, отлично разбирается в схемотехнике. Я не думаю, что он мог бы перепутать линии SCL и SDA. К тому же мы вместе проверяли - в нуле после передачи постоянно остается только SCL, а SDA - в высоком уровне. defunct Не знаю, вроде бы старт и стоп как раз формируются. С остальным - проблемы. Хотя тут есть ещё кое-что. Сегодня звонили в саппорт фирмы, в которой покупали плату AS-megaM (плата на основе того самого ATmega128 с распаянной на плате периферией, типа COM-порта, кнопками и т. п.). Так вот в саппорте сказали что по описанию похоже, что проблема в убитом блоке контроллера, отвечающем за реализацию TWI. Похоже что столкнулись с бракованным контроллером. В общем теперь думаем брать ещё контроллер (на этот раз без платы), выпаивать из платы старый, и сажать на неё новый. В пользу теории о бракованном контроллере говорит также то, что на ATmega8 при реализации связи с микросхемой 24C16 наши программы заработали (только порт D сменили на С). В общем в понедельник ещё попробуем поработать с этим контроллером (обещал подойти ещё один специалист), если не выйдет, то будем пробовать новый. Если кому интересно, могу попозже здесь написать как же всё-таки разрешилась данная ситуация.

Dopler Попробовали Ваши подпрограммы. В результате инициализация проходит, старт и стоп - работают. При передаче адреса данных и приёме данных код регистра TWSR равен 0x84. Пробовали с двумя различными микросхемами (чтобы исключить вероятнсть неисправности ведомой микросхемы) - AD7745 и 24C16 (микросхема памяти). При просмотре состояния линий после передачи линия SCL оказывается в низком уровне. С подтягивающими резисторами всё в норме (используем по 5 кОм). Никак не пойму где же всё-таки ошибка. Особо интересует, откуда берётся код 0x84?

Dopler Спасибо, завтра поковыряем Ваши подпрограммы. IgorKossak Не хочу быть злостным правонарушителем, но никак не найду кнопку "Правка", чтобы отредактировать своё сообщение. Ещё не подскажите, почему я не вижу половины сообщений в данной теме, когда захожу на форум на работе? Может это из-за использования прокси-сервера? Дома захожу без прокси - всё отлично.

Контроль корректности выполнения операций сейчас не используется. Устал с ним воевать. Имеется ввиду проверка состояния бита Т. P.S. Извините, что так тормозно отвечаю. Инет на работе глючит по-страшному. code.zip

Код инициализации: LDI R16,0x1C ; Коэфф.деления TWBR при f=7,3728 МГц STS TWBR,R16 ; LDI R16,0b00000100 ; Разрешить работу интерфейса Прерывания не используются, работаем по опросу флага TWINT.

Уважаемые! Кто реализовывал работу интерфейса I2C на ATmega128 помогите советом. Никак не могу понять в чем у меня ошибка. Суть проблемы: Не инициализируется аппаратный TWI. Возвращает коды состояния отличные от указанной в документации. Иногда появляются коды с арбитражем. Пробовал всевозможные установки порта D. Наверно здесь есть какая-нибудь особенность. Подскажите пожалуйста кто знает.

О, спасибо! Попозже будем разбираться капитально с этим компонентом. А сейчас надо попробовать API-функции "добить"...

function TCommPortDriver.SendDataEx( DataPtr: pchar; DataSize, Timeout: DWORD ): DWORD; Да, похоже это действительно какраз то, что мне надо. Только не могли бы Вы написать (если я Вам ещё ненадоел своими распросами) что именно нужно указывать в качестве параметра DataPtr: pchar? Ну а за пример использования данной функции (с передачей в буфер именно числа), моей благодарности не будет конца.

Я понял о чём Вы говорите. Можно было бы передавать числа ввиде символов, коды которых равны этим числам. Была такая идея. Отказался. Нерационально, имхо. К тому же возникла проблема с передачей символа, код которого равен нулю. P. S. chr(0) не возвращает никакого символа.

Kolia А если мне надо передать число 201? Это же 1 байт. А если я его преобразую в hex, то передавать придётся 2 байта (символ 'С' и символ '9'). Так что это немного не то (у меня число байт в пакете установлено строго и я не могу передать пакет с большим или меньшим числом байт). Всем Хотя я уже вроде понял как через WinAPI-функции передавать числа в СОМ-порт, но всё-таки, может у кого есть исходник программы с этим компонентом, где данные в порт передаются непосредственно ввиде чисел (а не ввиде символов). Был бы вам весьма признателен.

А кто-нибудь знает как с помощью этого компонента можно передать в СОМ-порт не символ, а число в двоичной форме? Т. е. если у меня в edit'e записано 11001111, то могу ли я передать это число ввиде одного байта? Или передавать только как 8 байт (т. е. каждый бит как символ)?