repstosw

Ещё один момент: на отладочной плате A13-Olinuxino не установлена NAND-Flash микросхема, и перемычка (SMD) замкнута: NCE_NAND_E - это Chip Enable как я понимаю. Может процессор пытается с неё загрузиться и перемычку надо разомкнуть, чтоб с SD карты пошла загрузка? Если да, прийдётся скальпелем резать потому что перемычка замкнута печатным проводником, а не резистором

может быть проблема в этом: sudo dd if=bin/release.bin of=/dev/sdb bs=1024 seek=8 И почему bs=1024, когда сектор карты 512 байт? И что мне вместо sudo в винде использовать? Пока пишу дисковым редактором на 16-й сектор карты памяти. С uboot пока бесполезно, нету под рукой RS232 <=> UART Может всё-же проверяет карту и если там упоминание о винде(первые 2 сектора), то не грузится?

Здравствуйте! Начал осваивать Allwinner A13 и пока безуспешно. Использую отладочную плату "A13-olinuxino", загрузиться хочу с SD карты (4 ГБ класс скорости 4). Компилятор arm-none-eabi , исходник программы ниже, мигает светодиодом на порте G 9 (штатный порт на отладочной плате со светодиодом): #define uint32_t unsigned long int #define CCMBase 0x01C20000 //clock module #define Def_APB0_Gating CCMBase + 0x68 //#define Def_APB0_Gating 0x01C20068 #define GPIOBase 0x01C20800 #define GPIOIncrement 0x24 #define ALLWINNER_GPIO_A GPIOBase #define ALLWINNER_GPIO_B GPIOBase + (1*GPIOIncrement) #define ALLWINNER_GPIO_C GPIOBase + (2*GPIOIncrement) #define ALLWINNER_GPIO_D GPIOBase + (3*GPIOIncrement) #define ALLWINNER_GPIO_E GPIOBase + (4*GPIOIncrement) #define ALLWINNER_GPIO_F GPIOBase + (5*GPIOIncrement) #define ALLWINNER_GPIO_G GPIOBase + (6*GPIOIncrement) #define ALLWINNER_GPIO_H GPIOBase + (7*GPIOIncrement) #define ALLWINNER_GPIO_I GPIOBase + (8*GPIOIncrement) #define Port_CFG0 0x00 //pin direction and function 0 to 7 #define Port_CFG1 0x04 //pin direction and function 8 to 15 #define Port_CFG2 0x08 //pin direction and function 16 to 24 #define Port_CFG3 0x0C //pin direction and function 25 to 32 #define Port_DAT 0x10 #define Port_DRV0 0x14 #define Port_DRV1 0x18 #define Port_PUL0 0x1C void main(void) { int i; int j; int foo; uint32_t *portGConfig; uint32_t *portGData; uint32_t *APB0Gating; //setup pointers for registers portGConfig = (uint32_t *)(ALLWINNER_GPIO_G + Port_CFG1); portGData = (uint32_t *)(ALLWINNER_GPIO_G + Port_DAT); APB0Gating = (uint32_t *)(Def_APB0_Gating); //enable clocking for GPIO *APB0Gating |= 0x0020; //configure port G pin 9 to output *portGConfig |= 0x10; //set output to on *portGData |= 0x0200; Loop: foo = 0; for (j = 0; j < 100; j++) { //toggle output *portGData ^= 0x0200; foo=j; for (i = 0; i < 30000000; i++) { if(i>10) { foo++; } } } goto Loop; } Файл линковщика: MEMORY { RAM (XRW) : ORIGIN = 0x00000000, LENGTH = 0x00004000 /* 16 KB */ } SECTIONS { .start : { *(.start) } > RAM .text : { *(.text) } > RAM .bss : { *(.bss) } > RAM .fill : { FILL(0x00); . = ORIGIN(RAM) + LENGTH(RAM) - 1; BYTE(0x00); } > RAM /DISCARD/ : { *(.dynstr*) } /DISCARD/ : { *(.dynamic*) } /DISCARD/ : { *(.plt*) } /DISCARD/ : { *(.interp*) } /DISCARD/ : { *(.gnu*) } /DISCARD/ : { *(.note*) } } ассемблерный листинг: test.elf: file format elf32-littlearm Disassembly of section .text.startup: 00000000 <main>: 0: e59f3030 ldr r3, [pc, #48]; 38 <main+0x38> 4: e5932068 ldr r2, [r3, #104]; 0x68 8: e3822020 orr r2, r2, #32 c: e5832068 str r2, [r3, #104]; 0x68 10: e59328dc ldr r2, [r3, #2268]; 0x8dc 14: e3822010 orr r2, r2, #16 18: e58328dc str r2, [r3, #2268]; 0x8dc 1c: e59328e8 ldr r2, [r3, #2280]; 0x8e8 20: e3822c02 orr r2, r2, #512; 0x200 24: e58328e8 str r2, [r3, #2280]; 0x8e8 28: e59f300c ldr r3, [pc, #12]; 3c <main+0x3c> 2c: e2533001 subs r3, r3, #1 30: 1afffffd bne 2c <main+0x2c> 34: eafffffb b 28 <main+0x28> мейк-скрипт: arm-none-eabi-gcc -Os -march=armv7-a -std=c99 -marm -fpic -Wall -fno-common -fno-builtin -ffreestanding -nostdinc -nostdlib -fno-strict-aliasing -mno-thumb-interwork -fno-stack-protector -fno-toplevel-reorder -Wstrict-prototypes -Wno-format-nonliteral -Wno-format-security -c test.c -o test.o arm-none-eabi-ld -T test.lds -M -o test.elf test.o arm-none-eabi-objdump -D test.elf > test.asm arm-none-eabi-objcopy -O binary test.elf test.bin mksunxiboot.exe test.bin test-sd.bin Для создания загрузочного образа использую программу с аргументами: mksunxiboot.exe test.bin test-sd.bin С помощью дискового редактора копирую весь образ на 16-й сектор карты памяти (это смещение 8кБ от начала). Карта памяти отформатирована в винде. Первые сектора - ДОСовский загрузчик-заглушка . Из ассемблерного листинга видно что программа идет с адреса 0, как требуется в A13. Хедер вроде тоже с верной контрольной суммой. Стек инитится BROM-ом (при старте) SP=0x7FF8 Вставляю карту в одладочную плату, подаю питание (внешний БП 6V 2A) - и ничего не горит. Пожалуйста, помогите разобраться, чего не хватает и что не так? Весь проект прилагаю, мейк-файлы, скрипты и утилиты там же. src.zip P.S. Звонил светодиод и ножку контроллера - контакт есть, диод зажигается от тестера. Объявил переменные volatile, не помогло: void main(void) { volatile int i; volatile int j; volatile int foo; volatile uint32_t *portGConfig; volatile uint32_t *portGData; volatile uint32_t *APB0Gating; //setup pointers for registers portGConfig = (volatile uint32_t *)(ALLWINNER_GPIO_G + Port_CFG1); portGData = (volatile uint32_t *)(ALLWINNER_GPIO_G + Port_DAT); APB0Gating = (volatile uint32_t *)(Def_APB0_Gating); //enable clocking for GPIO *APB0Gating |= 0x0020; //configure port G pin 9 to output *portGConfig |= 0x10; //set output to on *portGData |= 0x0200; Loop: foo = 0; for (j = 0; j < 100; j++) { //toggle output *portGData ^= 0x0200; foo=j; for (i = 0; i < 30000000; i++) { if(i>10) { foo++; } } } goto Loop; } 00000000 <main>: 0: e59f3094 ldr r3, [pc, #148]; 9c <main+0x9c> 4: e24dd010 sub sp, sp, #16 8: e5932068 ldr r2, [r3, #104]; 0x68 c: e3822020 orr r2, r2, #32 10: e5832068 str r2, [r3, #104]; 0x68 14: e59328dc ldr r2, [r3, #2268]; 0x8dc 18: e3822010 orr r2, r2, #16 1c: e58328dc str r2, [r3, #2268]; 0x8dc 20: e59328e8 ldr r2, [r3, #2280]; 0x8e8 24: e3822c02 orr r2, r2, #512; 0x200 28: e58328e8 str r2, [r3, #2280]; 0x8e8 2c: e3a02000 mov r2, #0 30: e58d200c str r2, [sp, #12] 34: e58d2008 str r2, [sp, #8] 38: e59d2008 ldr r2, [sp, #8] 3c: e3520063 cmp r2, #99; 0x63 40: cafffff9 bgt 2c <main+0x2c> 44: e59328e8 ldr r2, [r3, #2280]; 0x8e8 48: e2222c02 eor r2, r2, #512; 0x200 4c: e58328e8 str r2, [r3, #2280]; 0x8e8 50: e59d2008 ldr r2, [sp, #8] 54: e58d200c str r2, [sp, #12] 58: e3a02000 mov r2, #0 5c: e58d2004 str r2, [sp, #4] 60: e59d1004 ldr r1, [sp, #4] 64: e59f2034 ldr r2, [pc, #52]; a0 <main+0xa0> 68: e1510002 cmp r1, r2 6c: ca000007 bgt 90 <main+0x90> 70: e59d2004 ldr r2, [sp, #4] 74: e352000a cmp r2, #10 78: c59d200c ldrgt r2, [sp, #12] 7c: c2822001 addgt r2, r2, #1 80: c58d200c strgt r2, [sp, #12] 84: e59d2004 ldr r2, [sp, #4] 88: e2822001 add r2, r2, #1 8c: eafffff2 b 5c <main+0x5c> 90: e59d2008 ldr r2, [sp, #8] 94: e2822001 add r2, r2, #1 98: eaffffe5 b 34 <main+0x34> 9c: 01c20000 biceq r0, r2, r0 a0: 01c9c37f biceq ip, r9, pc, ror r3

