Сергей Борщ

С точки зрения внешних устройств ножка настроенная на ввод ничем не отличается от ножки в третьем состоянии. Поэтому в третье состояние переводим сбрасывая бит в PxDIR, т.е. переводя ногу в режим ввода. PxSEL нужен совсем для другого - он подключает к ножке вместо PxDIR, PxOUT, PxIN соответсвующий периферийный модуль.

На ум пришло такое: float val; #pragma pack (push,1) typedef struct { float data; }packed_float_t; #pragma pack(pop) float = ((packed_float_t *)getAddr())->data; float = (*(packed_float_t *)getAddr()).data; но не проверял. Если попробуешь, сообщи результат.

А чего вы ожидали? он и записал в P1OUT байт из 7 нулей и одной единицы. Если вы хотели выставить только один бит, а остальные оставить как есть, то надо писать P1OUT |= BIT1. А если сбросить - P1OUT &= ~BIT1;

Точнее к полям структуры. Т.е. если через указатель на эту упакованную структуру будешь обращаться к ее полям, то обращение будет побайтовым. А корректность указателей на поля упакованной структуры никто не обещал. Та кчто ошибаешься.

Конечно, частота там определяется RC-генератором и отличается от индикатора к индикатору, но не настолько. 250...300КГц еще поверю, но 10 - нет. Я использую такие задержки: питание - 200 мс - команда 0x30 - 50 мс - команда 0x30 - 50 мс - команда 0x30 - 50 мс - команда 0x20 (использую 4 -битную шину) - 200 мкс Работает железно со всеми индикаторами которые попадались. а разве на 8-битной шине она не должна выглядеть как 0x30?

Если не затруднит, и мне: serzh ухо rrt точка lv

__arm __irq void IRQ_Handler(void) { void (*AT91C_AIC_IVR)(); AT91C_BASE_AIC->AT91C_AIC_EOICR = 0; } что-то вроде этого. Или же по адресу 0x18 в асмовом файле разместить LDR PC, AT91C_AIC_IVR и каждый обработчик оформлять как __arm __irq не забывая в конце каждого обработчика вставлять AT91C_BASE_AIC->AT91C_AIC_EOICR = 0;

Тоже вариант,а как насчет того чтобы вообще не думать про запас?Какой ,где и сколько его нужно. Ну совсем не думать - "это для слабых" :-) Один раз подумал, и дальше только из проекта в проект copy. Да ладно,кто же постоянно обновляет данные на ЖКИ,вопрос насколько быстрее они будут обновленны.А если хотите прерывание,пожалуста,ставим BUSY по INT имеем еще быстрее при той же разгрузке проца. Пользователь не заметит разницы между появлением текста через 5 или 50 мс после нажатия кнопки. Не думаю что это так актуально,если действительно нужна экономия ставим 4 линии или покупаем ЖКИ с И2Ц. Мои устройства с дисплеями скорее вспомогательные инструменты, поэтому в них ставится то, что есть в столе. При решении что ставить в массовое изделие конечно используются другие критерии - в том числе доступность, цена, габариты, технологичность, подсветка и море других. Что касается лишнего провода - я не считаю ускорение вывода хоть сколько-нибудь значимым аргументом в пользу лишнего провода, если можно малой кровью обойтись без него. 8-битный вариант я уже давно не рассматриваю. Это для систем у которых есть полноценная шина. Чесно сказать никогда и не думал про согласование ,у серии 1602 диапазон питания от 3 до 6.5в и минимальное напряжение логической 1 на вход составляет 2.2в. По крайней мере у меня с этим проблем небыло. Еще 3 года назад (когда эта проблема стояла у меня) у большинства индикаторов в даташитах напряжение питания было указано 4.5-5.5в. Раз ситуация изменилась, аргумент снимаю. лишний код для организации цикла задержки. на пике (по памяти, давно с ними не работаю) movlw delay movwf tmp loop decfsz tmp goto loop для переключения половины порта на ввод, ожидания и потом переключения на вывод код будет значительно больше. необходимось процессору вместо полезной работы тупо крутится в цикле задержки. Ладно, оба варианта реализуются через прерывание, аргумент снимаю. Да здесь можно согласится,зависит от задач,у меня правда было наоборот,когда переполз на графические ЖКИ быстро понял что к чему.Тот же код теперь применяю и для текстовых. Ну, с графическими совсем другое дело. Тут и спорить не буду. Хотя приходилось и на графический писать без чтения, правда символ позиционировался с точностью до 8 пикселей. Резюме остается прежним - оба решения имеют право на жизнь. Редкий случай консенсуса :-)

MSP430F13x, F14x, F15x, F16x, может что-то из F2xx

