GenaSPB

Где живёте?

А в чём вопрос?

Напоролся на тоже самое при работе с RDX0154 (на том же контроллере).

Вот эта часть цитаты автор - я.

Ну на это не обращайте внимания... Типичный пример тяжело портируемой программы (привязка к тому, то биты в старшей тетраде байта находятся). Вот в ARM бывают порты 32-битные, представьте что шина индикатора припаяна к 19,20,21 и 22 битам... Да и на AVR, иногда индикатор можно захотеть на младштие биты развести... Вы лучше чем искать, прочитайте внимательно что я писал про проблемы инициализации. Никакой gav.ru не поможет - OLED появились совсем недавно, с этими проблемами (из-за значащих битов в команде переключения интерфейса) пока мало людей столкнулись.

Вам нужен только один файл HD44780.C А тут всё Вам понятно? Это указание на ещё одну ошибку у Вас.

Надо считать два ниббла и проверять в получившемся байте старший бит (можно игнорировать младший, но считать надо). ps: и зачем я Вам ссылку на проект давал? Хочется по граблям пройтись самому?

Мне хотелось универсальный код получить, чтобы и классические HD44780 работали и на OLED контроллере. Как мне кажется, получилось. Как будете тестировать, проверьте пожалуйста работоспособность при сбросе процессора без выключения питания индикатора. Вы просто так уверенно посоветовли, я подумал что уже проверили. И конечно, не сильно надеюсь, но если проверите - с перезапуском после незавершённых циклов обмена (один полубайт считан и один полубайт передан).

А даташит я не дочитал до конца... не подумал, что после уже одного приведённого примера инициализации дисплея (тоже, начинающегося с pwer-on) будет ещё один... альтернативный. Что делать, если дисплей уже включался, а процессор пересбросился? команда 0x00... интересно, что будет, если дисплей, находящийся в 4 битном режиме получает команду всю из нулей? Вроде недокументировано... POOL, Вам помог этот последний пункт даташита?

Вот тут http://www.cqham.ru/forum/showthread.php?t=9688 лежит проект, в котором я победил проблемы WEH02002. Файл HD44780.C НА мой взгляд, проблема вот в чём: При подключени по 4-м битам надо обеспечить корректное переключение в 4 бита и после включения питания (легко) и после ресета процессора (делается трюком из трёх команд, которые переводят в 8 бит, потом обратно в 4). Так вот - этот трюк с WEH* (с его контроллером) не проходит, так как в ранее игнорировавшихся битах младшего байта команды теперь другая информация. Как я с этим разобрался - смотрите в исходник. Коротко - по 4-х битному интерфейсу устанавливаю позицию курсора, а потом считываю её (ненулевая и с разными старшим/младшим нибблами). Если считалось - индикатор в 4-х битном режиме и ничего делать не надо. Если не считалось - инициализируем. Правда, есть ещё состояния, когда процессор сбросили в момент чтения первого из двух нибблов статуса - но это я не проверял (да и иделаьнее решить ключём в питании индикатора). Или перейти на SPI интерфейс - с WEH это можно сделать. http://www.cqham.ru/forum/showthread.php?t=18954

Скорость 3 МГц. Блоки по (примерно) 3.5 килобайта, загруженность канала где-то на 75%. При использовании VCP блоки иногда приходят битыми (внутренний контроль обнаруживал). Какая-то зависимость от загрузки компютера (без разницы, windows7 или xp). После редактирования программы для использования функций D2, проблемы исчезли. Использовался асинхронный режим обмена и через WinAPI и через D2.

Кст Вы описали массив указателей на int8_t, инициализируя их целыми числами. Компилятор ругнулся по поводу инициализации десяток раз (или сколько у Вас там инициализаторов), а Вы и не заметили... Причём, в первых двух выкладываниях текста программы было всё нормально а в последнем (там где дизассемблерный листинг с кусочками исходного текста) эта ошибка уже внесена. Естественно, при перескоке через байт всё заработало.

А это было вообще "шедевр" //Cnt1=pgm_read_byte(&(a[p])); // варианте 2 Вы хоть немного читайте диагностику компилятора. А то на asm ("r17"); Вас хватило, а на адресную арифметику нет... В приведённом тексте ++p будет через пропускать каждый второй элемент массива a.

А немного пофантазируем... Скорее всего, человек написал const char PROGMEM * str = "1234"; и надеется на что-то... ВОТ ТАК ДЕЛАТЬ НЕНАДО. тут Ни одного байта из СЕМИ занятых не попадёт по FLASH.

Может, поможет: void uc1601s_put_str_P(const char * str) { char c; uc1601s_put_char_begin(); while((c = pgm_read_byte(str ++)) != '\0') uc1601s_put_char(c); uc1601s_put_char_end(); }

Готовый проект возмите - там в файле hardware.c начиная с функции adc_initialize().

izerg, укажите пожалуйста на паралельную тему. По названию индикатора найти тему не смог...

Украинская "Гамма" продаёт RDX0154 (TIC154A).

Исходник функции на "С" покажите - подскажем.

По SPI устроит? GCC.

Точнее - там, все-таки использовалась контрольная сумма ВСЕЙ программы. Ошибки при использовании контрольной суммы как средства контроля данных я сам видел - в малоизвестном устройстве венгерского производства VT-20 с использованием 2.5 МБ дисков при 256-байтных блоках так же были сбои. Сбоев 16-битного CRC на флоппи-дисках, лентах, каналах передачи данных я не встречал.

Попробуйте то же самое на yagarto - есть подозрение, что проблема в "демке", а не в компиляторе.

'Koizumi', насчёт осцилограмм. у Вас по 8-битному интерфейсу обмен идёт или по 4-х?

lto отвалилось, но это не особо важно... Спасибо. Без него работает. arm-kgp-eabi-gcc ../crt_sam7s.o ../cp15_asm.o ../bandfilters.o ../board.o ../sequen.o ../encoder.o ../hardware.o ../hd44780.o ../dis play.o ../keyboard.o ../keymaps.o ../nvram.o ../spifuncs.o ../formats.o ../synthcalcs.o ../uc1601s_small.o ../uc1601s_font.o ../uc16 01s_font_alt.o ../uc1601s.o ../twi.o ../tc1.o -mcpu=arm7tdmi -flto -Os -nostartfiles -T../sam7x64_rom.ld -Wl,-Map=tc1_rom.map,--cref ,--no-warn-mismatch -lm -o tc1_rom.elf lto1.exe: internal compiler error: compressed stream: data error Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. lto-wrapper: arm-kgp-eabi-gcc returned 1 exit status c:/kgp_arm_eabi/bin/../lib/gcc/arm-kgp-eabi/4.6.2/../../../../arm-kgp-eabi/bin/ld.exe: lto-wrapper failed collect2: ld returned 1 exit status make.EXE: *** [tc1_rom.elf] Error 1

Попробуйте перед программировнием считать состояние фюзов с новой микросхемы и не трогать SPIEN. Проанализируйте увиденное. Ещё возможно, какой-то конфликт с rs-232, сигнал с которого приходит на те же выводы, что и программатор. Он может быть отключён, но MAX232 об этом не знает... Снизьте скорость работы программатора.