Iskra Neo + ILI9486 TFT 8bit driver (решено)

Я ж еще 8-битные не прошел )))

Да эта студия не щевелится на нетбуке и даже не помещается на экран ))
Я make.bat сделал, франкейнштейн такой из Atmel Studio (либы и avr-gcc) и Arduino IDE (avrdude):

Код (Text):

"C:\Atmel\Studio\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-gcc.exe"  -x c -funsigned-char -funsigned-bitfields -DDEBUG  -I"C:\Atmel\Studio\7.0\Packs\atmel\ATmega_DFP\1.2.209\include"  -O3 -ffunction-sections -fdata-sections -fpack-struct -fshort-enums -g2 -Wall -mmcu=atmega32u4 -B "C:\Atmel\Studio\7.0\Packs\atmel\ATmega_DFP\1.2.209\gcc\dev\atmega32u4" -c -std=gnu99 -MD -MP -MF "main.d" -MT"main.d" -MT"main.o"   -o "main.o" "main.c"
"C:\Atmel\Studio\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-gcc.exe" -o main.elf  main.o   -Wl,-Map="main.map" -Wl,--start-group -Wl,-lm  -Wl,--end-group -Wl,--gc-sections -mmcu=atmega32u4 -B "C:\Atmel\Studio\7.0\Packs\atmel\ATmega_DFP\1.2.209\gcc\dev\atmega32u4"
"C:\Atmel\Studio\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-objcopy.exe" -O ihex -R .eeprom -R .fuse -R .lock -R .signature -R .user_signatures  "main.elf" "main.hex"
"C:\Atmel\Studio\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-objcopy.exe" -j .eeprom  --set-section-flags=.eeprom=alloc,load --change-section-lma .eeprom=0  --no-change-warnings -O ihex "main.elf" "main.eep" || exit 0
"C:\Atmel\Studio\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-objdump.exe" -h -S "main.elf" > "main.lss"
"C:\Atmel\Studio\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-objcopy.exe" -O srec -R .eeprom -R .fuse -R .lock -R .signature -R .user_signatures "main.elf" "main.srec"
"C:\Atmel\Studio\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-size.exe" "main.elf"

C:\Arduino\hardware\tools\avr\bin\avrdude.exe -F -v -pm32 -cstk500v1 -P\\.\COM4 -b19200 -D -Uflash:w:"main.hex":i -C"C:\Arduino\hardware\tools\avr\etc\avrdude.conf"
 

Нажал и все скомпилялось и... залилось... в теории, пока что.

Ща вот только с портом доразберусь и как начну! )

 

Главное в общем то, что мне не удалось заточить Arduino IDE так, что бы код получался более менее компактным или по крайней мере я знал, что там в итоге получилось.
Один и тот же исходник компилируется с -O3:
в Adruino IDE - 11272 байт
в Atmel Studio / avr-gcc (в том числе и из Adruino IDE с одинаковыми ключами) - 8720 байт
Понятия не имею, что там еще прилипает в Adruino IDE на целых 2.5кб (((

 

O2 самый праильный ключ

 

Загрузчик?

 

Не, под загрузчик там ровно 4096 байт как я понял. И он дописывается в конце mainboard.ino.with_bootloader.leonardo.hex, а начало у них в общем то одинаковое за небольшим исключением, понятно почему.

То есть тут в начале бинарного скетча абсолютно 100% точно лежат вектора и далее - мои 8x16_font.c и pallete.c ))

 

Ппц блин залил!!! ))
Скажу я вам ide этот ардуиновский - весьма коварный. Расковырял все, нашел все скрипты, катарину, avr109, все как в ide 1в1, прописал в строку avrdude и... «connecting to programmer» бесконечно долго.
Дело решилось синхронным нажатием на ресет и запуском батника. Пока только так )) я так понимаю надо как то послать сигнал ресета перед заливкой но как еще не понял.

 

А что за плата? 32u4? Там хитро устроено - иде со скорости 9600 переключается на 1200 - это заставляет микропрограмму обслуживания стека USB сбросить МК. Загрузчик же на этой плате подключается как HID устройство без открытия виртуального COM порта.

 

