Вопросы по С/С++ (СИ)

Staska

Goldsmith писал(а):

IMHO программа должна достаточно легко читаться, если клиент будет взаимодействовать с модулем календаря только через этот интерфейс (само собой, подправить в случае хранения строк во FLASH/EPROM).

А как можно модифицировать такую структуру:

Код:

typedef struct PROGMEM{
   void       *Next;
   void       *NextView;
   void       *Parent;
   void       *Child;
   uint8_t     Type;
   uint8_t      Variable;
   uint8_t     Max;
   uint8_t     Min;
   uint8_t     Adress;
   uint8_t     X;
   uint8_t     Y;
   const char  Text[3][36];
   
} menuItem;

Инициализация:

Код:

#define MAKE_MENU(Name, Next, NextView, Parent, Child, Type, Variable, Max, Min, Adress, X, Y, Text1, Text2, Text3) \
    extern menuItem Next;     \
   extern menuItem NextView; \
   extern menuItem Parent;   \
   extern menuItem Child;  \
   menuItem Name = {(void*)&Next, (void*)&NextView, (void*)&Parent, (void*)&Child, (uint8_t)Type, (uint8_t)Variable, (uint8_t)Max, (uint8_t)Min, (uint8_t)Adress, (uint8_t)X, (uint8_t)Y,  {{ Text1 },  { Text2 },  { Text3 }}}

и


menuItem        Null_Menu = {(void*)0, (void*)0, (void*)0, (void*)0, 0, 0, 0, 0, 0, 0, 0, {{0x00}, {0x00}, {0x00}}};
//                NEXT,      PREVIOUS     PARENT,     CHILD
MAKE_MENU(m_s1i1,  m_s1i1,    NULL_ENTRY,  NULL_ENTRY, m_s2i1,       VARIABLE_TEXT, MODE, 5, 0, 0, 0, 0, "", " ", " ");

MAK

Для хранения в указателя на переменную ?

Так работает:

Код:

 uint8_t letter = 5;
 char * const ptr PROGMEM = &letter; 

Но при попытке передать указатель макросу - выкидывает ошибку значение не известно.

Реклама

brian4ever

Подскажите пожалуйста, в Си считается нормальным когда функция внешние переменные меняет или этого лучше избегать? Я пока что через указатели передаю.

Написал Понг, хочется сделать код поаккуратней.

Бывает, что многовато в результате действия функции должно поменятся, ну хотя бы функция начинающая новую игру, должен сброситься счёт у обоих игроков, координаты ракеток, направление мячика по X и по Y . Как правильно делать?

Реклама

Goldsmith

Staska писал(а):

А как можно модифицировать такую структуру:

Для начала я бы постарался избавиться от void* в пользу более строгого типа. Если Next, Parent и Child - это соответственно следующий, родительский и дочерний элементы меню, то и указывать следует на них, а не на бесформенную область памяти. Если я не угадал и это другие объекты, то все равно можно подобрать для них более подходящий тип.

И саму структуру лучше бы спрятать от клиента, ему вовсе не обязательно знать ее внутреннее строение.

Еще не понял назначение конструкций вроде extern menuItem Next. Зачем понадобилось делать Next доступным глобально?

Goldsmith

brian4ever писал(а):

Подскажите пожалуйста, в Си считается нормальным когда функция внешние переменные меняет или этого лучше избегать?

С функциями с побочным эффектом ситуация примерно такая же, как с оператором goto: если есть возможность, лучше его избежать, но изредка бывают случаи, когда они полезны ("изредка" - это в исключительных случаях, а не через каждые 20 строк). Если есть возможность, однозначно лучше избежать.

brian4ever писал(а):

Бывает, что многовато в результате действия функции должно поменятся, ну хотя бы функция начинающая новую игру, должен сброситься счёт у обоих игроков, координаты ракеток, направление мячика по X и по Y . Как правильно делать?

Правильно/неправильно - это скорее тема для холивара, у любого клуджа всегда найдется адвокат, с пеной у рта утверждающий: "зато работает!", и переубедить его невозможно, да и незачем в общем. Имеет смысл говорить о плюсах и минусах каждого варианта.

