Ruslan1

TVS у меня и так установлены. Работает нормально, вроде не мешает. А почему тогда в документации сказано нарисовать, но не ставить? Я думал, что эти индуктивности-конденсаторы ставятся в особых случаях, а тут выходит что юзергайд обманывает и их нужно ставить всегда? Хм...

Как с этим бороться? Я не могу проконтролировать что в поле делается, но хочу чтобы гарантированно не вылетало, при работе без антенны или с несогласованной антенной. Меня применительно к SIM7600 волнует, но вероятно это общее правило. Пока что ни разу такой проблемы не видел, но у меня реально в работе не так уж много Симкомов. Схема ниже. Но 'nc' - это неустановленные элементы, получается что один голый TVS работает. Все строго согласно даташиту. Что делать, срочно припаивать?

Так этта... Нету деталей- есть время потрепаться, есть детали- нету времени.... Опять же две кривые....

Все всегда упирается в деньги и время. Если посчитали, что переход на новый МК (или ПЛМ) выгоден- то да, его нужно делать. И чем сложнее изделие, тем проблематичнее такой переход. Но чем больше тираж- тем больше вероятность перехода. Эти кривые где-то пересекаются, и вот эта точка у каждого изделия своя.

Нет. Обычно дешевле купить старый МК в 10 раз дороже чем все переделывать. Правда есть у знакомых опыт съезжания с (кажется) простых STM32 на китайские аналоги, вроде получилось. Но это очень сильный стимул должен быть, да и задачи там несложные.

Неудачный пример. как раз это решается на уровне драйвера модема. У меня сейчас есть поддержка двух модемов, один из которых работает по разным протоколам мультиплексирования, все особенности спрятаны внизу- задачи уже не знают о протоколе ничего. Причем, если правильно помню, решено на уровне задач: запускается поддержка нужного модема, и никаких дополнительных накладных во время работы нет вообще. Точно так же, уверен и с USB, драйвер все решит. Не вижу совсем проблемы. Конфигугируете в своем устройстве что тут протокол#1, там- протокол#2, и вперед. Как сконфигурируете- ту часть кода и запустит. А прошивка одна и та же. Если же не код раздут и перестал помещаться в память- то да, нужно делить. Других причин множить прошивки не вижу. Почему? повторяю, для совсем жестких времянок это делается на этапе запуска программы: одни куски кода включаются, а другие нет. Например, устанавливается указатель на вызываемую функцию, соответсвующую используемому железу. Это делается один раз в начале работы и никак не влияет на производительность системы. Я имею опыт поддержки именно таких "франкенштейнов". И да, были случаи когда выстреливало "у старого заказчика" как Вы описываете. Но никаких проблем в отладке таких вещей нет, но нужна внимательность. В общем случае, этот путь "одна прошивка для всех случаев" экономически выгоднее (и в разработке, и в сопровождении), чем "своя прошивка для каждого железа". Про "распараллеливание саппорта" вообще жестоко, это ж как Вас достали "умельцы", если Вы это благом считаете....

Если это так сложно получается и реально влияет на надежность работы- то, конечно, так делать не нужно. У меня в одном проекте нужно было обработку делать по нескольким стандартам, применяемым в разных странах. То есть принципиально разные заказчики, и вполне можно разные прошивки. Но получилось сделать все в одной прошивке, через конфигурирование- и это неожиданно оказалось востребовано, вплоть до одновременной обработки входных данных по разным стандартам. И никакой головной боли в разработке: просто еще одна задача, которую запускают. Само собой, нужно проверять как работает и считать ресурсы, но по сравнению с поддержкой двух отдельных форков это мелочь мелкая.

"Непросветный лес прошивок" как раз и есть ночной кошмар саппорта. Прошивка-одна, поддерживающая все что эксплуатируется под этим названием.

