Востребована ли простая GUI-библиотека для LCD?

DrGandalf

ArtDen, вот что нашлось.

Думаю, тут два варианта - научить программу переводить битмапы в набор инструкций (вызовы для рисования примитивов или точек), либо извращаться с дефайнами, чтобы только при компиляции под AVR подставлялся специфичный для AVR код, препятствующий копированию в RAM.
PS. А вы сами пробовали на МК тестировать? В ARM Cortex-M ведь тоже гарвардская архитектура, и для них тоже видимо придется что-то придумывать.

Реклама

ArtDen

DrGandalf писал(а):

PS. А вы сами пробовали на МК тестировать? В ARM Cortex-M ведь тоже гарвардская архитектура, и для них тоже видимо придется что-то придумывать.

Конечно. У меня она на STM32F100R6T6B работает.
А у Cortex-M архитектура фон Неймана, так что там всё в порядке.

Реклама

DrGandalf

ArtDen, вы что-то путаете. У Cortex-M3 гарвардская архитектура. Как и в вашем STM32F100R6T6B.
Посмотрите табличку вот тут, раздел "Instruction sets". Видно, что не у всех Cortex-M архитектура Фон-Неймана.

ArtDen

Всё, разобрался. Мне объяснили, что хотя у CortexM гарвардская архитектура, но для программиста это не важно, т.к. адресное пространство одно и для FLASH-памяти и для ОЗУ, а также команды доступа к ячейкам FLASH и ОЗУ одинаковые.
Правда, в вики написано что

Цитата:

Также машина гарвардской архитектуры имеет различные адресные пространства для команд и данных. Так, нулевой адрес инструкций — это не то же самое, что и нулевой адрес данных.

Но похоже что для CortexM это не так.

DrGandalf

Я тоже для себя разобрался. В английской (и русской тоже) вики в статье про гарвардскую архитектуру приведен также подраздел с описанием т. н. модифицированной гарвардской архитектуры (Modified Harvard architecture) - когда адресное пространство одно, однако доступ к RAM и ROM осуществляется по разным шинам. Так вот ядра Cortex M3 и M4 относятся именно к такой архитектуре, но уточнение "модифицированная" касательно архитектуры часто просто опускается.

Реклама

DX168B

Начал знакомство с STM32 с ядра CortexM4F (STM32F407VG).
На сколько я понял из даташита, там вся память (ОЗУ, ПЗУ), регистры и вся периферия идут сплошным файлом.
Приведенный пример ниже загружает массив (скомпилированный бинарник) с флеша в ОЗУ и передает ему управление банальным прыжком в область ОЗУ.

main flash firmware (main.cpp)

Код:

#include <ST\iostm32f407VG.h>


//////////////////////////////////////////////////////////////////////////////
typedef int (*func)(void);

//////////////////////////////////////////////////////////////////////////////
#pragma section = "FLASH"
const unsigned char rawData[59][4] = {
    0x00, 0x84, 0x01, 0x20, 0xE1, 0x01, 0x00, 0x20, 0x9F, 0x01, 0x00, 0x20,
    0x9F, 0x01, 0x00, 0x20, 0x9F, 0x01, 0x00, 0x20, 0x9F, 0x01, 0x00, 0x20,
    0x9F, 0x01, 0x00, 0x20, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x9F, 0x01, 0x00, 0x20,
    0x9F, 0x01, 0x00, 0x20, 0x00, 0x00, 0x00, 0x00, 0x9F, 0x01, 0x00, 0x20,
    0x9F, 0x01, 0x00, 0x20, 0x4F, 0xF0, 0x00, 0x50, 0x01, 0x68, 0x0A, 0x68,
    0x42, 0xF0, 0x08, 0x02, 0x0A, 0x60, 0x41, 0x68, 0x0A, 0x68, 0x42, 0xF0,
    0xAA, 0x42, 0x0A, 0x60, 0x81, 0x68, 0x00, 0x22, 0x0A, 0x60, 0xC1, 0x68,
    0x0A, 0x60, 0x01, 0x69, 0x0A, 0x60, 0x08, 0xE0, 0x00, 0xBF, 0x49, 0x1C,
    0x91, 0x42, 0xFB, 0xDB, 0x41, 0x69, 0x0A, 0x68, 0x82, 0xF4, 0x00, 0x42,
    0x0A, 0x60, 0x00, 0x21, 0x00, 0x4A, 0xF5, 0xE7, 0xFF, 0xFF, 0x0F, 0x00,
    0x4E, 0xF6, 0x88, 0x51, 0xCE, 0xF2, 0x00, 0x01, 0x08, 0x68, 0x40, 0xF4,
    0x70, 0x00, 0x08, 0x60, 0x4F, 0xF0, 0x00, 0x70, 0xE1, 0xEE, 0x10, 0x0A,
    0x70, 0x47, 0xFE, 0xE7, 0x00, 0xF0, 0x09, 0xF8, 0x00, 0x28, 0x01, 0xD0,
    0xC0, 0x46, 0xC0, 0x46, 0x00, 0x20, 0xFF, 0xF7, 0xC7, 0xFF, 0x00, 0xF0,
    0x02, 0xF8, 0x01, 0x20, 0x70, 0x47, 0x00, 0xF0, 0x01, 0xB8, 0x00, 0x00,
    0x07, 0x46, 0x38, 0x46, 0x00, 0xF0, 0x02, 0xF8, 0xFB, 0xE7, 0x00, 0x00,
    0x80, 0xB5, 0xC0, 0x46, 0xC0, 0x46, 0x02, 0x4A, 0x11, 0x00, 0x18, 0x20,
    0xAB, 0xBE, 0xFB, 0xE7, 0x26, 0x00, 0x02, 0x00, 0xC0, 0x46, 0xC0, 0x46,
    0xFF, 0xF7, 0xCE, 0xFF, 0xFF, 0xF7, 0xDA, 0xFF
};

