1. В setup написал #asm("cli") // запретить прерывания
2. eracing() нафиг
3. temp заменил через #define 0x80
4. Приведение типа убрал.
Объявление мссива забыл написать, покуда это только половина программы была, причем вторая и внизу. Первую занимает дисплей. Управление им осуществлятся через программный spi, никакие регистры там не затрагиваются. Сам массив:
char bt_word[176]={0};
5. Попытался записать только одну константу...

И не хочу показаться занудой или неудачником, но 255 на экрачике в рядок.

Парни... кажится до меня доперло... У меня на памяти на ноже WP +5 Вольт... Случаем это не защита от записи?
Ответ на вопрос выше, отпаял я этот вывод - не помогло... Ну что за хрень

Сообщение отредактировал lomtev - Sep 25 2007, 17:57

Да, WP это вход защиты от записи, но только активный уровень у этого сигнала низкий.
Не настаиваю, а просто предлагаю посмотреть мою библиотеку для работы с AT45, написанную когда-то для MSP430. Писал для одного проекта, который заглох и эти исходники мне не пригодились. Исходники минимально тестировались. Дважды уже давал ее нуждающимся, но к сожалению никакой обратной реакции хотя бы на уровне "работает / не работает / глючит / фуфло полное" не получил Может хотя бы вы попробуете и как-то выскажетесь?

Предложенный исходник, написан явно не для Codevision а с другими компиляторами разбираться все равно что с нуля учиться. Так что врядли я скажу вам о правильности вашей прошивки...
Так вот еще забавно. Как я понял резет должен быть высоко а он у меня низко. Надо будет припаять их (WP тоже) к VCCи взглянуть что получиться.

Сообщение отредактировал lomtev - Sep 25 2007, 18:39

Вообще-то библа написана под ANSI C и компилировать ее что в IAR, что в CodeVision, что в GCC без разницы. Если вас смутили мои типы данных, то они в хидере _xOS_LOC.h задаются. Единственно, что #pragma pack может какому-то компилятору не понравиться, но четыре строки подправить не большой труд. Эх, опять сорвалось тестирование! Ну да ладно. Хозяин - барин.

ТАк парни, кажись пошло г**вно по трубам, перепаял резет на VCC и стало выводить какой-то мусор... хрен знает что это, но всяко прогресс...

А какой проц? пока почему-то думал, что мега16.

Всё парни.... всё заработало, по крайней мере первый байт пишится правильно. а там дело за адресацией и все. Что хочу подытожить.
Не работало правильно по двум причинам.
Первая - Не знаю почему на нужную ножку с резетом не выводилась единица, перепаял ее на VCC и по счастливой случайности у меня плата не была подключена к шнуру програматора и на экран вывелся мусор. Позже я подключил программатор и стал искать ошибку, но при запуске у меня снова вывелись 255, я допер что оказывается причина была совсем не там где мы ее искали.
Вторая - Не знаю почему но программатор (Обычный пяти проводковый через LPT) соединяет вместе SO или SI и SCK. таким образом когда процессор ждал в SPDR значения сдвигового регистра он получал клон сигнала с SCK и выдавал 0xFF. Стебно. Правда я мозг.
Всем вам И спасибо за помощь. Надеюсь эта темка поможет таким же лузерам как я. Упорство и проработка любых возможных ошибок, пусть даже самых нелепых - это залог успеха в достижении поставленной задачи. До связи.


мега32-16ua

Держите микроконтроллер в ресете когда его шьете внешним программатором. Его ноги будут в третьем состоянии и не будут мешать программированию.

Программатор все же лучше сделать покруче, например поставить таки туда буфер НС244, хотя и с буферизированным программатором у меня были проблемы. проблемы такого плана, что в один "прекрасный" момент он чуть-чуть поддох таким образом что при подаче питания на схему и программатор, последний садил сигнал SO, так было до первого прошивания контроллера, далее все работало нормально. Правда это мешало только на этапе отладки когда прграмматор держится постоянно подключенным в схему

