Jump to content

    

Stas633

Свой
  • Content Count

    109
  • Joined

  • Last visited

Community Reputation

0 Обычный

About Stas633

  • Rank
    Частый гость
  • Birthday 02/25/1967

Контакты

  • Сайт
    Array
  • ICQ
    Array

Recent Profile Visitors

1788 profile views
  1. Спасибо, Сергей! "Заставили" проверить! Проект большой, "много-авторский" (4+), поэтому и не искал здесь... (" ...в каком-то из заголовочных файлов есть "незакрытая" #pragma pack...). Нашел, исправил (в ОДНОМ месте на 11Мб исходников, в строках подсчитать не возьмусь). Все норм. Вопрос снят! )) Да, именно такой подход и использован. Т.е. формируется что-то типа FAT для внешнего хранилища (FLASH, EEPROM..), где в качестве параметров в том числе и размеры структур. Не встречался с таким.
  2. Про "IAR XLINK Linker" речь идет?
  3. Я бы с радостью! Но только, разве компоновщик умеет данные во внешней памяти размещать? (с которой обращение через слой 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" - это ни разу не указатель. (
  4. В продолжение темы... Схожая ситуация... Определяю константы, конкретно - таблицу адресов во внешней памяти (через #define ). При определении, ессно использую размеры размещаемых переменных (через sizeof()). В качестве переменных "участвуют" и структуры тоже. Вот кусочек.. #define BEGIN_ROM 0 #define PRIMARYDATA_ROM BEGIN_ROM + 10 #define SECONDDATA_ROM PRIMARYDATA_ROM+sizeof(struct MY_STRUCT) .... Все прекрасно работало, пока вынуждено не пришлось уровень оптимизации установить на максимальный по размеру... В результате для одной и той же структуры значение "sizeof" в разных файлах проекта разное - структура или упакована или нет. Соответственно "плывет" адресация... Спасает ситуацию только явный "запрет" упаковки "#pragma pack()" перед объявлением структуры. Тогда размер структуры во врем проекте одинаков. Что это за "вольности" компилятора (линковщика скорее)? Или "лыжи", которые не едут, ни при чем?
  5. Добрый день. Переходим на предприятии на KiCAD. Хочется "на попробовать" ГОСТовскую библиотеку. Дайте, плз., рабочую ссылку. Спасибо.
  6. LPC1114 есть в Тритоне (http://www.trt.ru)
  7. В общем-то, ответы найдены: http://electronix.ru/forum/index.php?showt...=49371&st=0
  8. А что Вы в качестве драйверов ШД использовали? /если конечно это не "секрет фирмы"(с) :rolleyes: / Как я понимаю, должно быть дешевле 3x33970 или 6x293 с "обвесом"..
  9. Плз., сообщите результат "разбора" и если возможно, схемотехнику. (около полугода назад попробовал FT232BM, "...чего-то там.." не срослось. Разбираться было некогда. Остался RS232....)
  10. И еще мнение, "..в догонку.." Во-первых, так ли уж необходимо производить опрос через флаг, устанавливаемый сис.таймером? , разве не проще через 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, вероятность пропуска нажатия кнопки еще меньше. .... Быть может такое мнение ошибочно?
  11. Вы правы: отдельный процесс для обрабоки нажатия кнопок должен быть вне зависимости от способа реализации обработки; процесс этот низкоприоритетный и другим, более важным, процессам мешать не может (чего не скажешь о прерывании); да и "сложности", например, с выявлением длительного нажатия кнопок сводят на нет кажущуюся простоту INT-подхода. Павильное решение - периодический опрос состояния кнопок из процесса. Спасибо. :rolleyes:
  12. ... опрос клавиатуры по прерыванию, устранение дребезга контактов.... Подскажите как, с точки зрения RTOS, поступать правильнее : а) в прерывании от кнопок "сигналить" процессу, а уже в нем вводить паузу через Sleep(..), счивать скан-код, разрешать прерывания. б) паузу вводить в прерывании, там же получать скан, разрешать прерывания и, как писал в форуме dxp, отправлять процессу сообщение (а не флаг). ... Если "б)", то чем реализовывать паузу? недостатки способов относительно друг друга (на мой взгляд): для "а)" - сохранение контекста процесса обработки кнопок при "падении" в спячку (для реализации паузы); работа с прерыванием (разрешение прерывания) в процессе, а не в теле прерывания /"..баня, а через дорогу раздевалка.."/ для "б)" - "длинное" прерывание.
  13. Конечно, как и вычисление иттераций при реализации метода Ньютона.. :) Но в этом случае задача видоизменяется в задачу написания своей библиотеки. Стандартные библ. работают с плавающей точкой (возможно не все). Спасибо! :a14: Лежало на поверхности, но "глаза не видят" и "мозг не думает". Спасибо за идею! :) .... Попытаюсь "переписать" ответы: Главное - преобразования присутствуют везде. long - приведение к заданной точности, float - приведение к одной экспоненте и нормализация результата. При этом работа с целыми быстрее. "Итого:" Если применение "плавающей точки" не продиктовано использованием готового кода (библ.) То для написания более "быстрого" кода, необходимо использовать "фикс.точку". А для приведения целых чисел к заданной точности использовать умножение/деление не на 10^n, а 2^n. Если же скорость работы про-ца достаточна (или есть встроенный FPU), и точность вычислений обеспечивается разрядностью мантиссы, то - "плавающая точка". .... Спасибо. С Наступающим! Удачи! :)
  14. Согласен. С точки зрения кода это, безусловно, и быстрее, и короче (чем умножение/деление на 10^n) - умножение и деление на 2 это, как известно, сдвиг, который длится 1 такт (с учетом разрядности МС конечно), но, тем не менее, это лишние, избыточные действия о которых НЕОБХОДИМО помнить при написании программы. А как быть если в различные моменты работы программы нужна разная точность? Передавать функции точность вычислений в качестве аргумента? Или писать несколько функций? Опять в "крайности"(сложности). Конечно, "тригономертию" без float ни как, но где та грань (водораздел, ватерлиния) когда "уже нужно"? Возведение в степень, деление..? ... Хорошо.. тогда так: допустим, необходимо вычислять такую фунцкию y=(x^2 + k) / z Вроде "МАТЕМАТИКИ" нет, но если не использовать float, то сразу возникает, как минимум, один вопрос: с какой точностью нужно производить вычисления? А если достаточная точность неизвестна перед началом программирования, да и вообще, может быть различной? ...... ...... Если попытаться ответить на вопрос топика, то правильно ли мнение, что: В случае, когда необходимая точность вычислений известна и не меняется, и математические формулы ограничены четырмя основными арифметическими действиями (+, -, *, /), то целесообразно применение long переменных, с соответствующими преобразованиями. В остальных случаях лучше, правильнее применять float.
  15. Не хотелось бы "углубляться", но... например. Один вариант - нужно расчитать значение и вывести его на индикатор. Выводить в формате плавающей точки ("1.234E-2"), согласитесь, не привычно для "глаза". Нужно точку "фиксировать" (0,01234). Другой вариант - нужно на расчитанное значение позиционировать, например, инструмент станка (руку робота и т.д.). И опять придется переводить float значение к единицам позиционирования (к ЦЕЛОМУ их числу). (А если дискретность перемещения не имеет 10-ное основание, то преобразование еще "длиннее"). Т.е. на лицо необходимость "обратного" преобразования float -> long. /НO!, вместе с тем, функции, написанные с использованием float, проще для "понимания", переносимее, универсальнее, если хотите./ Что может быть разным в этих вариантах? (с точки зрения работы с float) Каких именно? И еще одно уточнение... Вопрос достижения заданной точности не рассматривается. Хочется сравнить LONG v/s FLOAT /оверхед & скорость/