Сергей Борщ

Угу. Действительно. В моем проекте, где используется DBGU тоже стоит AT91C_AIC_SRCTYPE_INT_HIGH_LEVEL. Внесу изменения в примеры ОСи. Спасибо! Интересно, кто-нибудь знает, зачем я там делал EDGE? P.S. гляньте вот сюда: ветка на сахаре. Обнаружился баг в TEeventFlag, там идет обсуждение путей его ликвидации.

KiCAD совершенно бесплатный. AutoTrax EDA и DipTrace недорогие (из того, что знаю). Погуглив на тему "free pcb cad" можно найти много разных программ.

Честно скажу, я такую панель не "щупал". Но, насколько знаю по аналогам, FGND - просто отдельный проводник, подключенный к металлической рамке дисплея. Его соединение с GND является вполне логичным решением для защиты от статики и наводок. Его соединение с минусом питания непосредственно на источнике питания (а не в дисплее на GND) применяется в условиях сильных помех. И уж точно при правильном поключении конденсатор между этим проводом и питанием не должен никак влиять на работоспоспособность в настольных условиях. Копайте свою схему - упомянутые вами в посте №7 наводки амплитудой 2в - что-то из области либо фантастики либо какой-то чудовищной ошибки в схеме либо монтаже. Вы можете прикинуть, какие токи у вас гуляют, если пульсации такой амплитуды гасятся конденсатором 470мкф, но при этом не компенсируются стабилизатором питания. Какое же тогда сопротивление у вас имеют провода питания к индикатору? Или может стабилизатор сдох. В любом случае что-то ненормальное, и дисплей на 99% не виноват.

Обычно принято хотя бы вкратце описывать - в чем была причина. Даже если она была из серии "сам дурак". Чтобы человек, наступивший на такие же грабли, имел вариант решения, а не открывал тему заново.

Ой, как-то эта ветка выпала из моего внимания. Ув. klen! Я не гоню на ваш любимый компилятор. Я же еще в первом посте написал, что поиск в гугле ничего не дал. Я пересмотрел документацию к GCC - там нет ни слова об этих предопределенных символах. Я специально только что задал поиск по папкам, где установлен Yagarto: THUMBEL найден в двух файлах - cc1.exe и cc1plus.exe В файлах документации он не упоминается Я понимаю, что когда вы копаетесь в исходниках gcc, все эти символы для вас как на ладони, но у меня нет возможности вникать еще и в компиляторостроение. Поэтому, собственно и был вопрос. А за полный и конкретный ответ огромное спасибо! Ничего себе то же самое! Это же гораздо удобнее. Похоже, моя ошибка была в том, что я вызывал arm-elf-gcc, а не arm-elf-cpp

Поставьте между входом и выходом данных резистор - он ограничит ток кз. Пример можно посмотреть в даташите на FT232B. И еще один резистор на землю - чтобы превратить третье состояние в фиксированное. Выше вы пишете, что будете использовать АТ45, у нее тоже будете замыкать вход с выходом? Если все же вход и выход будут раздельные - поставьте между ними резистор. Он позволит определить третье состояние на выходе по наличию "эха".

Видимо, дельфи и С по-разному толкуют символ '\' в текстовых строках. В С он используется для задания спецсимволов, поэтому чтобы он попал в скомпилированный код его надо в исходнике написать дважды.

Вы утверждали, что это "Эта фишка (и не только) уже самого компилятора зарытая". Т.е. снова, как и в начале ветки, во всем виноват компилятор а не ваше невежество. Книга по С бывает одна: Керниган и Ритчи, "Язык программирования С". Второе (!) издание. Все остальные - ее толкования. Книга есть в интернете. Где искать - не подскажу, гугля в помощь.

Глюка в системе нет. Просто имя порта для CreateFile надо указывать правильно. Вот: http://support.microsoft.com/kb/115831

Докажите. Можно от противного - достаточно доказать, что битовые поля не упоминаются в стандарте языка С.

sprintf(comPortName, "\\\\.\\COM%d", comPortNumber); или в вашем случае PChar('\\\\.\\COM'+inttostr(PortNumber)),

Глянул на диаграму чтения 25P1024. Она начинает выдавать данные после посылки трех байтов адреса. Логично предположить, что 512 начинает выдавать после двух. До этого выход данных находится в третьем состоянии. Это нельзя как-то использовать?

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

Ну так недостающий пробел легко восполнить. Открываем Google, набираем ISO/IEC 9899-1999, скачиваем, открываем, search, >=, находим:

Это твой GNU gcc-frendly проект был, или в комплекте шел? Если твой - выложишь? Надо с чего-то начинать когда-нибудь, а то пока все доку читаю.

WinAVR\DOC\gcc, WinAVR\DOC\binutils\ld.html\index.html#Top, WinAVR\DOC\avr-libc\avr-libc-user-manual\index.html, WinAVR\DOC\avr-libc\avr-libc-user-manual\FAQ.html http://translate.google.com/translate_t?langpair=en|ru?

Ну раз работает - значит хорошо. Вы находитесь на стадии, когда использование чужих библиотек ускоряет процесс разработки. Когда вы упретесь в нехватку памяти или скорости - перейдете на следующий уровень, когда библиотеки пишутся под себя с минимумом универсальности и максимумом эффективности. Ну тогда берите исходник библиотеки и выкидывайте из него все лишнее. Я, например, так и не понял зачем у вас в прерываниях таймера вызов функций по указателю. Вы собираетесь подменять обработчики "на лету"? Все обработчики? А голова у кого? ;)

