Перейти к содержанию
    

HEX

Свой
  • Постов

    54
  • Зарегистрирован

  • Посещение

Весь контент HEX


  1. bool "третье состояние"

    у меня собственно так и есть, универсальность эта другая тема. да жульничество, но интервейс вызова Read(void* Buff, int N) достаточно широко используется, есть и другие варианта попадание мусора в bool. Но проверять значение после подозрительных мест надо обязательно. Потом такой момент, если используется swtich, пусть даже с параметром enum, все равно в голове помним о левых значениях, которые обработаем default. При работе с bool переменными думается true/false, а там может и вигная какая то быть, причем "заразная", передается присваиванием ( B2 = B1 ). А явное преобразование B = (bool)( B ) по моему, должно работать четко.
  2. bool "третье состояние"

    я в этом вижу потенциальную проблему, например, при чтении бинарного файла данных.Придется производить доп. операции, что бы избавиться от мусора: //data.bin = {0x0D, 0x00, 0x00, 0x00} f = fopen("data.bin", "r"); fread(&B, sizeof(B), 1, f); //B = 13 fclose(f); //Избавляемся от мусора if (B) B = true; else B = false;
  3. bool "третье состояние"

    Если бы не мешали я бы может и не заметил: //B = 13 if (B == true) printf("true\n"); else printf("false\n"); B = !B; if (B == true) printf("true\n"); else printf("false\n"); выводит только "true"
  4. bool "третье состояние"

    явное преобразование типа тоже не помогает: B2 = (bool)(B); //B2 = 12
  5. bool "третье состояние"

    #include <stdbool.h> int main() { bool B; B = 13; //B = 1 B = !B; //B = 0 unsigned char* Ptr; Ptr = (unsigned char*)(&B); *Ptr = 13; //B = 13 bool B2; B2 = B; //B2 = 12 B2 = !B; //B2 = 13 return 0; } Почему при присваивание непосредственно числа все нормально ( B = 13 ), а при присваивании другово bool ( B2 = B ) мусор остается? Так и должно быть?
  6. Все должно работать, см руководство на компилер раздел DLIB runtime environment. Надо только включить соотв. опцию линкера (если текст в окне появился, значит включено, тока почему дата левая?). Что подрузомивается под "досовского turboC"? А так очень нужная и полезная штука.
  7. причиной можте быть что нет сигнала rst при включении питания, а при запуске в отладчике сигнал сброса формирует jlink
  8. организация структуры проекта мне попадалась только тут: Таненбаум "Операционные системы разработка и реализаци" но и по инету полазить можно
  9. А как можно подключать си-шный файлы из библиотеки к проекту?
  10. Книжки, все достоваемо в инете. - Сэм Канер, Джек Фолк "Тестирование ПО" - Д.Макгрегор, Д.Сайкс "Тестирование объектно-ориентирования ПО" - Капберстон "Быстрое тестирование" советую посмотреть на форуме rsdn.ru там есть ветка посвященная тестированию
  11. File operation

    В опциях проекта необходимо установить: - General Options\Library Configuration = Full - Linker \With I/O emulation modules = true дальше как обычно, например, fopen, fread,...
  12. Я разводкой плат к счастью, а может, к сожалению не занимаюсь, и в этих вопросах мало компетентен. Это был просто случай из моего опыта. Фотку бы показал, да сейчас это платы уже нету.
  13. Был похожий случай: пластиковый корпус, внутри плата с lpc2134, при воздействии статическим электричеством, например, снятие защитного полиэтилена с корпуса, проц достаточно стабильно зависает (при этом сильно грелся), лечилось только передергиванием питания, сброс не помогал. Если кто знает просветите, возможность возникновения такой ситуации зависит от семейства проца или в любом случае соотношение качество разводки / уровеня помех?
  14. Может кому пригодиться. Сама идея описана здесь, вот еще статья на эту тему, спасибо авторам. Log.h #ifndef LOG_H #define LOG_H #include "Config.h" #include <stdbool.h> #if (LOG_LEVEL > 0) #include <iostream> #endif //Приоритеты (типы сообщений) #define LOG_NONE 0 #define LOG_FATAL 1 #define LOG_ERROR 2 #define LOG_WARNING 3 #define LOG_NOTICE 4 #define LOG_INFO 5 //Уровень фильтрации сообщений лога #ifndef LOG_LEVEL #define LOG_LEVEL (LOG_NONE) #endif class Logger { private: public: Logger(void); static void AddMess(int Level, const char *mess, ...); static void AddStr(const char *mess, ...); }; //Добавить Info сообщение в лог #define LogInfo(...) \ if (LOG_LEVEL >= LOG_INFO) { \ Logger::AddMess(LOG_INFO, __VA_ARGS__); \ } \ //Добавить Notice сообщение в лог #define LogNotice(...) \ if (LOG_LEVEL >= LOG_NOTICE) { \ Logger::AddMess(LOG_NOTICE, __VA_ARGS__); \ } \ //Добавить Warning сообщение в лог #define LogWarning(...) \ if (LOG_LEVEL >= LOG_WARNING) { \ Logger::AddMess(LOG_WARNING, __VA_ARGS__); \ } \ //Добавить Error сообщение в лог #define LogError(...) \ if (LOG_LEVEL >= LOG_ERROR) { \ Logger::AddMess(LOG_ERROR, __VA_ARGS__); \ } \ //Добавить Fatal сообщение в лог #define LogFatal(...) \ if (LOG_LEVEL >= LOG_FATAL) { \ Logger::AddMess(LOG_FATAL, __VA_ARGS__); \ } \ //Добавить строку в лог #define LogStr(...) \ if (LOG_LEVEL >= LOG_FATAL) { \ Logger::AddStr(__VA_ARGS__); \ } \ #endif //LOG_H Log.cpp #include "Log.h" #include <cstdarg> //Имена типов сообщений const char LevelNames[6][8] = { "", "Fatal", "Error", "Warning", "Notice", "Info" }; //----------------------------------------------------------------------------- // Logger //----------------------------------------------------------------------------- //Конструктор Logger::Logger(void) { } //Добавить строку в лог //mess: // Сообщение //...: // Дополнительные аргументы в стиле printf void Logger::AddStr(const char *mess, ...) { #if (LOG_LEVEL > 0) va_list args; va_start(args, mess); vprintf(mess, args); va_end(args); printf("\n"); #endif } //Добавление сообщения в лог //Level: // Тип сообщения //mess: // Сообщение //...: // Дополнительные аргументы в стиле printf void Logger::AddMess(int Level, const char *mess, ...) { #if (LOG_LEVEL > 0) va_list args; //тут можно добавить вывод строки дата/время //... //Тип сообщения if ((Level > LOG_NONE) && (Level <= LOG_INFO)) { printf(" %s: ", LevelNames[Level]); } //Сообщение va_start(args, mess); vprintf(mess, args); va_end(args); printf("\n"); #endif } Config.h #ifndef CONFIG_H #define CONFIG_H //Уровень лога отлади 0..5 #define LOG_LEVEL 4 #endif //CONFIG_H
  15. Мусор может появляться если выходы драйвера ни куда не подтянуты: "прямой" должен быть подтянут к "+", "инверсный" к земле.
  16. нужно установить Lib = Full (окно General Options\Library Configuration) подробнее см. ARM C\C++ Comipiler раздел: DLIB runtime enviroment\File input and output
  17. вывод в файл через иар

    Пытаюсь реализовать вывод файл, по такой схеме сылка когда включаю <fstream>, появляется сообщение об ошибке: "This library configuration does not support file I/O, either use another existing library configuration or define a new and rebuild the library." Как это побороть? версия ияр 4_4
  18. дерганье ножками lpc2xxx

    Поясните пожалуйста, чем вызвано оскарбление в мой адрес, и как это относится к теме сообщений?
  19. дерганье ножками lpc2xxx

    Казалось бы такая простая вещь дергать ножкой... В Примерах к китам, повсеместно для установка пинов вызывается что типа: IO1SET |= 0x00000001; Как то раньше не задумывалься, пока глюку не словил, ножка "сама" прыгала в "1", хорошо это было направления 485 и контроллер просто переставал отвечать оставаясь в передаче, тяжело было не заметить. Проблема в том что операция не атомарная, и при наличии нескольких потоков, одновременно работающих с портом, в порт может быть выведена ерунда: если после загрузки значения IOSET в регистр произойдет переключение потоков, в другом потоке будут сброшены битики, потом управление будет возвращено первому потоку, он установить сброшеные биты обратно в "1" (аналогично для IOCLR). Решается проблема просто использованием IO1SET = 0x00000001 IO1CLR = 0x00000001 или помещением в критическую секцию. Тем более что IO1SET |= .. бесмысленно, т.к. запись нуля ничего не меняет. вот как выглядет на асме: //IO1SET |= 0x1; LDR R0, [PC, #+156] LDR R1, [PC, #+152] LDR R1, [R1, #+0] ORRS R1, R1, #0x1 STR R1, [R0, #+0] //IO1SET_bit.P0_1 = 1; LDR R0, [PC, #+136] LDR R1, [PC, #+132] LDR R1, [R1, #+0] ORRS R1, R1, #0x2 STR R1, [R0, #+0] //IO1SET = 0x1; LDR R0, [PC, #+116] MOV R1, #+1 STR R1, [R0, #+0]
  20. это описка, спасибо, ну идея то правельная?
  21. виноват, забыл вставить #define RxFIFOTrigger1 0x00 #define RxFIFOTrigger4 0x40 #define RxFIFOTrigger8 0x80 #define RxFIFOTrigger14 0xC0 #define RxFIFOTrigger RxFIFOTrigger8 Еще доработал: ... case RDAInterruptID: { i = 0; while ((i < (RxFIFOTrigger - 1)) & ((U0LSR & ReceiverDataReady) != 0)) { FInQueue.Put(U0RBR); i = i + 1; } break; } ... Вот как это будет работать (если не прав поправте): При приеме данных когда в FIFO набирается >= RxFIFOTriggerLevel, должно прийти прерывание RDA. Забираем данные, прерывание по RDA снимется когда в FIFO будет данных < RxFIFOTriggerLevel. Если считаем все данные из FIFO мы не получем CTI (согласно мануалу). Поэтому надо оставлять один байт в RxFIFO, соответственно TriggerLevel должен быть > 1.
  22. До перло, так работает: всем спасибо!
  23. Где хранить свои lib?

    А как будет происходить отладка? можно будет посмотреть чего делается в модулях библиотеки? В умных книжках рекомендует включать хидеры от специализированных к более общим, цитата (в цитате) из книги Брюс Эккель Филосовия С++: Заголовки включаются в порядке "отспециализированных к общим". Иначе говоря сначала включаются все заголовочные файлы в текущим каталоге, затем заголовочные файлы личного инструментария автора, затем заголовки стандартной библиотеки С++ и наконец, - заголовочные файлы библиотеки С. Джон Лакос в своей книги "Large-Scale C++ Software Deign" так обосновывает эту последовательность Автономная обработка h-файлов компонента (без внешних объявлений и определений) помогает предотвратить скрытые ошибки. Включение h-файла в самой первой строке c-файла гарантирует присутствие всей критически важной информации, относящейся к физическому интерфейса компонент (или ее отсутствие обнаружиться немедленно при попытке откомпилировать c-файл). Если заголовочные файлы включаются в порядке "от специализированных к общим", вы быстрее обнаружите те из них, которые не обрабатываются автономно, и избавите сеюя от дальнейших огорчений.
  24. Где хранить свои lib?

    С хидерами вроде понятно, для подключения пишем: #include "..\_LIB\file.h" (порядок включения, как я понимаю, - после хидеров проекта, перед стандартной библиотекой) Можно наврное, добавлять путь"..\_INC\" в опциях предпроцессора, но тогда будут проблемы при однаковых именах хидеров, и менее наглядно, чем "..\_LIB\file.h" - сразу видну что хидер из библиотеки. А исходники библиотеки придется добовлять в проект? Чего лучше использовать исходники или объектные? И еще вопрос, в чем приимущества перед размещением в toolkit_dir?
  25. Где хранить свои lib?

    не хотелось бы велосипед изобретать, тем более что все тонкости сразу не учтеш.
×
×
  • Создать...