Именно она )) плата iskra neo от амперки, на 32u4. Про 1200 бод видел но не допер до такого па-де-де с ресетом )))
Не, виртуальный ком-порт есть, но он именно как hid работает, то есть отключил искру - ком порт пропал из системы )) а так он (сом4) у меня указан и через него льеться норм на 57600 бод.
Пока мысли как обресетить не появилось, скоростью порта на лету чот не умею я ((

 

Но ты можешь сбросить МК и потом залить прогу - загрузчик 8 сек ждёт. Есть ещё вариант с атмеловским FLIP - но в нем через пин HWB надо выходить в нормальный режим. Есть ещё загрузчик LUFA - там можно отказаться от этого пина, но я не разбирался. Мне ISP ближе как-то))

 

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

 

Конечно, есть. Я же про загрузчик пишу.

 

Внутренний осциллятор включён и фьюз ckdiv8 взведён. Возможно, bod включён.

 

Дошло ту дело до вычитки данных из GRAM и тут я застрял капитально. Если кто то делал - подскажите, где я ошибся?
Согласно даташиту драйвера, за вычитку отвечает команда 0x2eh.

Перед этим надо выставить координаты области экрана x,y,x1,y1 (типа активной области, с которой работаем, она выставляется прямо в экранных координатах)
Далее нужно вычитать dummy
И в общем читать из памяти, дергая RD ногой.

Именно так это и организовано в чьем-то драйвере:

Код (C++):

#define read8(dst) { RD_ACTIVE; DELAY7; dst = (PIND & DMASK) | (PINB & BMASK); RD_IDLE; }

где, собственно, RD_ACTIVE это в моем случае ноль на 7-й ноге порта А, а RD_IDLE - единица. Между ними вычитка (в моем случае только PORTB без маски) и макрос DELAY7 (который мне пока что не очень понятен):

Код (C++):

#define DELAY7        \
  asm volatile(       \
    "rjmp .+0" "\n\t" \
    "rjmp .+0" "\n\t" \
    "rjmp .+0" "\n\t" \
    "nop"      "\n"   \
    ::);
 

Собственно мой тестовый код (корявенький, но я уже как только не пробовал), который пытается вычитать область памяти 8х16 с координат x=16, y=0 и тут разместить вычитанные данные по координатам x=320, y=0:

Код (C++):

unsigned char block[255];
void ReadGRAM(){
    int a=255;            // счетчик байт

    Lcd_Write_Com(0x2e);        // засылка команды
    LCD_RS_HIGH();            // поднимаю после засылки команды
    LCD_CS_LOW();            // опускаем бит засылки команды
    Address_set(16,0,23,16);    // ставлю экранные координаты для вычитки
    LCD_RS_HIGH();            // поднимаю после установки экранных координат, так надо ))
    DDRB = 0;            // на всякий случай ноги в ноль на PORTB
    LCD_RD_LOW();            // вычитка dummy
    DELAY7;                // скопи-нный макрос (уже от безнадеги)
    LCD_RD_HIGH();            // поднимаю ногу
    while (a>0){             // тут цикл вычитки и набивки массива block[] вычитанными данными
        LCD_RD_LOW();
        DELAY7;
        block[a] = PINB;
        LCD_RD_HIGH();
        a--;
        LCD_RD_LOW();
        DELAY7;
        block[a] = PINB;
        LCD_RD_HIGH();
        a--;
        }
    LCD_CS_HIGH();            // поднимаем бит засылки команды

    DDRB = 255;            // порт В на запись
    Lcd_Write_Com(0x2c);         // дальше весь код полностью рабочий, рисует черный квадрат 8х16
    LCD_RS_HIGH();            // с задержками, что бы смотреть как что рисуется
    LCD_CS_LOW();
    Address_set(320,0,327,16);
    LCD_RS_HIGH();
    a=255;
    while (a>0){
        PORTB = block[a];
        PORTF &= ~(1<<6);
        PORTF |= (1<<6);
        a--;
        PORTB = block[a];
        PORTF &= ~(1<<6);
        PORTF |= (1<<6);
        a--;
        Delay(65000);
        }
    LCD_CS_HIGH();
}

 