Я бы отталкивался от того, по каким линиям пойдут биты байта при записи в регистр tcon0_cpu_wr_reg. Проверить в принципе это можно, просто зациклив передачу в этот регистр и путём вызванивания тестером логического уровня на каждом бите. Увы и ах - осциллографа и логического анализатора под рукой нет. :( А так да, получается индусский говнокод с нагромождением. Но к сожалению, нормальных SDK под эти чипы нет Должно хватить вот этого(код я писал): #define CA 25 /* A1位 A1 bit */ #define TCON 0x01C0C000 /* TCON基地址 TCON Base Address */ #define TCON0_CPU_IF_REG *(volatile u32*)(TCON+0x60) #define TCON0_CPU_WR_REG *(volatile u32*)(TCON+0x64) void TCON0_INDEX(u32 index) { TCON0_CPU_IF_REG&=~(1UL<<CA); //清除CA位 clear CA bit TCON0_CPU_WR_REG=index; //写索引 write index } void TCON0_DATA(u32 data) { TCON0_CPU_IF_REG|=(1UL<<CA); //设置CA位 set CA bit TCON0_CPU_WR_REG=data; // 写入数据 write data } Не забыв отремапить ноги GPIO и включив тактирование нужных узлов периферии. и отынитить TCON для режима CPU I/F i8080 :) Ну и второй головняк - тайминги шины. Подозреваю, что на ширину строба записи будет влиять делитель для DCLK, а на длительность цикла - длина VSYNC лили LCDDE

Поковырял немножко Linux BSP, "linux-master". Вырисовываются интересные вещи касаемо работы LCD в i8080 bus mode. __s32 LCD_CPU_WR(__u32 screen_id,__u32 index,__u32 data) { tcon0_cpu_wr_16b(screen_id,index,data); return 0; } __s32 LCD_CPU_WR_INDEX(__u32 screen_id,__u32 index) { tcon0_cpu_wr_16b_index(screen_id,index); return 0; } __s32 LCD_CPU_WR_DATA(__u32 screen_id,__u32 data) { tcon0_cpu_wr_16b_data(screen_id,data); return 0; } Пошёл дальше: s32 tcon0_cpu_wr_16b(u32 sel, u32 index, u32 data) { tcon0_cpu_wr_24b(sel,tcon0_cpu_16b_to_24b(index),tcon0_cpu_16b_to_24b(data)); return 0; } u32 tcon0_cpu_16b_to_24b(u32 value) { return ((value & 0xfc00)<<8) | ((value & 0x0300)<<6) | ((value & 0x00e0)<<5) | ((value & 0x001f)<<3); } s32 tcon0_cpu_wr_24b(u32 sel, u32 index, u32 data) { tcon0_cpu_wr_24b_index(sel,index); tcon0_cpu_wr_24b_data(sel,data); return 0; } s32 tcon0_cpu_wr_24b_index(u32 sel, u32 index) { u32 count = 0; while((tcon0_cpu_busy(sel)) && (count < 50)) { count ++; disp_delay_us(100); } lcd_dev[sel]->tcon0_cpu_ctl.bits.ca = 0; lcd_dev[sel]->tcon0_cpu_wr.bits.data_wr = index; return 0; } s32 tcon0_cpu_wr_24b_data(u32 sel, u32 data) { u32 count = 0; while((tcon0_cpu_busy(sel)) && (count < 50)) { count ++; disp_delay_us(100); } lcd_dev[sel]->tcon0_cpu_ctl.bits.ca = 1; //tcon0_cpu_if_reg_t lcd_dev[sel]->tcon0_cpu_wr.bits.data_wr = data; //tcon0_cpu_wr_reg_t return 0; } Тут мы видим, что перед посылкой байтов команды или данных - цикл с ожиданием пока устройство занято. Это очень плохо! Все параллельные шины с которыми приходилось работать - EBI у AT91RM9200, FSMC у STM32, FBI у Блекфина - не имели костыля для ожидания завершения. Сама процедура ожидания: u32 tcon0_cpu_busy(u32 sel) { if(lcd_dev[sel]->tcon0_cpu_ctl.bits.wr_flag || lcd_dev[sel]->tcon0_cpu_ctl.bits.rd_flag) return 1; else return 0; } Ну и интуитивно понятно, что структуры как раз описывают биты и смещения регистров от базового адреса. Как всё сложно описано!!! И всё для того чтобы послать на шину 8080 байт данных!!! Чего стоят только описания структур и юнионов: static volatile __de_lcd_dev_t *lcd_dev[2]; s32 tcon_set_reg_base(u32 sel, u32 base) { lcd_dev[sel]=(__de_lcd_dev_t *)base; return 0; } tcon_set_reg_base(screen_id,para->reg_base[DISP_MOD_LCD0]); tcon_set_reg_base(screen_id,para->reg_base[DISP_MOD_LCD1]); typedef struct { u32 reg_base[DISP_MOD_NUM]; u32 reg_size[DISP_MOD_NUM]; u32 irq_no[DISP_MOD_NUM]; s32 (*disp_int_process)(u32 sel); s32 (*vsync_event)(u32 sel); s32 (*start_process)(void); s32 (*capture_event)(u32 sel); s32 (*shadow_protect)(u32 sel, bool protect); disp_sw_init_para *sw_init_para; }__disp_bsp_init_para; //device define typedef struct { tcon_gctl_reg_t tcon_gctl; //0x000 tcon_gint0_reg_t tcon_gint0; //0x004 tcon_gint1_reg_t tcon_gint1; //0x008 tcon_reservd_reg_t tcon_reg00c; //0x00c tcon0_frm_ctl_reg_t tcon0_frm_ctl; //0x010 tcon0_frm_seed_reg_t tcon0_frm_seed_pr; //0x014 tcon0_frm_seed_reg_t tcon0_frm_seed_pg; //0x018 tcon0_frm_seed_reg_t tcon0_frm_seed_pb; //0x01c tcon0_frm_seed_reg_t tcon0_frm_seed_lr; //0x020 tcon0_frm_seed_reg_t tcon0_frm_seed_lg; //0x024 tcon0_frm_seed_reg_t tcon0_frm_seed_lb; //0x028 tcon0_frm_tab_reg_t tcon0_frm_tbl_0; //0x02c tcon0_frm_tab_reg_t tcon0_frm_tbl_1; //0x030 tcon0_frm_tab_reg_t tcon0_frm_tbl_2; //0x034 tcon0_frm_tab_reg_t tcon0_frm_tbl_3; //0x038 tcon_reservd_reg_t tcon_reg03c; //0x03c tcon0_ctl_reg_t tcon0_ctl; //0x040 tcon0_dclk_reg_t tcon0_dclk; //0x044 tcon0_basic0_reg_t tcon0_basic0; //0x048 tcon0_basic1_reg_t tcon0_basic1; //0x04c tcon0_basic2_reg_t tcon0_basic2; //0x050 tcon0_basic3_reg_t tcon0_basic3; //0x054 tcon0_hv_if_reg_t tcon0_hv_ctl; //0x058 tcon_reservd_reg_t tcon_reg05c; //0x05c tcon0_cpu_if_reg_t tcon0_cpu_ctl; //0x060 tcon0_cpu_wr_reg_t tcon0_cpu_wr; //0x064 tcon0_cpu_rd0_reg_t tcon0_cpu_rd; //0x068 tcon0_cpu_rd1_reg_t tcon0_cpu_fet; //0x06c tcon_reservd_reg_t tcon_reg070[6]; //0x070~0x84 tcon0_io_pol_reg_t tcon0_io_pol; //0x088 tcon0_io_tri_reg_t tcon0_io_tri; //0x08c tcon1_ctl_reg_t tcon1_ctl; //0x090 tcon1_basic0_reg_t tcon1_basic0; //0x094 tcon1_basic1_reg_t tcon1_basic1; //0x098 tcon1_basic2_reg_t tcon1_basic2; //0x09c tcon1_basic3_reg_t tcon1_basic3; //0x0a0 tcon1_basic4_reg_t tcon1_basic4; //0x0a4 tcon1_basic5_reg_t tcon1_basic5; //0x0a8 tcon_reservd_reg_t tcon_reg0ac; //0x0ac tcon1_ps_sync_reg_t tcon1_ps_ctl; //0x0b0 tcon_reservd_reg_t tcon_reg0b4[15]; //0x0b4~0x0ec tcon1_io_pol_reg_t tcon1_io_pol; //0x0f0 tcon1_io_tri_reg_t tcon1_io_tri; //0x0f4 tcon_ecc_fifo_reg_t tcon_ecfifo_ctl; //0x0f8 tcon_debug_reg_t tcon_debug; //0x0fc tcon_ceu_ctl_reg_t tcon_ceu_ctl; //0x110 tcon_reservd_reg_t tcon_reg104[3]; //0x104~0x10c tcon_ceu_coef_mul_reg_t tcon_ceu_coef_rr; //0x110 tcon_ceu_coef_mul_reg_t tcon_ceu_coef_rg; //0x114 tcon_ceu_coef_mul_reg_t tcon_ceu_coef_rb; //0x118 tcon_ceu_coef_add_reg_t tcon_ceu_coef_rc; //0x11c tcon_ceu_coef_mul_reg_t tcon_ceu_coef_gr; //0x120 tcon_ceu_coef_mul_reg_t tcon_ceu_coef_gg; //0x124 tcon_ceu_coef_mul_reg_t tcon_ceu_coef_gb; //0x128 tcon_ceu_coef_add_reg_t tcon_ceu_coef_gc; //0x12c tcon_ceu_coef_mul_reg_t tcon_ceu_coef_br; //0x130 tcon_ceu_coef_mul_reg_t tcon_ceu_coef_bg; //0x134 tcon_ceu_coef_mul_reg_t tcon_ceu_coef_bb; //0x138 tcon_ceu_coef_add_reg_t tcon_ceu_coef_bc; //0x13c tcon_ceu_coef_rang_reg_t tcon_ceu_coef_rv; //0x140 tcon_ceu_coef_rang_reg_t tcon_ceu_coef_gv; //0x144 tcon_ceu_coef_rang_reg_t tcon_ceu_coef_bv; //0x148 tcon_reservd_reg_t tcon_reg14c[5]; //0x14c~0x15c tcon0_cpu_tri0_reg_t tcon0_cpu_tri0; //0x160 tcon0_cpu_tri1_reg_t tcon0_cpu_tri1; //0x164 tcon0_cpu_tri2_reg_t tcon0_cpu_tri2; //0x168 tcon0_cpu_tri3_reg_t tcon0_cpu_tri3; //0x16c tcon0_cpu_tri4_reg_t tcon0_cpu_tri4; //0x170 tcon0_cpu_tri5_reg_t tcon0_cpu_tri5; //0x174 tcon_reservd_reg_t tcon_reg178[2]; //0x178~0x17c tcon_cmap_ctl_reg_t tcon_cmap_ctl; //0x180 tcon_reservd_reg_t tcon_reg184[3]; //0x184~0x18c tcon_cmap_odd0_reg_t tcon_cmap_odd0; //0x190 tcon_cmap_odd1_reg_t tcon_cmap_odd1; //0x194 tcon_cmap_even0_reg_t tcon_cmap_even0; //0x198 tcon_cmap_even1_reg_t tcon_cmap_even1; //0x19c tcon_reservd_reg_t tcon_reg1a0[20]; //0x1a0~0x1ec tcon_safe_period_reg_t tcon_volume_ctl; //0x1f0 tcon_reservd_reg_t tcon_reg1f4[3]; //0x1f4~0x1fc tcon_mux_ctl_reg_t tcon_mul_ctl; //0x200 tcon_reservd_reg_t tcon_reg204[9]; //0x204~0x224 tcon_reservd_reg_t tcon_reg228[54]; //0x228~0x2fc tcon1_fill_ctl_reg_t tcon_fill_ctl; //0x300 tcon1_fill_begin_reg_t tcon_fill_start0; //0x304 tcon1_fill_end_reg_t tcon_fill_end0; //0x308 tcon1_fill_data_reg_t tcon_fill_data0; //0x30c tcon1_fill_begin_reg_t tcon_fill_start1; //0x310 tcon1_fill_end_reg_t tcon_fill_end1; //0x314 tcon1_fill_data_reg_t tcon_fill_data1; //0x318 tcon1_fill_begin_reg_t tcon_fill_start2; //0x31c tcon1_fill_end_reg_t tcon_fill_end2; //0x320 tcon1_fill_data_reg_t tcon_fill_data2; //0x324 tcon_reservd_reg_t tcon_reg328[54]; //0x328~0x3fc tcon_gamma_tlb_reg_t tcon_gamma_tlb[256]; //0x400 }__de_lcd_dev_t; typedef union { u32 dwval; struct { u32 trigger_en : 1; // default: 0; u32 trigger_start : 1; // default: 0; u32 trigger_fifo_en : 1; // default: 0; u32 trigger_fifo_bist_en : 1; // default: 0; u32 trigger_sync_mode : 2; // default: 0; u32 res0 : 10; // default:; u32 flush : 1; // default: 0; u32 auto_ : 1; // default: 0; u32 res1 : 4; // default:; u32 rd_flag : 1; // default: 0; u32 wr_flag : 1; // default: 0; u32 vsync_cs_sel : 1; // default: 0; u32 ca : 1; // default: 0; u32 da : 1; // default: 0; u32 res2 : 1; // default:; u32 cpu_mode : 4; // default: 0; } bits; } tcon0_cpu_if_reg_t; typedef union { u32 dwval; struct { u32 data_wr : 24; // default: 0; u32 res0 : 8; // default:; } bits; } tcon0_cpu_wr_reg_t; Предстоит жёсткий секс с Линуксом :) Начну-ка я наверно с A13, отладочной платы Olinuxino (тоже есть на руках). Чем-то напомнило индусский код :) Теперь надеюсь, вы поняли, почему я не люблю писать под линукс? Потому что громоздко и тормозит! Нужен чистый поток сознания в программировании!

_pv, большое спасибо! :rolleyes: Вот как раз этой схемы мне не хватало, а я уже хотел логику прикидывать к CLK, LCDDE, чтобы выдать нужную полярность по стробам. Зарегался на том форуме и поинтересовался у китайцев - сказали, что всё как в A10, дали инфу по подключению и даташиты: https://debugdump.com/t_900.html Что понравилось - отвечают очень оперативно, возможно они контачат с Alwinner напрямую. Таблица подключения от A10 по назначению пинов совпадает с вашей картинкой: Очень надеюсь, что в v3s работа с дисплеем в режиме i8080 присутствует и её алгоритм аналогичен как в A20, A10. Почему я не хочу подключать дисплей по параллельному RGB? Потому что контроллер будет постоянно вынужден как угорелый рисовать кадр, в то время как он ещё будет не готов, а это несколько неудобно! Плюс отсутствие режимов LCD с выбором прямоугольника отрисовки, направлений - проще через встроенный контроллер дисплея это делать. Ну и как правило, большинство LCD матриц помимо простого RGB содержат ещё I2C/SPI порт для конфигурации. Так что в плане переносимости мне проще через i8080-BUS работать. Этот Alwinner полон загадок, заманчив высокой тактовой 1,2 ГГц + DDR 400 МГц, QFP корпусом и встроенной памятью. Но его загадочность меня настораживает :) Надо сообразить простейшую плату для опытов (v3s есть на руках), для питания пока поставлю обычнее LDO на 3.3V, 3V, 1.2V и 1.8V (точно в даташите смотреть надо). Наподобие как STM-NUCLEO - по минимуму обвязки: питание, кварц, пины на порты, MCU, SD карта памяти для загрузки. Конечно, после мигания светодиодами и ком-порта, прийдётся ковырять Linux BSP, что наверно трудоемко. А обращаться к дисплею в режиме 8080 как? (команды и данные слать) . Через TCON0_CPU_WR_REG, TCON0_CPU_RD0_REG и TCON0_CPU_RD1_REG ? Команда или данные выбираются через бит 25 регистра TCON0_CPU_IF_REG ? (управление A1). На первых порах конечно, линию DC LCD можно посадить на обычный GPIO без ущерба скорости, но хочется чтобы красиво было.

мой ответ остался на предыдущей странице:)

действие 1) проверка условия , если равно, выполняем: addeq r0,r1,r2 LSL r3 действие 2) сдвигаем r2 влево на значение бит в r3: addeq r0,r1,r2 LSL r3 действие 3) складываем r2 с r1: addeq r0,r1,r2 LSL r3: дейсвтвие 4) записываем результат в r0: addeq r0,r1,r2 LSL r3 У Блекфина как-то тухло: ... P1.L = _LCD; P1.H = _LCD; .align 2 P0 = 272; P1 = P1 + P0; P0 = -256; P1 = P1 + P0; P0 = 144; [--SP] = (P5:3); P2 = 64; P5 = 0 P5.H = 8193 LOOP .P36L2L LC0 = P0; ... Это типа ногодрыга как GPIO ? Надо 16 бит данных, 1 бит адреса, стробы CS, WR. На строб RD можно забить(не нужен, подтянуть к Vcc). Типа DSP-инструкция, SIMD к тому же! :) ----- Касаемо Олвиннера V3s. Вышел на форум китайцев https://debugdump.com/t_576.html - тут они тот самый дисплей что у меня (контроллер тот же) подключают к... SPI - и быстродействие всего 10 FPS. Видимо, через 16 битную шину его не подрубить, раз SPI взяли