Да, именно так. И пользователь даже не знает какая версия платы у него стоит, это задача разработчика софта сделать так, чтоб переход прошел безболезненно. Например, у меня в одной конструкции уже давно ставится 32МБ RAM, но для совместимости со старым железом всегда используются только первые 8 МБ (стараемся, хватает). Инициализация, конечно, разная. Таким образом, очень старая прошивка (которая не знала о версии плат с 32МБ) не будет работать на новых платах- напишет RAM Error на дисплее. А новая версия на старых платах работать будет, потому что она поймет что там за память. Или вот еще пример- подключаются платы с двумя разными модемами. Конечно, это задача софта определить какой модем подключен и правильно с ним работать. Или например улучшили кое-что в обработке (ушли от однополярных тестовых сигналов к двуполярным кое-где в аналоге)- ну так это опять же задача софта протестировать и понять какой из вариантов железа установлен, и обрабатывать в зависимости от версии железа. Я долго еще трындеть на эту тему могу, у меня историй много :) Тут принципиальный момент- софт должен иметь возможность однозначно определить, какая из поддерживаемых версий железа используется, косвенно (по отклику системы на подаваемые сигналы, как в случае с изменением аналоговой части) или напрямую (если железо выдает какой-то идентификатор, например в случае с модемами). Кстати, в одном сложном проекте изначально, с самой первой версии, заложили на каждую из разрабатываемых плат I2C флешку 2 кбита и общую шину, чтобы хранить, например, версию железа, которую центральный процессор может прочитать. Флешки паяются, но до сих пор ни разу эта фича не использовалась- обходимся без подсказок. Я бы сказал, не больше десяти версий для сложных систем, и не более трех-четырех для простых. Причина: в простых сразу все уже можно придумать так, что улучшать особо некуда, это уже другое устройство будет, а не новая версия. А вот в сложных могут измениться условия игры, да и просто гораздо больше степеней свободы, всегда есть где еще подкрутить. Но у всех своя специфика, кому-то и вторая версия уже катастрофа

Ну, это вообще легко. ПО одно и то же (новое), но если железо не позволяет- то нектрорые функции не стартуют и, соответсвенно не занимают ресурсов. Динамическое выделение памяти, запуск задач по условиюи прочее. То есть оно всегда есть в прошивке, но работать будет не везде. А если новое ПО физически не может быть размещено на старом железе- то об этом должен думать бутлоадер на этапе замены прошивки (или на этапе загрузки) Ад для снабженца- если низкое качество разработки приводит к большому количеству ремонтов. При чем тут количество версий?

Ну, у всех разная специфика, мне проще на складе готовые платы держать.

не хотел. FTDI влепить проще, чем еще и USB поддерживать в софте. Ну, у меня с документацией все в порядке, никаких проблем с поддержкой "зоопарка" нет :)

Привыкайте. Это теперь такое развлечение, проверять для каждого изделия что дешевле: искать комплектуху для старой платы или переразвести под то что еще есть на складах. Я уже две платы в этом году так переделывал, и сразу в серию (ну, серии у нас мелкие). Например, в одной нужно было согласовать 11 новых позиций и переделать плату под две которые не смогли найти (причем устраивало время 20 недель): - Новый ethernet PHY - новый мост USB/UART Кстати, память я тоже менял: MT48LC16M16A2TG заменил на AS4C16M16SA-6TAN Но это без изменения платы, просто даташиты аккуратно проверить нужно. Ну и процы по примерно 40 это Вам крупно повезло.

Я понимаю. Для меня это вершина, от которой есть куда идти вниз :) А, я еще и не смотрел подробно. Подумал что ух ты, ядро 3.3 вольта. Но если так, то, конечно, нужно считать тепловыделение и думать надо ли оно. Но такая возможность может быть полезна- если тепла мало, то почему бы и нет, экономия в номенклатуре (если это 1.2 больше никому не нужно).

Мда. куда катится этот мир. Вижу 1NR-4 c такой памятью на моузере начиная от 20 баксов поштучно.... да и еще есть версии с ядром на 3.3 вольта, а не только экзотические (для меня) 1.2. Да и корпуса QFN и даже LQFP Надо чтоб их срочно кто-то поругал, так не бывает чтоб не было нюансов. Фиговая среда разработки? несоответствие документации и реального камня? Какое-то уж очень масло маслянное... Даже у рекламщиков должны быть заготовлены "ругалки", не умаляющие достоинства товара, но успокаивающие потенциального потребителя. Вроде "к сожалению, эта коробка уже после миллиона километров пробега нуждается в замене масла".