Короче, либо я читать не могу вообще, либо там не читается в принципе ((( вычитал dummy, вычитал первый параметр с команды 0x04h и он ноль, хотя должен быть ManufacturerID

Справа черный квадрат - это должна была продублироваться буква s из слова Test (координаты 16,0) а там нули в итоге (0х0000h) в rgb565 понятное дело...

Экран врядли глючит, поменял на другой - такая же картина Малевича. Скорее глючу я, не верится, что китайцы разведя RD ногу на плате, вырезали ее программно из оборота )) Например если поубирать Delay(1) из процесса - квадрат становится зеленым. Если поставить значение 1000-3000 то можно нахвататься помех и получить разноцветную кашу.

И мыслей уже не осталось.

 

А нет, есть одна, но нужно экспертно ее оценить.
Смотрите, что надумалось:
1. у Atmega32u4 (Iskra Neo) на ноге 5в, эти 5в идут в экран по шине данных и шине управления.
2. в экране стоят две трехвольтовые микрухи LVC245A (на шину управления и на шину данных), что преобразуют 5в > 3.3в
3. это позволяет нормально писать в экран (заливать его данными по шине), так как 5в с микроконтроллера преобразуются LVC245A в нужные ему 3.3в и он прекрасно понимает и 1 и 0.
4. но попытка прочитать шину когда она с экрана получает только 3.3в (возможно и меньше)....
Возможно ли то, что микроконтроллер просто не может определить когда на шине 1 возникает? Поэтому я и читаю стабильно нули...
Сколько там на шине - я сегодня вечером измерю.

 

Нет. МК AVR нормально понимает уровни 3.3в при собственном питании в 5 вольт. Раздел CMOS уровней находится на уровне половины напряжения питания. У AVR на входе триггеры Шмитта, поэтому есть небольшой гистерезис в (около) 1 вольт. В даташите все графики присутствуют.

Только осциллографом.

 

Я вот тоже думаю, чего ему их не понимать, но вдруг там не 3.3 далеко? Пока что только такие мысли.

Правильно думаю, что при питании микроконтроллера в 5В я получу: 5В * 0.2 = 1В и далее 1В + 0.9В = 1.9В как порог единицы? И если с экрана в итоге приходит HIGH = 1.8В то единицы микроконтроллеру не видать как своих ушей ))

У меня мысль такая, вот ---там--- я ставлю задержку около 1-2 сек и пробую просто померить напругу на любой ноге шины данных (В) обычным мультиметром. Так как считаться должно 0xff и так раз 32 точно (два ряда по 8 точек, каждая по 2 байта) - возможно замечу.

Код (C++):

unsigned char block[255];
void ReadGRAM(){
    int a=255;
    Address_set(16,0,23,16);
    LCD_RS_HIGH();
    Lcd_Write_Com(0x2e);
    LCD_RS_HIGH();
    DDRB = 0;
    LCD_CS_LOW();

    LCD_RD_LOW();
    Delay(1);
    LCD_RD_HIGH();
    Delay(1);

    LCD_RD_LOW();
    Delay(1);
    LCD_RD_HIGH();
    Delay(1);

    while (a>0){
        LCD_RD_LOW();
        MegaDelay(); // ---------  вот тут -----------
        block[a] = PINB;
        LCD_RD_HIGH();
        Delay(1);
        a--;
        }
.... и прочая

Или не? Осциллографа у меня нет, к сожалению.

 

тогда только встроенным АЦП.

 

Если на выводе мк такое напряжение, а вы запрашиваете у него состояние, то он обязан ответить. Ответ может быть "1" или "0".
1.8 В попадает в зону гистерезиса и результат будет зависеть от последнего зафиксированного триггером значения.
Т.е. если был "0" (0.2В), а потом возникло 1.8 В, то читаться это будет как "0".
Если был "0" (0.2В), напряжение скакнуло до 2 В, а потом упало до 1.8 В, то мк должен сообщить, что у него "1", т.к. последнее зафиксированное значение было "1" при 2-ух В.

 

Там все проще к моему сожалению. На экране распаяны полудохлые микрухи

Вот эта зараза LVC245A отдает 0,07в на ноги шины. При этом исправно получает с другой стороны положенные 0,7-3,3в (low/high). То есть конкретно этот китайский экран в принципе не выставляет данные на шине и МК оттуда читать просто нечего. Поэтому у меня и нули читаются из видеопамяти. До микрухи все в порядке, после - нули. Разобрался на 100%. Мультиметр из детского мира рулит. Но мне не радостно ни разу.