:) Просто меня сбила с толку улыбающаяся тётка с повязкой на лбу, выпускающая бабочек :) (её можно встретить часто на продукцииях STM)

Если сравнить обсуждаемые здесь Кинетисы с таким поделием восточных друзей - STM32H743, какой из этих камней более предпочтителен в плане отсутствия глюков (не сырости) и открытой документации?

Усовершенствованный вариант Lossless видео-кодека "PackMan" - с мульти-стратегическим конвейером. Теперь жмёт ещё лучше! Не совместим с ранними версиями ! Исходники усовершенствованного кодера/декодера, там же и билды под Win32, DOS: PackMan_r2_.zip Исходники усовершенствованного декодера для nanoPlayer: nanoPlay_PackMan2.zip Вариант печатной платы (4-слойка) герберы: nanoPlay_Gerber.zip Демонстрационное видео на ЮТУБ: http://www.youtube.com/watch?v=ZCZwsP3rf8Y

должны быть, но не обязаны. Я глянул даташит на V3s что у меня есть (на английском), там расписаны времянки, но самих стробов CS, WR, адресные биты A* на выводах микроконтроллера НЕ нашёл. Таблицы мультиплексирования выводов тоже молчат. Просто приводят картинку с времянками, которая как бы намекает, что без дополнительной логики (ПЛИС, ЦПЛД,рассыпуха) не обойтись: У вас даташит другой или тоже английский? Был один головняк(SDRAM), будет два (преобразователь SDIO в i8080 для LCD :) ) А линукс и камадроид не даст ответов на этот вопрос, потому что там везде "стандартная" связка LCD с v3s по RGB-интерфейсу.