Лично я завел бы для хранения текущего состояния игры отдельный модуль, в котором инкапсулированы все переменные. Модуль должен иметь метод инициализации, который устанавливает начальные значения всех переменных. При таком подходе в случае необходимости можно добавить впоследствии еще переменные состояния, и имеющийся код клиента переписывать не придется.

Реклама

Эиком - электронные компоненты и радиодетали

Staska

Goldsmith писал(а):

Staska писал(а):

А как можно модифицировать такую структуру:

Для начала я бы постарался избавиться от void* в пользу более строгого типа. Если Next, Parent и Child - это соответственно следующий, родительский и дочерний элементы меню, то и указывать следует на них, а не на бесформенную область памяти. Если я не угадал и это другие объекты, то все равно можно подобрать для них более подходящий тип.

Можете подсказать хорошую книжку про Си ? Особенно про построения макросов.. Я как бывший С# программист привык к удобным конструкциям из С#.

Мой код - развитие MicroMenu из Avrfreaks. Собственно (*void) наследование - по другуму не знаю как делать макрос такого вида. Указатель конечно на тот же тип как и само мену.

Что имеете под видом клиента ? Наружу имеют доступ только событию меню (минус, плюс, ввод, меню.)

Запасной вариант - сделать программу для генераций menu.h из удобного хмл файла..

Реклама

brian4ever

Goldsmith писал(а):

Лично я завел бы для хранения текущего состояния игры отдельный модуль, в котором инкапсулированы все переменные. Модуль должен иметь метод инициализации, который устанавливает начальные значения всех переменных. При таком подходе в случае необходимости можно добавить впоследствии еще переменные состояния, и имеющийся код клиента переписывать не придется.

А есть способ попроще, который можно порекомендовать начинающему?

Реклама

Goldsmith

Staska писал(а):

Можете подсказать хорошую книжку про Си ?

Самые начальные буквари советовать не буду, их навалом и практически все равноценны, поскольку толкут одну и ту же воду в одинаковых ступах; если программировали на куда более развитом C#, то разобраться с C легко сможете по любому попавшемуся под руку справочнику.

Что касается стиля программирования на С, рекомендую полистать Schreiner A. Object-oriented programming with ANSI C. Подход IMHO не идеальный, но некоторые идеи заслуживают рассмотрения.

Применение TDD на C обстоятельно рассмотрено в James W. Grenning. Test Driven Development for Embedded C. Есть также забавная, но очень толковая брошюрка Mark VanderVoord. Embedded Testing with Unity and CMock. Марк с коллегами из Atomic Objects опубликовали также ряд хороших статей по использованию паттерна MCH (Model-Conductor-Hardware) в программах для МК на языке C.

Примеры неплохого встроенного кода можете посмотреть в Jean J. Labrosse. Embedded Systems Building Blocks. Правда, насколько я помню, Лабросс пишет для интеловского микропроцессора (кажется, i80186 или что-то наподобие), но на то он и C, чтобы не заморачиваться на подобные мелочи.

Если хотите построить свою систему на основе модели конечного автомата, может пригодиться отличная книга Miro Samek. Practical Statecharts in C/C++: Quantum Programming for Embedded Systems, а также прилагаемый к ней бесплатный фреймворк разработки автора.

Ну и, конечно же, незаменимая "книжка" по C - стандарт языка.

Например, ISO/IEC 9899.

Staska писал(а):

Я как бывший С# программист привык к удобным конструкциям из С#.

Отличная основа. Наверняка как минимум знакомы с основными паттернами проектирования и имеете практику объектно-ориентированного анализа. А реализовать хороший проект сможете без труда и на обычном C.

Staska писал(а):

Собственно (*void) наследование - по другуму не знаю как делать макрос такого вида. Указатель конечно на тот же тип как и само мену.

Классический вариант - элемент структуры ссылается на саму структуру:

Код:

struct TreeNode
{
  DataItem dataItem;
  TreeNode *left;
  TreeNode *right;
};