Фишка не в самом программаторе, а в компе, если программатор отключить от LPT то клона сигнала нет. Но буфер это хорошо не спорю, но причина выяснена так что можно ее избегать простым отключением разъема. Да еще и времени нет, и так от графика отстаю. Но всем, огромное спасибо за внимание.

Заметил странную штуку. Была проблема что у меня на дисплей выводилось следующее (всего пять символов)
0_ *01_*02_*03_*04

* - помечано символ который я не кодировал (никакой просто белеберда 8*12 pix), как там вылазил бред понять не могу поскольку на вывод чисел у меня стоит фильтр и ничего кроме записаных в кодировке символов высти нельзя в принципе... а однако можно...
_ - на дисплее это пробел... просто пустая ячейка цвета фона.

Так вот, бред такой выводился при следующим цикле записи

char k=0;

for(k=0;k<5;k++){
flash_write(k);
}

Я морщил репу, один байт в виде функции flash_write(77); в любую ячейку буфера пишится отлично, а цикл не хочет. Перепахал все битовые сдвиги адрессации бита в буфере. ноль эмоций. Решил сделать так

for(k=0; k<5; k++){
if(k==0) flash_write(77);
if(k==1) flash_write(69)
if(k==2) flash_write(18);
if(k==3) flash_write(13);
if(k==4) flash_write(54);
}

И странно но факт, он вывел все в виде

77_69_18_13_54

В общем, как надо. В чем причина? Почему в функцию правильно передается только константа, а не переменная?

Сообщение отредактировал lomtev - Sep 26 2007, 19:50

А unsigned char k не пробовал?

Попробовал. Не помогло. Согласен что скорее всего все дело в переменной k, но как она нарушила довольно жесткий цикл пересчета:

void math_screen(unsigned char eds,unsigned char new_znach)
{
unsigned char i=0;
unsigned char mas_eds[4]={10,10,10,10};

if(eds>=100) mas_eds[0]=0; //Если число больше или равно сотни, то там явно будет число и надо убрать пробел
if(eds>=10) mas_eds[1]=0; //Если число больше или равно десяти, то там явно будет число и надо убрать пробел
if(eds!=0) mas_eds[2]=0; //Если число больше не равно нулю, то там явно будет число и надо убрать пробел
if(eds==0) mas_eds[2]=0;

for(i=0; i<eds; i++) //Разбиение числа на единицы, десятки и сотни
{
mas_eds[2]++;
if(mas_eds[2]==10){mas_eds[2]=0; mas_eds[1]++;}
if(mas_eds[1]==10){mas_eds[1]=0; mas_eds[0]++;}
}

for(i=0; i<4; i++) put_char (new_znach+i*8,60, mas_eds[i]);
}

Вызывается мат_скрин циклом:

unsigned char g=0;

for(g=0; g<5; g++)
{
math_screen(bt_word[g], 10+g*32);
}

Сам массив bt_word:

unsigned char bt_word[176]={0};

Дальше идет, сравнение с кодировкой символов, причем только цифр и пробела - но это уже не важно. Башню ему сносит где-то на пересчете. Что он пишет в mas_eds[0] что выводит казилябры, число должно быть больше десяти, но как в char можно запихнуть значение больше тысячи, лишнее должно было бы срезаться. Надеюсь вам понятно, а то без пива явно не разобраться.

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

Я иногда дивлюсь своему аналитическому уму Добавил в функцию пересчета строчку
if(mas_eds[0]>=11) mas_eds[0]=6;
Если значение отвечающее за сотни перевалит за значение превышающее число символом в таблице кодировок, то в него запишется значение равное 6. И мне вывелось на экран следующее.

__0_601_602_603_604 (Хочу заметить что нули здесь лишнии за исклчением первого)

_ - пробел
Будем думать почему пишится число больше тысячи и все это упихивается в переменную char. Не int, я не совсем дурак
Вот такая муть

Сообщение отредактировал lomtev - Sep 27 2007, 18:20

eds == 0xFF для

плачевно, если не int i
Дальше не разбирал. Подход к делению через сложение ниасилил