Смотрел даташит на v3s и схему камдроида на нём и пришёл к 2-м печальным выводам: 1) шина там только на 8 бит 2) и только RGB, а не i8080, управляющих стробов (nWR,nRD,nCS) я не нашёл, также как и их описания в даташите. Кусок подключения LCD к v3s в камдроиде: И проиграть в помехозащищённости - гнать БИТОВЫЙ клок, который должен быть в 8- или в -16 раз больше по частоте чтобы битики в байты преобразовать (некий параллельный регистр с последовательной загрузкой). Ну и нагромождение. А один фиг тупую матрицу прийдётся цеплять на SPI или I2S, так что одним RGB-интерфейсом не отделаешься! А вот если i8080 - то это уже сказка! :) Но беда в том, что C6745 который мне так понравился в QFP содержит только 16 и 8 битную шину, а хочется 32 и 16 как в БГА :) Нашёл тут ещё кандидата - STM32H743 - у него 1 Мбайт внутренней оперативы на частоте 400 МГц- весь код эмулятора туда можно затолкать, 32 бита SDRAM - на случай если некоторвые эмуляторы не поместятся + чтение РОМ-ов для эмуляторов + спроецированная FatFS - всё в SDRAM! Ну и RGB интерфейс там 24-битный (в корпусе LQFP208 точно!) и 32 разряда на SDRAM. И ещё питание одно - 3.3V, нет дополнительного гемороя с питанием как в Оллвиннерах и C6745. Ядро Cortex-M7 с его вкусным многооперандными командами Ассемблера типа: addeq r0,r1,r2 LSL r3 - 4 действия в одном - это лучше чем BF532 на 400 МГц и его 16-битной шиной! И наличие плавающей точки! И QFP корпус. И шить можно ST-LINK-ом то бишь дискавери. И 2D- ускоритель с 2-D DMA, цвет прозрачности, BitBlt - это всё для эмуляторов нужно!! :) Одни плюсы! В общем вижу его в кандидатах на замену 532-го. :santa2:

Смотрю в даташит на 6745 и вижу - 2 шины EMIF A, B, что очень радует. Но огорчила урезанность шин в 2 раза в QFP корпусе: вместо 32- и 16- имеем 16- и 8- соответственно. Посему возник вопрос. Планирую дисплей с шиной 16 бит (LCD, не тупая матрица) соединить по шине 8 бит. Можно ли сделать 16-битность дисплею таким макаром: CPU LCD D0-----D0 D1-----D1 D2-----D2 D3-----D3 D4-----D4 D5-----D5 D6-----D6 D7-----D7 BA0----D8 BA1----D9 A0------D10 A1------D11 A2 ------D12 A3------D13 A4------D14 A5------D15 A12-----Command/Data CS[]-----LCD CS nWR-----LCD nWR Pull Up----LCD nRD И обращаться к регистрам/ данным дисплея так: обращаться к памяти LCD: *(int*)(LCD_Data_Base|(Data>>8))=Data; к командам: *(int*)(LCD_Command_Base|(Command>>8))=Command; Всёравно для дисплея нужен только 1 адресный бит, более ничего на шине не будет. А SDRAM будет висеть на 16-битной шине. Пройдет или нет? Правда , ещё DMA-пересылки надо будет хорошо продумать при таком подключении

Такой же DMA есть и в ADSP BF532,533. Так и называется 2D-DMA! :) Там можно приращения разные задавать по X и Y, возможнен вариант с "топтанием на месте через 1" - для растяжения пикселей по обеим осям. На счёт направлений не скажу, но в целом оставил у меня хорошие впечатления. Активно его использовал при отрисовки кадра в эмуляторах. Зеркально? :)