////////////////////////////////////////////////////////////////////////////// Таблица адресов периферии
#pragma section = "FLASH"
volatile const uint32_t io_p[6] = {(uint32_t)&RCC->AHB1ENR,  (uint32_t)&GPIOD->MODER, 
                                   (uint32_t)&GPIOD->OTYPER, (uint32_t)&GPIOD->OSPEEDR, 
                                   (uint32_t)&GPIOD->PUPDR, (uint32_t)&GPIOD->ODR};

////////////////////////////////////////////////////////////////////////////// Место, где будет расположена таблица (Начало ОЗУ)
#pragma location = 0x20000000
volatile uint32_t io_ptr[20];

//////////////////////////////////////////////////////////////////////////////
int main()
{
  uint32_t size = (sizeof(rawData)/4); //Размер бинарника в словах
  uint32_t start_addr = 0x20000100; //Адрес, куда следует поместить бинарник
  
  volatile uint32_t *Raw = (uint32_t*)start_addr; //Передача адреса указателю
  
  for(uint32_t x=0; x<size; x++) //Копирование бинарника в ОЗУ
  {
    Raw[x] = 0x00000000;
    Raw[x] |= (uint32_t)(rawData[x][0]<<0);
    Raw[x] |= (uint32_t)(rawData[x][1]<<8);
    Raw[x] |= (uint32_t)(rawData[x][2]<<16);
    Raw[x] |= (uint32_t)(rawData[x][3]<<24);
  }
  
  for(uint32_t y = 0; y<6; y++) //Копирование адресов периферии (для частичного абстрагирования от конкретного камня)
  {
    io_ptr[y] = io_p[y];
  }
  
  
  func RAM = (func)Raw[1];//копирование адреса начала программы из Reset_Handler бинарника
  RAM(); //Собственно, само исполнение программы

  while(1); //На случай, если программа завершится
}
 

bin array code (main.cpp)

Код:

#include <ST\iostm32f407VG.h>
#include "IO_MAP.h"

///////////////////////////////////////////////////////////////////////////////
int main()
{
  RCC_AHB1ENR |= RCC_AHB1ENR_GPIODEN; //Enable GPIO D

  GPIOD_MODER |= (GPIO_MODER_MODER15_0 | 
                   GPIO_MODER_MODER14_0 | 
                   GPIO_MODER_MODER13_0 | 
                   GPIO_MODER_MODER12_0); // GPIO Mode Port Out
  
  GPIOD_OTYPER = 0x00000000; //Out D type Push-Pull
  GPIOD_OSPEEDR = 0x00000000; //Out Speed Low (2MHz)
  GPIOD_PUPDR = 0x00000000; //Not Pull Up/Down
  
  while(1)
  {
    for(int i = 0 ; i < 0x00FFFFF ; i++){asm("nop");}
    GPIOD_ODR ^= GPIO_ODR_ODR_15;
  }
}
 

IO_MAP.h

Код:

///////////////////////////////////////////////////////////////////////////////
#pragma location = 0x20000000
volatile __no_init uint32_t *io_ptr[64];

///////////////////////////////////////////////////////////////////////////////
#define RCC_AHB1_ENR   0
#define GPIO_D_MODER   1
#define GPIO_D_OTYPER  2
#define GPIO_D_OSPEEDR 3
#define GPIO_D_PUPDR   4
#define GPIO_D_ODR     5
#define GPIO_D_IDR     6