Итого: плюсы - не волнуют задержки - можно поставить с большим запасом и точно также забить на них - максимальная скорость - а нафига? Дисплей все равно не в состоянии отображать данные с такой скоростью, не говоря о пользователе который с такой скоростью воспринимать с дисплея не может. Если критичны простои процессора во время вывода - делаем буферизированный и в прерывании таймера выводим. минусы: - лишний провод чтение/запись - необходимо иметь 4 или 8 двунаправленных линий, что очень неудобно при согласовании индикатора с трехвольтовой схемой. - лишний код для чтения этого флага. - необходимось процессору вместо полезной работы тупо опрашивать этот флаг. В общем каждый решает для себя, я лично флаг читал только в первом проекте, схему которого делали до меня. С тех пор уже 11 лет обхожусь задержками и не испытываю никаких неудобств.

А разве в С есть operator new? Про Cray не знаю ничего кроме "Цыпленок Cray перебежит дорогу быстрее всех, но если перед стартом его не окунуть в жидкий азот, то на той стороне дороги он появится в уже зажаренном виде" :-) На другой платформе int 0 будет стандартно преобразован к принятому на той платформе битовому представлению указателя который никуда не указывает. По-моему так! (с) Винни-Пух.

А вот тут zltigo не прав. Цитирую Страуструпа: Так что ноль вполне законен и даже очень правилен. Кстати, IAR 4.30 после вызова new проверяет R0 на ноль и если не ноль вызывает конструктор. Глубже не копал, но интуитивно понял что new таки в случае неудачи возвращает ноль. Счас отловлю другие ошибки и попробую организовать нехватку памяти.

Не находит в библиотеке указанную функцию. Может, библиотеку какую-нито забыли подключить? Скорее требуется написать самописную функцию обработки ошибки выделения памати с именем abort.