Чтоб не быть голословным: сделал и закачал архив(ссылка ниже), в котором результаты сжатия трёх кодеков: - VP9: 18.1 МБ - Lagarith: 12.8 МБ -PackMan v.2 (мульти-стратегический): 12.6 МБ Исходное видео: 52.3 МБ что при пересчёте с 8 на 6 бит на компоненту - в эквиваленте 39.23 МБ (младшие 2 бита каждой цветовой компоненты оригинального видео =0). Там же бат-скрипты, утилита для воспроизведения ffplay и новая версия кодера/декодера PackMan (мультистратегический). На более длинных видео - результат будет ещё лучше в пользу PackMan Архив: https://dropfiles.org/2Sn пароль к архиву 13169

У вас есть опыт работы с этим камнем без пингвина и ведра? Внешней шины для подключения дополнительной периферии, наподобие как FSMC у STM32 у V3s как я понял нет? Если так - прощай дисплеи с контроллерами и своей памятью .. Тот что в QFP OMAPL137-HT недоступен для заказа из-за политики США по отношению к РФ. В БГА мне неинтересно.

Всё-же уделил время на VP9 и затестил его в режиме лосслесс через ffmmpeg: rem VP9 кодек Lossless конфа ffmpeg -i 0.avi -c:v libvpx-vp9 -lossless 1 output.webm Результат обнадёжил : 390 МБ против моих: Packman rev.0: 234 МБ rev. 1: 228 МБ Мультистратегический: 224 МБ Лагариф и МСУ также лучше: 242 и 247 МБ соответственно. Так что хвалёный VP9 на лосслесс оказался хуже "старых" добрых MSU и Lagarith. И жмёт ещё долго, по сравнению с PackMan и Lagarith. Выводы я сделал.

