Сергей Борщ

Присоединюсь к предыдущим коллегам: Сделайте простой проект который просто читает одно измерение из АЦП и приложите к сообщению. С картами в руках и разговор будет более предметный. Да и в процессе выкидывания всего лишнего велика вероятность обнаружить "ту самую" ошибку.

Слишком умный компилятор :-) Выкинул все лишнее нафиг. Ни одна из этих переменных в проекте не используется, значит не нужна. Дает совсем другой результат. Или на крайний случай (не используется, но очень надо иметь в выходном файле): __root __eeprom char ST[] = "TEST EEPTOM"; __root __eeprom char eee = 245; Нет, до момента когда это содержимое eeprom хоть на что-нибудь сгодится.

Есть подозрение, что к проекту подключен какой-то из стандартных .xcl файлов, который имеет мало общего с LPC2103. Поэтому код слинковался в несуществующие адреса. Глянь в .map, если это действительно так - надо к проекту подключить правильный .xcl, например, из папки examples.

Я тоже долго перечитывал и задавал этот вопрос на сахаре. Пришли к выводу что они просто сделали copy-paste с документации на макрофункцию для ПЛИС.

Получается. Только надо кроме адресов и размера их еще в желаемое окно запихать - секция [sfrGroupInfo] в конце файла. Я дописал, но сегодня болею а они на работе. Если до завтра терпит, выложу.

А вот чтобы ответ обратно в комп передать эти +-10 (точнее, больше чем +-3) и нужны.

Чтение AIC_IVR (не важно, программой или через JTAG отладчиком) заставляет AIC выполнять некоторые действия. Чтобы этого не происходило, надо в .ddf - файле исключить AIC_IVR из списка регистров, показываемых в окне AIC.

Это очень хорошо и правильно. Приложите весь код одним файлом, гляну.

Не знаю, пользовался оригиналом. Стоит поискать на www.gaw.ru Еще может быть полезным маленький FAQ: http://faqs.org.ru/electron/embint.htm#I1

Выходит удивительная штука этот VMLab. Ибо в даташитах нет ограничения на максимальное значение задержек.

Говорят, "у дураков мысли сходятся" :-) Однако продолжение почему-то забывают: "но у умных - чаще!" Вроде у Страуструпа читал, что если уж используешь явное преобразование указателей - сам смотри. Ведь в зависимости от контекста этот код может быть как абсолютно правильным (если этот char * в прошлой жизни был float *) и тогда предупреждения компилятора будут мешать или неправильным как в твоем случае. Видимо, придется просто запомнить, что в подобных случаях могут быть грабли.

А, дошло. звездочка - это любое число! Привык просто, что обычно в датахшитах Х в таких слуучаях пишут. Да, про 38 согласен. На все остальные команды использую задержку 40 мкс, сдвиг экрана не использую и команду очистки дисплея (которая 1.6мс по даташиту) тоже. Посчитал, что выставить курсор в начала строк и забить строки пробелами быстрее и проще чем городить специальную задержку. "Достаточно одной таблэтки". Для перевода в 4-битный режим 3 раза по 3х и один раз 2х, для перевода в 8-битный режим - 3 раза 3х. Когда-то писал на телесистемах о 4-битном, для 8-битного отбросить команду d. Повторю здесь: Обозначим эти команды как a, b, c, d Допустим, дисплей был в 8-битном режиме. Тогда: команда a - не влияет на работу, он и так в 8-битном режиме команда b - то же самое команда c - то же самое команда d - воспринимается как 8-битная команда и переводит в 4-битный режим. Допустим, дисплей был в 4-битном режиме и ждал команду. Тогда: команда a - воспринимается как старшая тетрада команды перевода в 8-битный режим команда b - воспринимается как младшая тетрада команды перевода в 8-битный режим, дисплей переходит в 8-битный режим команда c - не влияет на работу, он и так в 8-битном режиме команда d - воспринимается как 8-битная команда и переводит в 4-битный режим. Теперь допустим, дисплей был в 4-битном режиме и уже получил первую тетраду команды когда проц сбросили. Тогда: команда a - воспринимается как младшая тетрада предыдущей команды. Да и фиг с ней, все равно инитим дисплей. команда b - воспринимается как старшая тетрада команды перевода в 8-битный режим команда c - воспринимается как младшая тетрада команды перевода в 8-битный режим, дисплей переходит в 8-битный режим команда d - воспринимается как 8-битная команда и переводит в 4-битный режим. P.S. нашел то сообщение на телесистемах. Гы, я его и там тебе в ответ писал :-))))) http://www.telesys.ru/wwwboards/mcontrol/7...ges/66090.shtml

С точки зрения внешних устройств ножка настроенная на ввод ничем не отличается от ножки в третьем состоянии. Поэтому в третье состояние переводим сбрасывая бит в 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.