Ага Спасибо, обнадежили. Посмотрел по диагонали их проспекты- много есть в корпусах с шагом шариков 1 мм. И даже QFN и QFP, что еще лучше: как правило, экономия места на плате не так важна, чтобы именно BGA ставить, ну и на этапе макетрования проще если ко всем ногам доступ есть и перепаять легко.

Кто-то подскажет из практики, что самое пузатое из GOWIN (наверное не-BGA ?) еще нормально можно развести на 4-слойке? Или можно и небольшие (малошариковые?) BGA на 4 слоях использовать и я зря их стороной обхожу? Частоты большие не ожидаются, но хотелось бы, например, иметь в перспективе возможность внешнюю SDRAM прикрутить, хоть на 50-100 MHz.

Да, согласен. Пусть в худшем случае программа накидывает +500мс на любое чтение (хотя на самом деле думаю нет), я не знаю как оно внутри сделано. Но посмотрите на разницу между блоками- 600 миллисекунд для некоторых из них. И это уже вряд ли программа так избирательно время увеличивает для одних и не увеличивает для других (ну и на разных картах картина разная).

Молодежжж. Вот помню напишешь чего-то в Фидо в руембеддеде например - и ждешь пару дней чтоб люди хоть прочитали.

Я имел в виду: SD карточка использовалась, и на нее что-то записывали (FAT32). А потом проверил ее на скорость чтения разных блоков. В результате получил таблицу, в которой написано время доступа к каждому из блоков. Отсортировал "с бОльшего к меньшему" и увидел самые "тормозные" по чтению блоки вверху таблицы. Проверил несколько раз- ситуация стабильная. Вот, например, одна из карточек. Elapsed time - это время доступа в миллисекундах. По дефолтовым установкам, блоки с таким временем доступа считаются "Normal" Нет. Так работать может быть и будет, но недолго и не всегда. Будьте готовы ждать сильно больше. Например, упомянутая мной программа считает блок нечитаемым, если доступ к нему невозможен в течении 5 секунд. Но в Вашем случае я бы сначала взял многоканальный логический анализатор, и помедитировал над картинками- там сразу видно, что и когда тормозит конкретно в Вашем устройстве с Вашей программой. Может, дело вообще не в карточках, или их вклад в замедление не так критичен, как другие задержки.

BUSY не одновременно? нет, побороть невозможно: карты разные, каждая работает со своим флешем, и у каждого флеша свои заморочки (с момента изготовления и накопившиеся во время использования). Даже теоретически, этот эффект просто обязан быть, а не только "возможен". Стратегически неправильно надеяться, что карты поведут себя одинаково. Именно так. Абсолютно непредсказуемы. И меняются со временем. Для развлечения можете попробовать программы типа "DiskGenius" - он умеет проверить карту на bad blocks, и одновременно можно получить табличку, сколько времени к какому блоку шло обращение. Это время разное по карте, и оно меняется во время эксплуатации: у вполне рабочих карт время доступа может составлять единицы секунд к некоторым (часто используемым) блокам. И это я про чтение, а не про запись!! :) Так что Вы должны быть готовы к ожиданию, причем рандомному и большому. Самый оптимальный способ при общей шине: пихать в карту данные до получения сигнала занятости, а после этого переходить к работе с другой картой. Как раз пока с другими работаете, эта может уже освободиться. Причем бегаете по кругу, пропуская те карты которые все еще заняты- так можно добиться минимального простоя в ожидании. Само собой, следующие записываемы данные (хорошо если кластер) должны быть всегда готовы к моменту следующего освобождения карты, чтобы не терять время на подготовку. Кстати, убедитесь что используете не CMD24 (WRITE_SINGLE_BLOCK), а именно CMD25 ("WRITE_MULT_BLOCK"). Не, так у Вас быстро не будет. Каждая карта должна иметь свой буфер (ну или свой указатель чтения в общем буфере), и работать со своей порцией данных.