Проверил. При оптимизации по размеру разница есть - 32/44 байта: вы твоем str+Buf_Adres вычисляется дважды внутри цикла, хотя +3 встроено в команду LDD: LDD Z+3. При оптимизации по скорости разница больше - 32 / 46 байт, хотя суммирование вынесено за цикл. И все равно остается сравнение с 64 в конце цикла. А если str передавать как параметр, да еще перед функцией __x поставить - мой вариант получается еще лучше - 26 байт, а твой так и остается в районе 40. (я делал только цикл). Выигрыш получился имеено за счет указателя и того, что в результате вычисления Buf_Address-=2 сам собой получается флаг Z который тут же можно использовать для проверки окончания. Тогда для улучшения наглядности рекомендую такой вариант: str += 3; do { data = str[Buf_Adres+1]; data <<= 8; data |= str[Buf_Adres]; или str += 3; do { data = str[Buf_Adres++]; data |= (uint16_t)str[Buf_Adres++] << 8; а еще лучше str += 3; do { data = *str++; data |= (uint16_t)*str++ << 8; Новичков надо сразу приучать писать оптимально. Раз str больше не нужен, нет смысла его хранить неизменным. Пусть указывает на текущий байт. Тогда одной командой LD Rn, X+ сразу делаем и загрузку и передвигаем указатель. Кстати, в последнем варианте цикл получился 30 байт независимо от оптимизации. На эту тему много копий поломали с dxp в личной переписке (каждый остался при своем). Я не нашел в имеюмщемся у меня стандарте (ISO/IEC 9899) описания размеров данных. На всех известных мне компиляторах unsigned short действительно 2 байта. Но мне больше нравится подход с использованием заголовочного файла stdint.h. Объявленые в нем типы uint8_t, uint16_t, int8_t и т.д. имеют один и тот же размер всегда и везде. Упустил из виду. Можете кратко сказать с чем его едят? подкоректирую - будет скоро готов. "Говорю одно, делаю третье, думаю второе". Имел в виду intrinsics.h. Можно указать, что функции работы с флешкой описаны в файле intrinsics.h, тогда код будет самодостаточен - не нужны левые flash.h. Пришли (в почту) файл flash.h, я посмотрю как его макросы заменить на функции из intrinsics.h.

Молодец! Первая ласточка в FAQ. "необходимо отредактировать файл lnkm8s.xcl" - лучше все же скопировать его в папку проекта и редактировать копию - а то потом остальные проекты (которые использовали lnkm8s.xcl) перестанут работать. Еще можно добавить в какой папке искать этот файл (\avr\config). -H1895 -h(CODE)1C00-1C25 /*Fill unused interrupt vector's with RETI */ Не нужно. Правильно написанная программа не должна влетать в ненужные вектора, а эту память можно использовать под код (загрузчик обычно стремится занять всю отведенную память и еще чуть-чуть:-) "Тогда файл будет браться из Workspace проекта" - из папки проекта (гдe лежит .ewp). В Workspace обычно куча проектов из разных папок. #include "inavr.h" #include "iom8.h" #include "stdio.h" #include "flash.h" 1) первые три файла надо указать в угловых скобках. 2) вместо #include "iom8.h" #include <ioavr.h> - тогда нужный ioxxx.h будет подставлятся автоматически исходя из настроек проекта и исчезнет warning35 при линковке многофайловых пректов. 3) flash.h - файл явно не из комплекта компилятора, поэтому надо упомянуть где его брать. цикл я бы сделал иначе: #include <intrinsics.h> #define PAGE_SIZE 64 void update_Page(uint8_t *str) { uint8_t Buf_Address = PAGE_SIZE; uint8_t *ptr = str + 3 + PAGE_SIZE; do { uint16_t data = (uint16_t)*--ptr << 8; data |= *--ptr; _SPM_FILLTEMP(Buf_Address, data); } while (Buf_Address-=2); } И по ошибкам: "критЕку", "возможностями среда IAR", "что адре байта" Buf_Adres -> Buf_Address, NumbePageWrite -> NumberPageWrite P.S. с pgmspace.h так и не разобрались? У меня получилось такое: (для AVR231): #include <intrinsics.h> static void spmWriteWord(unsigned char APPFLASH *addr, unsigned int data) {_SPM_FILLTEMP(addr, data);} static int spmReadWord(unsigned char APPFLASH *addr) { return *addr; } static void spmErasePage(unsigned char APPFLASH *addr) { _SPM_ERASE(addr); while(SPMCR & (1<<0)); } static void spmProgramPage(unsigned char APPFLASH *addr) { _SPM_PAGEWRITE(addr); while(SPMCR & (1<<0)); } static void spmEEWriteByte(unsigned int addr, unsigned char data) { __EEPUT(addr, data); } static void spmWriteLockBits(unsigned char data) { _SPM_LOCKBITS(data); while(SPMCR & (1<<0)); }

Лето... отпуск только через 2 недели. Совсем я плохой стал. char STR1[16]; char STR2[16]; sprintf(STR2, "%i", NUM); sprintf(STR1, "%i", NUM2); Не вижу тут ошибки... :-(

Различные "чудесатые чудеса" наблюдал при отсутствии цепочки на ноге PLLRC.

Аналогично. Кроме того заметил, что на странице форума в приветствии (там где "Добро пожаловать (ник), ваше последнее посещение чч:мм") не выводится ник. Также ника нет на личной панели управления (кажется раньше был) а в выпадающем меню слева в персональном меню стоит "Добро пожаловать" и в след. строке логин (а должен вроде как быть ник).

Если схема вроде _Sam_ или моей, т.е с побитным отключением передатчика, то симптомы очень похожи на отсутствие растяжек. Если обычная - скорее всего перепутаны входы данных и включения передатчика.

В данном случае все правильно. STR1 и STR2 - массивы из 16 элементов типа char. Поскольку массивов как таковых в С нет, то имя массива тождественно указателю на его первый элемент. Т.е. STR1, STR2 имеют тип char *. Поэтому запись char *ptr = STR1; вполне корректна. Она тождественна записи char *ptr = &STR1[0]; И с другой стороны в С массивы в функции передаются как указатель на первый элемент. Так что с какой стороны ни подойди - в этом месте ошибки нет. А если поменять их местами? Т.е. проблема в чем - вообще любой второй вызов функции глючит или именно преобразование отрицательного числа? Пока могу предположить налезание стеков друг на друга. sprintf требовал стека более 100 байт. Сколько точно - не помню :-( А! можно в .map посмотреть.

Замечание: Очень полезно при передаче 1 тоже включать передатчик, но на очень короткий промежуток времени (~50% бита на макс. скорости) для быстрой перезарядки емкости линии. Прилагаемая схема делает это и плюс давит эхо. Работает до 115200 без всяких настроек скорости и процессоров. Растяжки, конечно, обязательны.

СОМ порт в компьютере асинхронный по условию. В самом простом (и наиболее часто используемом варианте) подключение такое: 10 или 11 ногу MAX на TXD меги, соответственно 14 или 7 МАХ на RXD компа (2 ножка). 12 или 9 МАХ на RXD меги, 13 или 8 МАХ на TXD компа (3 ножка). GND компа (5 ножка) на землю платы. Прилагаю код под мегу-8, переставил в проекте кристалл на 32, компилятор не ругается. Прием/передача по прерываниям, буфера приема/передачи, в main() делает эхо. UART.zip

О! Может тут кто-нибудь скажет: 1) как заставить WinAVR не подлинковывать функции к которым никто не обращается? Бить исходный файл на десять (по файлу на функцию) и делать из них библиотеку не хочу - дурная работа и инкапсуляция страдает. 2) объявляю две функции (putstring, putstring_P) у одной аргумет - указатель на флеш, у второй - указатель на RAM. Еще не зная о тонкостях досупа к флеш в обоих написал putchar(*ptr++); и получил две функции с идентичным кодом (т.е. с LD вместо LPM во второй) _без_всяких_варнингов_. Это штатное поведение? Как же тогда отслеживать ошибки типа "забыл вытащить переменную через макрос"?

Так и спрашивать надо было не в этом подфоруме. WinAVR - совершенно другой компилятор. Читайте в папке \doc в описании avrlibc как оформляются прерывания в WinAVR. Раздел (если память не изменяет) interrupt.h

О какой эвалюшн-версии идет речь? В 30-дневной с сайта ИАР все библиотеки прилагаются.