TreeNode * вместо аморфного void * позволяет использовать все преимущества сильной типизации.

Staska писал(а):

Что имеете под видом клиента ?

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

Staska писал(а):

Наружу имеют доступ только событию меню (минус, плюс, ввод, меню.)

А как быть с объявлениями extern? Они ведь имеют внешнюю компоновку и, следовательно, нарушают инкапсуляцию.

Staska писал(а):

Запасной вариант - сделать программу для генераций menu.h из удобного хмл файла..

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

Нужно продумать очень хороший, самодостаточный генератор, к выходу которого ничего не нужно приписывать вручную.

Goldsmith

brian4ever писал(а):

А есть способ попроще, который можно порекомендовать начинающему?

Этот способ на самом деле вовсе не сложен, начинающие при желании могут его легко постичь. А пользоваться таким модулем будет намного проще, чем простым набором переменных, поскольку он защищен от многих случайных ошибок кодирования.

Staska

За книжки спасибо.

Цитата:

А как быть с объявлениями extern? Они ведь имеют внешнюю компоновку и, следовательно, нарушают инкапсуляцию.

Ошибка.

Цитата:

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

Потому и говорю - запасной вариант. Главное в таком коде - комментарий жирный буквами "Auto-generated code, do not change" И все таки - хочется сделать все одним куском. Но удобно. Оставим меню на потом, оно и так работает, нужно будет ethernet в основной плате добить.

Реклама

Goldsmith

Staska писал(а):

А как можно модифицировать такую структуру:

Вот, кстати, еще рекомендация по улучшению (хоть и относится не к вопросам по C, а к самой задаче).

Предлагаю убрать из структуры поле *Parent. Вместо этого каждый раз, спускаясь на следующий уровень меню, откладывать текущий уровень в стек. Тогда для возврата к предыдущему уровню достаточно лишь снять указатель с верхушки стека.

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

