Jump to content

    

Ruslan1

Свой
  • Content Count

    2646
  • Joined

  • Last visited

Community Reputation

0 Обычный

About Ruslan1

  • Rank
    Гуру
  • Birthday 01/09/1973

Контакты

  • Сайт
    Array
  • ICQ
    Array

Информация

  • Город
    Array

Recent Profile Visitors

10238 profile views
  1. Спасибо всем, буду думать в рабочее время. 1. если сделать как однажды сделанную функцию с установленным динамически числом аргументов- то все уже придумано до меня, это массив, созданный с помощью va_list() для vsprintf(). 2. Если упрощать "в лоб"- то отказаться от strstr(): переконвертировать строку, оставив признак ключа (у меня это '/') и после него один единственный байт, уникальный для каждого ключа. Метод работает для 253 ключей, что меня сейчас более чем устраивает. Тогда простым 'switch-case' решается. Первый метод быстрее, но посмотрю получится ли так как я хочу, и сколько занимает в памяти этот сформированный va_list массив: у меня строк много разных, и может быть критично если массив сильно (в дестки-сотни раз) больше чем сама оригинальная строка.
  2. 18.6 миллисекунды на строку. Но когда нужно сформировать тысячу-другую строк, набегает много. Время зависит от многих параметров, в основном- какой длины строка парсится и сколько ключей возможны: получается, что встретив новый ключ в строке, я его сравниваю с базой, применяя strstr(). То есть если у меня база из сейчас 120 ключей, то для каждого встреченного ключа это от одного до 120 вызовов strstr() . Можно оптимизировать сам метод, но лучше уйти от бесконечного парсинга. И меня не столько парсинг строки формата волнует во время sprintf(), сколько этот вот парсинг ключей для списка параметров, который и съедает все время. А формат и строка параметров у меня постоянные до следующего выключения, то есть создав один раз списки, надеюсь что vsprintf с ними быстрее будет работать чем я с исходными текстовыми ключами.
  3. Здравствуйте! Дано : есть конфигурационный файл, задающий формат генерируемой строки с использованием разных 'ключей'. Во время вывода эти ключи подменяются конкретными величинами. Количество ключей в строке может быть разное. Например: конфигурация String1 = "\dat \time, \SNum, V1=\Val1, V2=\Val2" превращается в выводимую строку "2021-04-01 00:22:15, 103567, V1=17.2, V2=0.4" Сейчас это делается парсингом строки конфигурации онлайн во время каждой печати строки, символ-за символом, с заменой встреченных ключей на из значения. Но это реально долго (у меня десятки ключей). Хочу ускорить и не делать парсинг каждый раз. Идеально было бы однажды пропарсить конфигурационную строку и создать что-то, что можно просто вызывать каждый раз, когда эту строку нужно напечатать. Для данного случая, например это будет: sprintf (txtOut, "%s_%s, %06d, V1=%.1f, V2=%.1f", date, time, SERNUM, Val1, Val2); но как это сделать? Нужно решить задачи: 1) создать строку формата (в примере это ["%s_%s, %06d, V1=%.1f, V2=%.1f"]) - это самое простое, это я понимаю. 2) создать строку аргументов (в примере это [date, time, SERNUM, Val1, Val2]) - не представляю как это сделать. Ну, могу создать массив указателей на нужные величины, но как это использовать? 3) запустить это как sprintf() - подозреваю, что если будет ответ на предыдущий вопрос, то этот уже просто решается. Вроде бы подходит vsprintf() и va_list ? Если я правильно понял, то для vsprintf() можно однажды создать список параметров va_list c указателями на расположение нужных мне величин в памяти, и дальше просто вызывать vsprintf() столько раз сколько нужно? Так?
  4. Никаких проблем. Смотрите на параметры шлейфа/контакта, и полученное теоретическое количество необходимых контактов умножаете на [зависит от доверия к производителю, но не менее чем на 2]. Я для токов примерно 1 А/12V использую в параллель 4 провода для питания (ну и как минимум столько же для GND). Длина 10 см. Для долговременного использования еще очень важно покрытие, агрессивность среды и вибрация. По моему опыту: со временем может увеличиться сопротивление между ножом разъема и проткнутым шлейфом. Но видел только в слаботочке, как раз токовые нагруженные соединения работают стабильно.
  5. А что, от скорости набора текста хоть как-то может зависеть скорость написания программы или скорость написания научной статьи?
  6. Как же хорошо на душе что есть еще люди, этим занимающиеся. Я без сарказма, только с завистью. Удачи вам, не утонувшие в нашем сером меркантильном потребительском бытии!!
  7. А у меня первым языком Фортран-4 был, на ЕС ЭВМ (PL/1 еще можно было применять, но посоветовали Фортран). Но последнего программера, реально пишущего на Фортране, я лет 10 назад видел. Но это не значит что их нет. Вспомнился старый анекдот, даже в сети его нашел:
  8. Ну так классика жанра: 0. Отладчиком увидеть что именно приехало в микроконтроллер, на этом этапе можно спланировать что копать дальше. 1. Убедиться что сигнал физически ушел с разъема компьютера: Подключить подслушку (терминал на прием, или логический анализатор), ну и осциллограф для тяжелых случаев. Если не выводится физически- может потому что хардверное управление портом включено (hardware flow control). Ну или таки порт занят и не отпущен другим софтом.
  9. Тоже подозреваю что это и есть какой-то "Noise Floor", цифры похожи на NLNM (New Low Noise Model) по Петерсону, используемые USGS. На эту модель равняются, когда смотрят диджитайзеры для сейсмики. (ниже картинка с реальными шумами из одного старого доклада USGS).
  10. вот прислали приглашение на это: https://www.embedded-world.de/ Я так понял, в этом году там пиво пить не будут. Ну, разве что виртуальное завезут по дешевке....
  11. А что, есть разница сколько центов МК стоит, 40 или 70 ??? На фоне стоимости работы это вообще разговор ни о чем. Подозреваю, что за время обсуждения ТС уже потратил времени на сумму, превышающую любую теоретически достижимую экономию от оптимального выбора. А если всех читателей и их время посчитать- то можно и планку стоимости до пары долларов поднять :) Просто нужно выбрать известный МК из дешевых, сделать и забыть (так как задача простая). И идти дальше. На простых задачах и доходы мизерные, обсуждение дороже стоит. Под "известный" я имею в виду не только среду сам камень, но и всю логистику. Часто сильно выгоднее делать на уже используемом неоптимальном, чем на новом супероптимальном, но неизвестном.
  12. Левый какой-то даташит. Разве что есть дополнительные документы (appNote, EVboard etc.) где это дополнительно описано, но я ничего не нашел для этого семейства. Никто кроме производителя не ответит на Ваши вопросы. И испытания могут только подтвердить, если так делать нельзя. А вот если испытания покажут что все окей- так это верно только для тестируемых образцов. Так что не нужны испытания, они не помогут вам перейти на малую емкость. Так что вариантов всего два: 1. Оставить как есть (работает по даташиту- не трогай). 2. Спросить у производителя. Но мало ли кто и чего ответит: я бы не особо доверял, разве что в связи с Вашим вопросом они новую ревизию даташита выпустят, и вот ему уже можно доверять. Я думаю, путь (1) является самым простым, если нет особых причин что-то менять. Ну и 10 мкф на входе- не так уж и много, тем более если большое выходное сопротивление источника и еще провода.
  13. вдогонку, из личного опыта с 5-вольтовыми дисплеями: 1. это напряжение очень индивидуально, и иногда меняется в следующей партии дисплеев. 2. Может быть необходимо изменить это напряжение при изменении температуры окружающей среды. 3. диапазон нужных напряжений очень узок и обычно близок к 0. 4. это напряжение может быть как отрицательным, так и положительным относительно VSS, Так что делаю инвертор на пине микроконтроллера (выход таймера), а напряжение регулирую изменением частоты сигнала и ШИМ. что-то вроде схемы, приведенной ниже.
  14. Кстати да, и указатели на функции обработки тоже часто храню в структурах. Получается быстро работающий код, в котором все "экраны запихивания в структуры" делаются однажды на этапе инициализации. К своему стыду, так и не перешел к использованию С++ как языка с его идеологией. Сначала это были объективные причины, а теперь просто нет желания что-то менять в этой жизни, не вижу профита от таких потрясений. Наверное пенсия скоро- не хотят нейроны на новые орбиты выходить.
  15. А что, еще кто-то хранит много взаимосвзязанных (используемых вместе) данных не в структурах? Если данные связаны между собой (например, массив и указатели записи-чтения в нем) - то они и до вызова функции храняться всегда в структуре, а не как отдельные переменные. Компилятору все равно, работать с wrpnt и buf[] или с transmit.wrpnt и transmit.buf[]. А если данные несвязаны и поэтому не собраны в структуру- то нужно подумать, почему они в одну функцию передаются, может нужно разбить функцию на несколько? Да и не проблема передать в функцию два или пять указателей на разные используемые структуры, если уж нужно. Но если эти пять структур используются вместе более одного раза- я бы собрал указатели на них в одну новую структуру :)