Вам осталось сделать ещё один небольшой рывок - доказать, что AV1 и VP9 битэкзактны. Есть сомнения по поводу. Ну и глупо искать по нарицательным именам конкретные видеоролики, тем более версии, заточенные под 160x128. Но ваш намёк понял - вот вам моё встречное напутствие: встречного ветра и якорь вам в... :)

AV1 и VP9 - не lossless. MSU - не древний, живёт и процветает до сих пор. http://www.compression.ru/video/ls-codec/ Lagarith я бы не сказал что древний

Здравствуйте. Ищу процессор в QFP корпусе, который будет производительнее, чем ADSP BlackFin BF532. Цель: запуск обильного кода с 2D графикой (bitblt, colorkey, alfablending) + немножко 3D (поворот, перенос, масштабирование), тригонометрия. + эмуляция процессоров -8 и 16 бит: Z80, 6502, M68000. + декодирование видео (H264, MJPEG,...) аудио (MP3, FLAC) Пробовал собирать эмуляторы на BF532, разогнал до 700 МГц. Иногда эмуляция всей системы не достигает 60 FPS из-за отсутствия floating point, медленной производительности. В качестве кандидата на замену рассматриваю : TMS320C6745 - доступен, корпус QFP, 475 МГц, шина SDRAM 32 бита, есть floating point, VLIW до 6 команд одновременно. Вроде как лучше чем BF532 ? Или даст выигрыш по сравнению с 532-м незначительно?

