-
Постов
109 -
Зарегистрирован
-
Посещение
Репутация
0 ОбычныйИнформация о Stas633
-
Звание
Частый гость
- День рождения 25.02.1967
Контакты
-
Сайт
Array
-
ICQ
Array
Посетители профиля
2 145 просмотров профиля
-
Спасибо, Сергей! "Заставили" проверить! Проект большой, "много-авторский" (4+), поэтому и не искал здесь... (" ...в каком-то из заголовочных файлов есть "незакрытая" #pragma pack...). Нашел, исправил (в ОДНОМ месте на 11Мб исходников, в строках подсчитать не возьмусь). Все норм. Вопрос снят! )) Да, именно такой подход и использован. Т.е. формируется что-то типа FAT для внешнего хранилища (FLASH, EEPROM..), где в качестве параметров в том числе и размеры структур. Не встречался с таким.
-
Про "IAR XLINK Linker" речь идет?
-
Я бы с радостью! Но только, разве компоновщик умеет данные во внешней памяти размещать? (с которой обращение через слой spi/i2c) Да, такой выход рассматривался. Но, как самый простой и крайний (прямолинейный - "бери больше, кидай дальше..."). Хочется же понять чем вызвано "поведение" компилятора и как этим "поведением" управлять? Действия компилятора скрытые (не очевидные), ни каких сообщений нет, а как итог - неработающий код. Да IAR честно предупреждает в "Development Guide": ".. A normal pointer can be implicitly converted to a pointer to __packed , but the reverse conversion requires a cast....". Но "sizeof" - это ни разу не указатель. (
-
В продолжение темы... Схожая ситуация... Определяю константы, конкретно - таблицу адресов во внешней памяти (через #define ). При определении, ессно использую размеры размещаемых переменных (через sizeof()). В качестве переменных "участвуют" и структуры тоже. Вот кусочек.. #define BEGIN_ROM 0 #define PRIMARYDATA_ROM BEGIN_ROM + 10 #define SECONDDATA_ROM PRIMARYDATA_ROM+sizeof(struct MY_STRUCT) .... Все прекрасно работало, пока вынуждено не пришлось уровень оптимизации установить на максимальный по размеру... В результате для одной и той же структуры значение "sizeof" в разных файлах проекта разное - структура или упакована или нет. Соответственно "плывет" адресация... Спасает ситуацию только явный "запрет" упаковки "#pragma pack()" перед объявлением структуры. Тогда размер структуры во врем проекте одинаков. Что это за "вольности" компилятора (линковщика скорее)? Или "лыжи", которые не едут, ни при чем?
-
Добрый день. Переходим на предприятии на KiCAD. Хочется "на попробовать" ГОСТовскую библиотеку. Дайте, плз., рабочую ссылку. Спасибо.
-
Cortex M0 живьём кто-нибудь видел?
Stas633 ответил MrYuran тема в ARM, 32bit
LPC1114 есть в Тритоне (http://www.trt.ru) -
4ADC + UART + calc /// ATMEGA8
Stas633 ответил vitecd тема в MCS51, AVR, PIC, STM8, 8bit
В общем-то, ответы найдены: http://electronix.ru/forum/index.php?showt...=49371&st=0 -
4ADC + UART + calc /// ATMEGA8
Stas633 ответил vitecd тема в MCS51, AVR, PIC, STM8, 8bit
А что Вы в качестве драйверов ШД использовали? /если конечно это не "секрет фирмы"(с) :rolleyes: / Как я понимаю, должно быть дешевле 3x33970 или 6x293 с "обвесом".. -
Плз., сообщите результат "разбора" и если возможно, схемотехнику. (около полугода назад попробовал FT232BM, "...чего-то там.." не срослось. Разбираться было некогда. Остался RS232....)
-
И еще мнение, "..в догонку.." Во-первых, так ли уж необходимо производить опрос через флаг, устанавливаемый сис.таймером? , разве не проще через Sleep(n) в самом процессе? /нет необходимости ни флаг создавать, ни конструкцию "сочинять" для установки флага с периодом, отличным от периода сис.тика (напр., флаг нужен через 3мс, а тик равен 1мс. А для Sleep(n) -> n=3 и "..все..")/. ... И если "останавливаться" на Sleep(n), то не проще ли опрашивать через время достаточное для устранения дребезга... Общепринятым считается: - опрос состоятия через ~2..10мк; - при получении изменения "задержка" опроса на ~50мс /тут два варианта или "пауза", или подсчет числа обращений (3мс х 17 раз = 51 мс). Для RTOS приемлем последний вариант, посностью согласен с MrYuran/ ; - повторный опрос; - принятие решения. А что если производить опрос через 50мс? Получается: - опрос /обнаружено изменение/; - задержка 50мс; - повторный опрос; - принятие решения. Дествия те же, но вот для RTOS от 17 (в нашем примере) циклов переключения процессов, со всеми вытекающими..., удается избавиться. ... Что теряем? - Увеличивается время реакции на нажатие с 3мс до 50мс. Но при скорости печатания 150 знаков/мин (это очень хороший результат, обычно 100...120) время между нажатиями 60/150 = 400мс. А предполижить, что кнопками прибора бутут пользоваться с такой скоростью затруднительно.. То есть, применительно к EmbeddedDevice, вероятность пропуска нажатия кнопки еще меньше. .... Быть может такое мнение ошибочно?
-
Вы правы: отдельный процесс для обрабоки нажатия кнопок должен быть вне зависимости от способа реализации обработки; процесс этот низкоприоритетный и другим, более важным, процессам мешать не может (чего не скажешь о прерывании); да и "сложности", например, с выявлением длительного нажатия кнопок сводят на нет кажущуюся простоту INT-подхода. Павильное решение - периодический опрос состояния кнопок из процесса. Спасибо. :rolleyes:
-
... опрос клавиатуры по прерыванию, устранение дребезга контактов.... Подскажите как, с точки зрения RTOS, поступать правильнее : а) в прерывании от кнопок "сигналить" процессу, а уже в нем вводить паузу через Sleep(..), счивать скан-код, разрешать прерывания. б) паузу вводить в прерывании, там же получать скан, разрешать прерывания и, как писал в форуме dxp, отправлять процессу сообщение (а не флаг). ... Если "б)", то чем реализовывать паузу? недостатки способов относительно друг друга (на мой взгляд): для "а)" - сохранение контекста процесса обработки кнопок при "падении" в спячку (для реализации паузы); работа с прерыванием (разрешение прерывания) в процессе, а не в теле прерывания /"..баня, а через дорогу раздевалка.."/ для "б)" - "длинное" прерывание.
-
Деление целых чисел
Stas633 ответил Stas633 тема в Программирование
Конечно, как и вычисление иттераций при реализации метода Ньютона.. :) Но в этом случае задача видоизменяется в задачу написания своей библиотеки. Стандартные библ. работают с плавающей точкой (возможно не все). Спасибо! :a14: Лежало на поверхности, но "глаза не видят" и "мозг не думает". Спасибо за идею! :) .... Попытаюсь "переписать" ответы: Главное - преобразования присутствуют везде. long - приведение к заданной точности, float - приведение к одной экспоненте и нормализация результата. При этом работа с целыми быстрее. "Итого:" Если применение "плавающей точки" не продиктовано использованием готового кода (библ.) То для написания более "быстрого" кода, необходимо использовать "фикс.точку". А для приведения целых чисел к заданной точности использовать умножение/деление не на 10^n, а 2^n. Если же скорость работы про-ца достаточна (или есть встроенный FPU), и точность вычислений обеспечивается разрядностью мантиссы, то - "плавающая точка". .... Спасибо. С Наступающим! Удачи! :) -
Деление целых чисел
Stas633 ответил Stas633 тема в Программирование
Согласен. С точки зрения кода это, безусловно, и быстрее, и короче (чем умножение/деление на 10^n) - умножение и деление на 2 это, как известно, сдвиг, который длится 1 такт (с учетом разрядности МС конечно), но, тем не менее, это лишние, избыточные действия о которых НЕОБХОДИМО помнить при написании программы. А как быть если в различные моменты работы программы нужна разная точность? Передавать функции точность вычислений в качестве аргумента? Или писать несколько функций? Опять в "крайности"(сложности). Конечно, "тригономертию" без float ни как, но где та грань (водораздел, ватерлиния) когда "уже нужно"? Возведение в степень, деление..? ... Хорошо.. тогда так: допустим, необходимо вычислять такую фунцкию y=(x^2 + k) / z Вроде "МАТЕМАТИКИ" нет, но если не использовать float, то сразу возникает, как минимум, один вопрос: с какой точностью нужно производить вычисления? А если достаточная точность неизвестна перед началом программирования, да и вообще, может быть различной? ...... ...... Если попытаться ответить на вопрос топика, то правильно ли мнение, что: В случае, когда необходимая точность вычислений известна и не меняется, и математические формулы ограничены четырмя основными арифметическими действиями (+, -, *, /), то целесообразно применение long переменных, с соответствующими преобразованиями. В остальных случаях лучше, правильнее применять float. -
Деление целых чисел
Stas633 ответил Stas633 тема в Программирование
Не хотелось бы "углубляться", но... например. Один вариант - нужно расчитать значение и вывести его на индикатор. Выводить в формате плавающей точки ("1.234E-2"), согласитесь, не привычно для "глаза". Нужно точку "фиксировать" (0,01234). Другой вариант - нужно на расчитанное значение позиционировать, например, инструмент станка (руку робота и т.д.). И опять придется переводить float значение к единицам позиционирования (к ЦЕЛОМУ их числу). (А если дискретность перемещения не имеет 10-ное основание, то преобразование еще "длиннее"). Т.е. на лицо необходимость "обратного" преобразования float -> long. /НO!, вместе с тем, функции, написанные с использованием float, проще для "понимания", переносимее, универсальнее, если хотите./ Что может быть разным в этих вариантах? (с точки зрения работы с float) Каких именно? И еще одно уточнение... Вопрос достижения заданной точности не рассматривается. Хочется сравнить LONG v/s FLOAT /оверхед & скорость/