Я таким путем тоже ходил много лет назад. Сначала ПЛИС передавала у меня через SPI в ПИК, потом по параллельной шине предоставляла доступ для ADSP-21, потом я к ней Блэкфин (533 кажется) с линуксом внутри подключил (и написал в ядро мой драйвер для общения). А потом все заглохло: стало хватать одного МК для всего вокруг, а ПЛИС стала лишней сущностью. Склоняюсь к тому, что "не шмогу" доказать нужность железячного ядра внутри FPGA для моих применений вместо МК с большой функциональностью. А вот просто FPGA да, все еще хочу добавить в новый проект как часть, обеспечивающую RTOS (заместо планируемого STM32F0). Там наружу ничего хитрого не планируется, я и врукопашную смогу без микроядра все коммуникации и обработки нарисовать на стандартных мегафункциях, или на VHDL. Попробую выбрать ПЛИС, которая мне уже годится для моих первых хотелок, но и вдруг еще минимальное ядро чтоб можно было всюнуть для тренировок. Ну или просто два кита с разными ресурсами (но, конечно, одной фирмы).

Нашел статью которая очень понравилась, как раз для таких как я, ликбез : https://numato.com/blog/differences-between-fpga-and-asics/ Но я даже не знаю, как правильно назвать микросхему, в которой есть и конфигурируемые ячейки, и железячное ядро в одном флаконе? "ASIC&FPGA"?, буду читать википедию.... Я именно про железячную имплементацию, а не про заливку в FPGA ядра. С заливкой понятно, отжираются ресурсы на ядро и остается непонятно что, потому и жирные FPGA нужны. А вот если там внутри ASIC кортекс, да плюс ресурс FPGA под всякую синхронную параллельную работу (и под интерфейсы для ядра), то интересно. А что дешевле и доступнее, чтобы после заливки ядра осталось ресурсов под интерфейсы и прочее : 1) микросхема "чистый FPGA", в который я залью ядро Кортекса, 2) микросхема FPGA с дополнительным ASIC того же кортекса внутри ?

Да, я уже прикинул- это реально большие объемы работы. Если бы все было так просто- производители процессоров бы давно обанкротились, все пользователи бы на ПЛИС перешли. Текущий аллокейшен сдвигает планку в пользу ПЛИС, но недостаточно. Очень интересны ПЛИС с встроенным АРМ ядром.

Как-то я упустил из виду вопрос, с которого наверное нужно было начинать: о доступности программных средств и их удобстве. Я много пользовался МаксПлюсом, немного Квартусом, и мне их хватало и все было очевидно. Забивал микросхемы 1К под завязку своими схемами и мне хватало мегафункций альтеровских, да и байтбластеры LPT-шные легко паялись на коленке. Воспоминания только положительные. Ну и "откорректированные" версии софта для работы (да и ключики) легко находились в Интернете. Думаю, что после Альтеры в софте от Квартуса я тоже разберусь - они прошли большой путь бок о бок, и вряд ли сильно друг от друга отличаются в базовой функциональности (как Пикады и Оркады, например). Но что про китайских товарищей? их софт работает и достаточен? Мне не нужно фильдеперсовости, мне интересно можно ли им пользоваться, или нужно принципиально меняться, по сравнению с Квартусом, например? Из практических задач первое что собираюсь сделать- это работать на уровне мегафуккций, может быть описывая свои через AHDL/VHDL (надеюсь эти языки, как сам термин мегафункций, еще живы?). Уже рисую проектик под такое применение: собрать данные со многих потоков (например, АЦП), минимально обраьлотать (децимация, может быть масштабирование и фильтрация), и сделать доступными для чтения как массив (шине данных) или передача единным потоком наружу (например, SPI). Уверен, что могу набросать такое мегафункциями, без всяких ядер. И многопоточность выглядит естественно, и нет ограничения по количеству таких потоков (в пределах ресурсов ПЛИС). Вы правы. Нужно с софта начинать. Но важно понять- с какого именно софта, чтоб потом не переобуваться во время прыжка. Я имею большой опыт работы с Альтеровским софтом, но старым (лет 10-20 назад). Понимаю, что добавили и обновили, но, надеюсь, идеология осталась прежней.