Что за шланг? GCC arm-noeabi ? Насколько хуже будет код GCC по скорости по сравнению с ARMCC ? Да, подвисает зараза, когда много сорцов проекта открыто. По этой причине редактирую код в Блокноте, а фишки компиляции со сборкой в проект - в Кейле. Насколько оправдан и затратен переход на GNU ToolChain? Файлы линкера и мейк-файлы писать умею.

А разве не порвёт C6745 BF532 хотя-бы из-за: 1) VLIW до 6 команд одновременно - против 2 команд у BF532 //выигрыш в 3 раза 2) SDRAM 32 бит - против 16 бит у 532-го // выигрыш в 2 раза 3) Hardware floating point - против софтварных целочисленных рядов Тейлора на 532-м //выигрыш в специфических местах 4) 475 МГц - против 400 // несущественно, но приятно 5) У BF532 - скудный малооперандный ассемблер, в отличие от того же ARM. У C6745 вроде как по-лучше? В целом вижу оправданным переход на C6745. Поправьте, если ошибаюсь.

Рассматривал JPEG2000 Lossless, его программная реализация (которая есть в открытом виде) - очень громоздка для переноса на МК STM32F407 и алгоритм просто не пошёл (из-за применения менеджера кучи для данных и кода). К тому же, кодек MJPEG2000 Lossless проигрывает по степени сжатия даже тому же Lagrith. Dirac - тоже жмет хуже Lagarith и требует много вычислительных ресурсов. HuffYUV - прост, но хуже всех жал. MSU - нет исходников Lagarith - хотел вначале портировать его, но мой кодек его обскакал по сжатию (в анимешных мультфильмах) Остался 1 путь - написать свой, взяв всё лучшее со всех. Я - человек науки, поэтому тут ещё дополнительно академический интерес. Жал много фильмов, мультфильмов, коэффициент сжатия был не ниже 2. Обычно от 2.8 - 3. Конечно, если жать белый шум, то выигрыша не даст :) Пробовал применить ZLIB, слишком затратно по времени на декодирование. LZH тоже. Так что только энтропийное кодирование. ---------------------------------- Я вот тут подумал и сообразил новый Мульти-Стратегический кодек. Суть его в том, что пробуются все возможные сочетания блоков конвеера на предмет сжатия. И выбирается лучшая стратегия. Если исходный сигнал у нас - это RGB, то блоков конвеера у нас 5: 1) преобразование YCbCr 2) WaveLet преобразование 3) Difference преобразование (межкадровое вычитание) 4) Huffman 5) RLE Просчитал, возможно 64 комбинации, они на рисунке ниже. Написал кодер, прогнал вариант 3): "Space Cobra": 1034.24 МБ С учётом 6 бит из 8: 775.68 МБ PackMan rev.0: 225 МБ PackMan rev.1: 211 МБ получилось 187 МБ против 211, что неплохо! Причем задача декодирования нисколько не усложняется, а наоборот даже - в некоторых случаях конвейер декода будет короче, номер стратегии пишется в хедер - каждый номер определяет жестко заданный порядок декодирования . Это немаловажно для STM32F407. Восклицательным знаком помечены те варианты, которые были распознаны как оптимальные по сжатию. (подсчитал статистику по стратегиям )

В SNES-эмуляторе графическая система на floating point. Эмулятор Snes9x. Потому что : поворот, растяжение, текстурирование :) Особо упоротые реализации в CPS1/2 - синтез звука на floating point. Вот я и хочу понять, насколько осчастливят меня ARM Kinetis, или всё-же лучше взять C6745, который будет по-лучше прошлого варианта эмулятора с ADSP BF532? Если оно того не стоит, то насколько будет удачен выбор Allwinner A13, v3s для эмуляторов? (без линукса правда, в стиле баре-метал)