Во-вторых, проще модифицировать меню (например, переносить опции из одного подменю в другое.

В-третьих, небольшая экономия памяти, если меню может строиться динамически в ОЗУ. Глубина вложения меню вряд ли превысит 3-4 уровня, соответственно и стек потребуется небольшой.

Staska

Goldsmith писал(а):

Вот, кстати, еще рекомендация по улучшению (хоть и относится не к вопросам по C, а к самой задаче).

Предлагаю убрать из структуры поле *Parent. Вместо этого каждый раз, спускаясь на следующий уровень меню, откладывать текущий уровень в стек. Тогда для возврата к предыдущему уровню достаточно лишь снять указатель с верхушки стека.

Экономия будет по стороне флеша, но не по стороне рама. Мы убираем один байт из каждого меню, но должны добавить с 1+макс_глубина_меню переменных.

Goldsmith

Staska писал(а):

Экономия будет по стороне флеша, но не по стороне рама

Это при условии, что меню жестко прошивается во FLASH и всегда неизменно. Впрочем, первые два плюса гораздо существеннее этой мизерной экономии, если только не идет борьба за каждый байт (в случае, если кристалл выбран неправильно), поскольку исключают потенциальный источник ошибок.

Staska

Goldsmith писал(а):

Staska писал(а):

Экономия будет по стороне флеша, но не по стороне рама

Это при условии, что меню жестко прошивается во FLASH и всегда неизменно. Впрочем, первые два плюса гораздо существеннее этой мизерной экономии, если только не идет борьба за каждый байт (в случае, если кристалл выбран неправильно), поскольку исключают потенциальный источник ошибок.

Это я из испуга. Запускал недавно tcp/ip на меге 328 - каждый байт считаеш. Зная что так не делается - но теперь для сети нужен просто дополнительный вывод на разъем программатора. И если уж менят процессор - то только на кортех.

COKPOWEHEU

Я пункты меню делал в массиве во флеш, который по мере надобности копируется в ОЗУ. Точно так же ссылки на всех 4 родственников (выбор пунктов меню реализован несколько коряво но не о нем речь). Преимущество перед размазыванием по памяти - на потомка надо тратить 1 байт (адрес в массиве) а не 2 (а то и больше, адрес во всей памяти).

Твори бобро

Здраствуйте. В общем в С я пока бревно. Есть вопрос.

эта штука выносит мне мозг

Код:

typedef void* (*_ext_Interface)(int, void*);

в заголовочном файле.

в другом(основном) файле есть обьявление переменной:

Код:

_ext_Interface io_interface;

основная функция ядра:

Код:

DEVICECORE_API void* _device_Interface(int procedure, void *datum)
{
int line;
        switch(procedure)
        {
         case FDP_INIT:
                io_interface=(_ext_Interface)datum;
                return (void*)_device_Init();
         case FDP_DESTROY:
                _device_Destroy();
                break;
         case FDP_DO_EXECFRAME:
                _device_Frame((VDLFrame*)datum);
                break;
         case FDP_DO_EXECFRAME_MT:
                _device_Frame((VDLFrame*)datum, true);
                break;
         блаблабла блаблабла...итд

Далее пишу типа:

Код:

void main(void)
{
char *psomedata(nullptr);
//psomedata = new char[1024*1024*3];
 _device_Interface(FDP_INIT,psomedata);

   return;
}

Далее через "switch" выполняется

Код:

int _device_Init()
{
 unsigned char *Memory;
 unsigned char *rom;

   Memory=_arm_Init();

        io_interface(EXT_READ_ROMS,Getp_ROMS());
        rom=(unsigned char*)Getp_ROMS();
        for(int i=(1024*1024*2)-4;i>=0;i-=4) *(int *)(rom+i)=_bswap(*(int *)(rom+i));

   _vdl_Init(Memory+0x200000);
   _PLD1_Init(Memory+0x200000);
   _PLD2_Init(Memory);

        _xbus_Init(_xbplug_MainDevice);
блаблабла блаблабла.....

подходим к сути выполняется Memory=_arm_Init();

Код:

unsigned char * _arm_Init()
{
    int i;

   MAS_Access_Exept=false;

        profiling=new uint32[(1024*1024*3)>>2];
        memset(profiling,0,RAMSIZE);

      profiling2=new uint32[(1024*1024*3)>>2];
        memset(profiling2,0,RAMSIZE);

      profiling3=new uint32[(1024*1024*3)>>2];
        memset(profiling3,0,RAMSIZE);

   CYCLES=0;
    for(i=0;i<16;i++)
        RON_USER[i]=0;
    for(i=0;i<2;i++)
    {
        RON_SVC[i]=0;
        RON_ABT[i]=0;
        RON_IRQ[i]=0;
        RON_UND[i]=0;
    }
    for(i=0;i<7;i++)
        RON_CASH[i]=RON_FIQ[i]=0;

   gSecondROM=0;
   pRam=new uint8[RAMSIZE+1024*1024*16];
   pRom=new uint8[ROMSIZE*2];
   pNVRam=new uint8[NVRAMSIZE];

    memset( pRam, 0, RAMSIZE+1024*1024*16);
    memset( pRom, 0, ROMSIZE*2);
    memset( pNVRam,0, NVRAMSIZE);
    gFIQ=false;

   io_interface(EXT_READ_NVRAM,pNVRam); //ЖОПА



   REG_PC=0x03000000;
    _arm_SetCPSR(0x13); //set svc mode

    return (unsigned char *)pRam;
}

Вот. в общем на io_interface(EXT_READ_NVRAM,pNVRam); пишет "унхандлед эксепшн access violation reading location 0xffffffff"
Кароче я сам ничего не понял. Толи память не выделилась. Толи указатель кривой, может вообще ченить другое. Мне самое главное понять имено вот это выражение typedef void* (*_ext_Interface)(int, void*). Это типа указатель на указатель?

Вообще это эмулятор, просто хотел припрутить междумордие, заодно нормально подучить язык до СПП. Кто мчто может подскажет, и разжует по порядку?

Goldsmith

Твори бобро писал(а):

Мне самое главное понять имено вот это выражение typedef void* (*_ext_Interface)(int, void*). Это типа указатель на указатель?

Больше похоже на указатель на функцию от двух аргументов (int и void*), возвращающую void*.

Во время компиляции никаких предупреждений не было?

Твори бобро

Goldsmith писал(а):

Твори бобро писал(а):

Мне самое главное понять имено вот это выражение typedef void* (*_ext_Interface)(int, void*). Это типа указатель на указатель?

Больше похоже на указатель на функцию от двух аргументов (int и void*), возвращающую void*.

Во время компиляции никаких предупреждений не было?

В принципе только не явная конверсия типов(или как там?).
Вот полный листинг(на всякий случай)

Код:

1>------ Rebuild All started: Project: _device_sys, Configuration: Debug Win32 ------
1>Build started 23.02.2013 21:17:12.
1>_PrepareForClean:
1>  Deleting file "Debug\_device_sys.lastbuildstate".
1>InitializeBuildStatus:
1>  Creating "Debug\_device_sys.unsuccessfulbuild" because "AlwaysCreate" was specified.
1>ClCompile:
1>  _device_sys.cpp
1>  XBUS.cpp
1>  vdlp.cpp
1>  PLD3.cpp
1>  quarz.cpp
1>  PLD2.cpp
1>PLD2.cpp(489): warning C4005: 'CHAR_BIT' : macro redefinition
1>          C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\limits.h(23) : see previous definition of 'CHAR_BIT'
1>PLD2.cpp(702): warning C4244: '=' : conversion from '__int64' to 'double', possible loss of data
1>  Iso.cpp
1>  DSP.cpp
1>  DiagPort.cpp
1>  PLD1.cpp
1>  bitop.cpp
1>  arm.cpp
1>  Generating Code...
1>Manifest:
1>  Deleting file "Debug\_device_sys.exe.embed.manifest".
1>LinkEmbedManifest:
1>  _device_sys.vcxproj -> P:\Testapp\test\Debug\_device_sys.exe
1>FinalizeBuildStatus:
1>  Deleting file "Debug\_device_sys.unsuccessfulbuild".
1>  Touching "Debug\_device_sys.lastbuildstate".
1>
1>Build succeeded.
1>
1>Time Elapsed 00:00:09.06
========== Rebuild All: 1 succeeded, 0 failed, 0 skipped ==========

Создал тупо Win32 console application из файла device_sys.cpp, с помощью мастера(create project from exiting source) дабы проверить вообще возможность сборки

Goldsmith

Попробуйте поставить точку останова в строке с нежным именем //ЖОПА и поглядеть, чему там равно значение переменной io_interface. Возможно, она (переменная) неправильно инициализирована.

Аlex

Цитата:

Больше похоже на указатель на функцию от двух аргументов (int и void*), возвращающую void*.

Немножко не так. Объявляется тип _ext_Interface как функция, принимающая 2 аргумента (int и void*) и возвращающая void*.

Твори бобро

Goldsmith писал(а):

Попробуйте поставить точку останова в строке с нежным именем //ЖОПА и поглядеть, чему там равно значение переменной io_interface. Возможно, она (переменная) неправильно инициализирована.

имя значение тип
io_interface 0x006c0040 void * (int, void *)*

Да наверняка. Но проблема что тот кусок кода я не трогал, сами исходники рабочие, программа работает под виндой, но очень медленно, а программисты свалили втихую, и помогать не собираются никому и низа что. Хочу для начала прилепить интерфейс, в перспективе паралелизацию. Но пока познания мои сводятся к тому что, когда я вижу такое обилие символов "*" мозг пытается свалить из черепушки под диван :))

Аlex писал(а):

Цитата:

Больше похоже на указатель на функцию от двух аргументов (int и void*), возвращающую void*.

Немножко не так. Объявляется тип _ext_Interface как функция, принимающая 2 аргумента (int и void*) и возвращающая void*.

Вот и хочется понять что-же это void*. С моими познаниями в Си - void это отсутствие аргументов, короче пустота. А тут указатель на нее, причем указатель на указатель пустоты.