Jump to content

    

turnon

Свой
  • Content Count

    475
  • Joined

  • Last visited

Community Reputation

0 Обычный

About turnon

  • Rank
    Местный

Контакты

  • ICQ
    Array

Recent Profile Visitors

3687 profile views
  1. Это с какой стороны посмотреть. Если взвалить на программиста непосильную для него задачу - родит монстра.
  2. Wear leveling там вроде только для NAND/NOR. Ну я и не планирую закладывать SD в устройство, это рулетка.
  3. Значит TC надо посоветовать не отвлекать программиста, использовать FatFS как есть и не морочить голову
  4. При чем тут FAT? Для выравнивания износа и устойчивости к сбоям там свой слой поверх SPI драйвера флешки. Интересно, приведите пожалуйста пример такой системы и сколько это стоит. А почему не могут быть реализованы в одной библиотеке эти совершенно разные фичи?
  5. spiffs, как и LittleFS не вызывает доверия, куча issues. К тому же в spiffs не заявлено устойчивости к сбоям питания. Ну и похоже автор тоже "ушел в туман", версия 0.4.0 уже наверное года два как в ожидании.
  6. Да, фичи заявлены красивые. Только уже вторая версия со сменой метаданных вышла, а количество глюков только растет. Разработчик зарылся. Реальное использование к сожалению невозможно. Ну и список проблем это тоже подтверждает. Отсюда: Тоже потратил кучу времени на этот литтлфс. Перспектив не вижу, список багов растет, их описание пугает. Автор опять "ушел в туман". Начал искать другие варианты. Нашел два: filex/levelx из Azure RTOS и uS-FS от Micrium, в обеих заявлено и выравнивания износа и устойчивость к сбоям. Сейчас портировал оба варианта, тесты на симуляторе проходят оба варинта, осталось испытать в реале. uS FS выглядит намного качественнее, внутри все очень документировано, не видно говнокода. Azure_RTOS_FileX_User_Guide.pdf uC-FS Documentation V40700.pdf
  7. Почему-то ембедеры осваивающие C++ пытаются сразу применить все его изученные возможности. И выходит то же самое что на С, но с кучей классов и виртуальных методов и разочарование в C++ и обвинение в "оверхеде".
  8. Именно. С релизом проекта надо фиксировать и версию библиотечного репозитория. А изменения в библиотечном репозитории уже переносятся в ранние версии процедурой слияния (merge). А иначе больше проблем будет от "супер Common" библиотеки. Проект - это набор всех файлов необходимых для сборки, причем согласованных версий, а не просто что-то там подтягиваем.
  9. С вырезами. Сбоев за полгода не было. Скорее это влияние четырехслойки, а не вырезов. Ну и я там еще на питание МК поставил проходной конденсатор.
  10. Не путайте. @Orc писал о зазоре в 0.6 мм от полигона с целью избежать "замыканий при пайке"
  11. Да, средний заказчик обычно хорошо знает функциональные качества устройства, но никак не может оценить качество трассировки и схемотехнические решения. Видел как пускали в тираж автотрассированные платы, разработчик даже не пытался ничего разводить руками - примерно раскидал компоненты и запустил Auto Route.
  12. Спуститесь на землю. На такие изделия заказчик обычно дает листик с надерганной из инета функциональностью. Он понятия не имеет ни про ESD ни про EMS. Тем более такие испытания ему выйдет на порядок дороже самой разработки платы. На заре своей деятельности обращался к сторонним разработчикам электроники. Разброс предложения был от 100 баксов и срока месяц до 1 млн рублей и срока 1 год.
  13. Это @Orc высказал, что от полигонов надо делать больше отступы. Я не понимаю, зачем.
  14. Месяц? Это похоже что он Altium с нуля осваивает. И ранее не работал с софтом по проектированию ПП. Это все видите вы, а заказчик не в курсе всех этих "тонкостей". Оценит по факту работы устройства (работает / не работает), а если от грозы сдохнет - то разработчику предъявить ему будет сложно.
  15. А у вас и между дорожками 0.6 мм? Почему отступ в 0.6 должен быть только от полигона? А если дорожка рядом с падом проходит и на нее "замкнет при пайке"? Вы можете назначить себе хоть 1 млн/час, но кто же вам их заплатит?