Ну это не совсем так и компилятор точно следует стандарту: Т.е. "ноль" и "не ноль" отностится не к результату, а к операндам. Поэтому первое отличие: для A=1 и B=2 A&B=0, A&&B=1. Второе - для && операнды вычисляются слева направо и если правый операнд равен нулю, то уже сразу известно, что и результат будет равен нулю, поэтому второй операнд вычисляться не будет.

Ой. Извиняюсь. Давайте смотреть .map вместе: .text 0x00000000 0x6a2 <- Итого во флеш попадает 1698 байт. .vectors 0x00000000 0x26<- Вектора. Ненаказуемо. Заняты все. .progmem.data 0x00000026 0x88 lcd.o <- 136 байт констант. Судя по следующей строке - знакогенератор 0x00000026 LcdCustomChar .text.main 0x000000e6 0x40 123.o <- собственно main(), 64 байта -------- дальше идут функции дисплея, которые вызываются из main или прерываний ------- .text.lcdInitHW 0x00000126 0x1a lcd.o .text.lcdBusyWait 0x00000140 0x5c lcd.o .text.lcdControlWrite 0x0000019c 0x64 lcd.o .text.lcdControlRead 0x00000200 0x4e lcd.o .text.lcdDataWrite 0x0000024e 0x64 lcd.o .text.lcdGotoXY 0x000002b2 0x1a lcd.o .text.lcdLoadCustomChar 0x000002cc 0x52 lcd.o .text.lcdPrintData 0x0000031e 0x2a lcd.o .text.lcdInit 0x00000348 0x6e lcd.o ---------------------- итого 656 байт ----------------- а дальше ваши прерывания для таймера - 5 раз по 0x5A байт (450 байт) .text.__vector_8 0x0000045e 0x5a timer.o .text.__vector_6 0x00000538 0x5a timer.o .text.__vector_7 0x00000592 0x5a timer.o .text.__vector_5 0x000005ec 0x5a timer.o .text.__vector_3 0x00000646 0x5a timer.o и пара по 166 + 128 байт .text.__vector_9 0x000003b8 0xa6 timer.o .text.__vector_4 0x000004b8 0x80 timer.o Мелкие секции я опустил. По имени секции в первой колонке вы можете узнать имя функции, по адресам из второй колонки можно в листинге найти получившийся код. Зря вы решили читать флаг BUSY. Без него код получается значительно меньше.

Я тоже получил массу удовольствия от этого объяснения. Позвольте реабилитироваться и внести свой вклад: #define i2c_read(ack) i2c_read_func( (ack) ? (1<<TWINT)|(1<<TWEN)|(1<<TWEA) : (1<<TWINT)|(1<<TWEN) ) // --------i2c.c---------------- unsigned char i2c_read_func(uint8_t control) { TWCR = control; while(!(TWCR & (1<<TWINT))); return TWDR; } Кажется так может быть эффективнее. А может и нет. Надо смотреть листинг.

Ничто не мешает ему представить себе это число как знаковое и после CMP.B #0x0, R13 проверять флаг N. Скорее всего он так и делает дальше. Теперь докажите, что TST.B R13 - неправильный код. Чтобы понять причину такого решения - сравните длину и время команд BIT и CMP

Во-первых посмотрите листинг. 99%, что тело вашей задержки выкинуто оптимизатором. Объявите параметр ms как volatile или перепишите внутренний цикл так: while ( ms-- ) __no_operation(); (это если иар, если WinAVR - while ( ms-- ) __asm__ __volatile__ ("nop" : : ); во-вторых "переход в 4 битный режим, повтор" - лишнее.

Не из семейства GCC, но тоже под GPL - SDCC Брать не релиз (который 2.7.0) - в нем нет библиотек для PIC18Fxxx, а snapshot (в нем еще и некоторые ошибки поправлены). Еще потребуются gputils, искать на sourceforge.net

Восстановим справедливость - это aesok сказал. Я лишь пытался объяснить механизм "не работы". Вы предлагаете Атмелу менять дизайн кристалла (с возможным внесением ошибок или просто небольшим изменением параметров), перестраивать процесс на новую топологию и прочее? А ради чего? Чтобы один раз облегчить жизнь невнимательным читателям даташитов? Ведь второй раз на эти грабли вменяемый разработчик не наступит. Я при освоении нового кристалла просматриваю список всех фузов, анализирую, какое состояние каждого мне необходимо, и после этого поведение кристалла становится предсказуемым.

Проконсультировался с ReAl - в С функция не может иметь атрибута volatile, это я с плюсами попутал: Так что тут вы правы - компилятор не может заменить два i2c_read() или NegPort() на один. Признаю, вводил в заблуждение. Это заставило вновь внимательно посмотреть листинг из поста №7 - и что мы видим? Мы не видим там одного вызова i2c_read() - мы видим, что вызов(ы) i2c_read() происходят в подпрограмме ?Subroutine0, содержимое которой нам не показали. Видимо подобная конструкция используется в файле не один раз и компилятор посчитал оптимальным вынести ее в отдельную подпрограмму. Ставлю себе большую двойку за невнимательность. Так что вопрос - ошибся тут компилятор или нет остается открытым до обнародования листинга ?Subroutine0