///////////////////////////////////////////////////////////////////////////////
#define RCC_AHB1ENR     *io_ptr[RCC_AHB1_ENR]
#define GPIOD_MODER     *io_ptr[GPIO_D_MODER]
#define GPIOD_OTYPER    *io_ptr[GPIO_D_OTYPER]
#define GPIOD_OSPEEDR   *io_ptr[GPIO_D_OSPEEDR]
#define GPIOD_PUPDR     *io_ptr[GPIO_D_PUPDR]
#define GPIOD_ODR       *io_ptr[GPIO_D_ODR]
#define GPIOD_IDR       *io_ptr[GPIO_D_IDR]

 

При компиляции бинарника, в настройках линкера было задано иное адресное пространство для ОЗУ и ПЗУ.

TEST_RAM.icf

Код:

/*###ICF### Section handled by ICF editor, don't touch! ****/
/*-Editor annotation file-*/
/* IcfEditorFile="$TOOLKIT_DIR$\config\ide\IcfEditor\cortex_v1_0.xml" */
/*-Specials-*/
define symbol __ICFEDIT_intvec_start__ = 0x20000100;
/*-Memory Regions-*/
define symbol __ICFEDIT_region_ROM_start__ = 0x20000100;
define symbol __ICFEDIT_region_ROM_end__   = 0x20017FFE;
define symbol __ICFEDIT_region_RAM_start__ = 0x20017FFF;
define symbol __ICFEDIT_region_RAM_end__   = 0x2002FFFF;
/*-Sizes-*/
define symbol __ICFEDIT_size_cstack__ = 0x400;
define symbol __ICFEDIT_size_heap__   = 0x800;
/**** End of ICF editor section. ###ICF###*/


define memory mem with size = 4G;
define region ROM_region   = mem:[from __ICFEDIT_region_ROM_start__   to __ICFEDIT_region_ROM_end__];
define region RAM_region   = mem:[from __ICFEDIT_region_RAM_start__   to __ICFEDIT_region_RAM_end__];

define block CSTACK    with alignment = 8, size = __ICFEDIT_size_cstack__   { };
define block HEAP      with alignment = 8, size = __ICFEDIT_size_heap__     { };

initialize by copy { readwrite };
//initialize by copy with packing = none { section __DLIB_PERTHREAD }; // Required in a multi-threaded application
do not initialize  { section .noinit };

place at address mem:__ICFEDIT_intvec_start__ { readonly section .intvec };

place in ROM_region   { readonly };
place in RAM_region   { readwrite,
                        block CSTACK, block HEAP };
 

Данный пример говорит о том, что ядру абсолютно начихать на то, где находятся данные, а где программа, несмотря на его гарвардскую архитектуру.

Реклама

DrGandalf

Спасибо за интересный пример. Хм, а без

Код:

#pragma section = "FLASH"

константный массив будет тупо скопирован в стек при инициализации?
Если так то наверное в коде проекта нужно тоже указать область

Код:

#pragma section = "FLASH"
const uint8_t tahoma14ru_Bitmaps[] = {...}

DX168B

Это IARовская директива. Без нее массив копируется в ОЗУ. Причем, хрен знает куда. (в произвольную область ОЗУ)
Желательно объявить массив как volatile const , иначе при отсутствии каких либо операций с ним, компилятор его похерит.

Код:

#pragma section = "FLASH"
const uint8_t tahoma14ru_Bitmaps[] = {...}

Для IARа это будет справедливо.
Что касается GCC, то там хз. Мало имел дела с ним.

ArtDen

Сделал скроллинг в списке окна выбора. Правда, надо будет скроллер немного по-другому рисовать.

Реклама

_AHTOXA_

DX168B писал(а):

Это IARовская директива. Без нее массив копируется в ОЗУ. Причем, хрен знает куда. (в произвольную область ОЗУ)

Очень сильно сомневаюсь, насчёт "копирования в ОЗУ". Константные массивы обычно остаются во флеше. (Ну, если компилятор не совсем глупый, а IAR уж точно не такой)

DX168B

Судя по изучению ассемблерного листинга, массив все-таки копировался, несмотря на const.
А так, я записал, чтобы оно железно там оставалось. Даже несмотря на утехи компилятора.

_AHTOXA_

DX168B писал(а):

Судя по изучению ассемблерного листинга, массив все-таки копировался, несмотря на const.

Не верю. Или вы оптимизацию отключили в ноль (хотя и при этом вряд ли).

DX168B

Код:

//////////////////////////////////////////////////////////////////////////////
//#pragma section = "FLASH"
const uint32_t io_p[6] = {(uint32_t)&RCC->AHB1ENR,  (uint32_t)&GPIOD->MODER, 
                          (uint32_t)&GPIOD->OTYPER, (uint32_t)&GPIOD->OSPEEDR, 
                          (uint32_t)&GPIOD->PUPDR, (uint32_t)&GPIOD->ODR};
 

Вызывается до функции main.

Код:

__sti__routine:
        LDR.N    R0,??DataTable2
        LDR.N    R1,??DataTable2_1  ;; 0x40023830
        STR      R1,[R0, #+0]
        LDR.N    R1,??DataTable2_2  ;; 0x40020c00
        STR      R1,[R0, #+4]
        LDR.N    R1,??DataTable2_3  ;; 0x40020c04
        STR      R1,[R0, #+8]
        LDR.N    R1,??DataTable2_4  ;; 0x40020c08
        STR      R1,[R0, #+12]
        LDR.N    R1,??DataTable2_5  ;; 0x40020c0c
        STR      R1,[R0, #+16]
        LDR.N    R1,??DataTable2_6  ;; 0x40020c14
        STR      R1,[R0, #+20]
        BX       LR               ;; return

И собственно, цикл for, который копирует массив куда мне надо.

Код:

//   60   for(uint32_t y = 0; y<6; y++)
//   61   {
//   62     io_ptr[y] = io_p[y];
        MOVS     R2,#+24
        LDR.N    R1,??DataTable2
        MOV      R0,#+536870912
          CFI FunCall __aeabi_memcpy4
        BL       __aeabi_memcpy4 

И все на этом

Подпрограмму __aeabi_memcpy4 показать немогу, так как она видна только в отладчике. В листинге ее нет. Суть ее, перетащить данные из одной области ОЗУ в другую.
С отладчика текст копировать не могу. Если кто покажет как, буду благодарен.
Подмечу то, что в данной версии IARа еще плохо проработана поддержка данного камня. В комплекте нет файла iostm32f407vg.h (его я добавил сам, а для других камней есть)
Хотя, в отладчике камень есть.
По этому, он может и тупить.

Есть еще сомнения?

ArtDen писал(а):

Сделал скроллинг в списке окна выбора. Правда, надо будет скроллер немного по-другому рисовать.

А исходники уже обновлены?

HHIMERA

DX168B писал(а):

Есть еще сомнения?

Да, есть...
Включите в опциях компилятора генерацию map-файла и посмотрите, в map-файле, куда что ложится...

DX168B

Код:

io_p                    0x20018000  0x18  Data  Lc  main.o [1]  //Злосчастный массив. Как видите, ОН В ОЗУ
rawData                 0x0800021c  0xec  Data  Lc  main.o [1] // Большой массив остался во FLASH

Запуск линкера:

Код:

#    Command line =  D:\IARprj\STM32\STM32F407VGT6\Release\Obj\PNS.o          #
#                    D:\IARprj\STM32\STM32F407VGT6\Release\Obj\main.o         #
#                    D:\IARprj\STM32\STM32F407VGT6\Release\Obj\startup_stm32f #
#                    4xx.o -o D:\IARprj\STM32\STM32F407VGT6\Release\Exe\cpp.o #
#                    ut --redirect _Printf=_PrintfFull --redirect             #
#                    _Scanf=_ScanfFull --map D:\IARprj\STM32\STM32F407VGT6\Re #
#                    lease\List\cpp.map --log libraries,initialization,module #
#                    s,redirects,sections,veneers,unused_fragments            #
#                    --log_file D:\IARprj\STM32\STM32F407VGT6\Release\List\cp #
#                    p.log --config D:\IARprj\STM32\STM32F407VGT6\STM32F407VG #
#                    T6.icf --entry __iar_program_start --inline "C:\Program  #
#                    Files (x86)\IAR Systems\Embedded Workbench               #
#                    6.0\arm\CMSIS\Lib\IAR\iar_cortexM4lf_math.a" --vfe

Оптимизация в свойствах проекта выставлена как: High - Balanced

_AHTOXA_

DX168B писал(а):

Код:

const uint32_t io_p[6] = {(uint32_t)&RCC->AHB1ENR,  (uint32_t)&GPIOD->MODER, 
                          (uint32_t)&GPIOD->OTYPER, (uint32_t)&GPIOD->OSPEEDR, 
                          (uint32_t)&GPIOD->PUPDR, (uint32_t)&GPIOD->ODR}; 

Это плохой пример. Здесь указатели на волатильные регистры, или что-то в этом роде. Поэтому компилятор даже инициализирует их не циклом, а поштучно. (Я думаю, что это не копирование в ОЗУ, а инициализация).
Почему вы просто не убрали квалификатор FLASH от rawData? Потому что результат не подтверждает вашу теорию?

DX168B

Код:

const uint32_t io_p[6] = {0x40023830, 0x40020C00, 0x40020C04,
                          0x40020C08, 0x40020C0C, 0x40020C14};

Код:

io_p                    0x080002d4  0x18  Data  Lc  main.o [1]

Вы правы.

Это из-за указателей.
Я тоже всегда считал, что модификатор const всегда будет указывать на ПЗУ, но тут это не сработало.
Из-за этого и были сомнения.

Вроде и структура объявлена не как volatile:

Код:

typedef struct
{
  __IO uint32_t MODER;    /*!< GPIO port mode register,               Address offset: 0x00      */
  __IO uint32_t OTYPER;   /*!< GPIO port output type register,        Address offset: 0x04      */
  __IO uint32_t OSPEEDR;  /*!< GPIO port output speed register,       Address offset: 0x08      */
  __IO uint32_t PUPDR;    /*!< GPIO port pull-up/pull-down register,  Address offset: 0x0C      */
  __IO uint32_t IDR;      /*!< GPIO port input data register,         Address offset: 0x10      */
  __IO uint32_t ODR;      /*!< GPIO port output data register,        Address offset: 0x14      */
  __IO uint16_t BSRRL;    /*!< GPIO port bit set/reset low register,  Address offset: 0x18      */
  __IO uint16_t BSRRH;    /*!< GPIO port bit set/reset high register, Address offset: 0x1A      */
  __IO uint32_t LCKR;     /*!< GPIO port configuration lock register, Address offset: 0x1C      */
  __IO uint32_t AFR[2];   /*!< GPIO alternate function registers,     Address offset: 0x20-0x24 */
} GPIO_TypeDef;

Но я не обратил внимания на это:

Код:

#define     __IO    volatile             /*!< defines 'read / write' permissions              */

Которое закралось в файле core_cm4.h
Дико извиняюсь. :oops:

_AHTOXA_

Ну, главное что разобрались

А с приведением указателей на волатильные структуры к константам во время компиляции и GCC иногда обламывается. (Хотя конкретно этот массив - смог разместить во флеше без проблем).
Ладно, думаю что это уже немного оффтопик в данной теме, давайте закруглимся.

ArtDen

Сделал более "правильное" отображение скролл-бара при выборе вариантов в Choice

ArtDen

Сменилась идеология.
1. Теперь виджет не хранит своё положение и размер для экономии памяти. Размеры и положения теперь задаются в IWidgetVisitor::visit:

Код:

void visit_all_widgets(muil::IWidgetVisitor &visitor)
{
   visitor.visit(label_,    5,  5);
   visitor.visit(test_btn_, 5,  15,  90, 15);
   visitor.visit(up_down1_, 5,  35,  40, 15);
   visitor.visit(up_down2_, 50, 35,  40, 15);
   visitor.visit(ch_box_,   5,  55,  90, 10);
   visitor.visit(ch_,       5,  70,  90, 12);
}

Это позволяет сэкономить 8 байт на каждый виджет

2. Координаты и размеры виджетов задаются в процентах относительно ширины и высоты клиентской части экрана. Это позволит проще адаптировать одни и те же окна к разным разрешениям экрана

Ну и по мелочи: виджеты можно раскрашивать. При этом цвет не храниться в самом виджете, а запрашивается каждый раз при отрисовке через WidgetsForm::get_widget_color. Пример раскраски из исходников окна для ввода пина:

Код:

void get_widget_color(const muil::Widget *widget, muil::Color &color)
{
   if (widget == &btn_ent_) color = muil::Color(160, 255, 160);
   else if (widget == &btn_esc_) color = muil::Color(255, 160, 160);
   else if (widget == &btn_clr_) color = muil::Color(180, 180, 180);
}

Скриншот для этого окна:

Тут пример окна для ввода ПИНа целиком:
http://muil.googlecode.com/svn/trunk/sa ... INForm.hpp
http://muil.googlecode.com/svn/trunk/sa ... INForm.cpp

Как использовать это окно:

Код:

wchar_t pin[5];
PINForm pin_form(&tahoma14ru_FontInfo, pin, 4);
pin_form.show_modal();
switch (pin_form.get_modal_result())
{
case MR_OK:
   ....
case MR_CANCEL:
   ....
}

Востребована ли простая GUI-библиотека для LCD?

Кто сейчас на форуме