Перейти к содержанию
    

Lelikk

Свой
  • Постов

    115
  • Зарегистрирован

  • Посещение

Репутация

0 Обычный

Информация о Lelikk

  • Звание
    Частый гость
    Частый гость
  • День рождения 18.05.1988

Контакты

  • Сайт
    Array

Информация

  • Город
    Array

Посетители профиля

1 934 просмотра профиля
  1. Вы пнули разработчиков TI? Тогда покажите хотя бы публикацию о Вашем замечательном блоке в каком-нибудь серьезном источнике на английском. Slope compensation имелся в виду как возможность присутствующая в блоке CPMSS для реализации режимов peak-current mode control. P.S. ваша сверхценная идея будет невостребованной, так как аппаратный PLL стоит дорого, занимает место, а поставленную задачу легко выполнить другими способами. В контроллеры обычно ставится та периферия, которая востребована в решениях реализуемых на рынке - дело не в том, что разработчики IC чего-то не знают, а в том, что они умеют считать деньги.
  2. Это вы неважно разбираететь с микроконтроллерах для источников питания :) Там есть уже давно и компараторы, и slope compensation и все остальное, например TMS320F280049
  3. Всегда последняя, так как в ней баги чинят от предыдущих. Иногда странные глюки могут быть, если открыть и продолжать дизайн, сделаный в альтиуме 2014 или около того года. Так что новые версии для старых проектов нужно с осторожностью, но новые проекты всегда лучше в самой последней версии начинать.
  4. Вы понимаете, что это минимум 3 года работы опытного коллектива? И от 3-4 миллионов в долларах... ну если конечно нужно, чтобы он в реальности надежно работал :-) "Индивидуальные разработчики" - это видимо человек-научный центр на гусеничном ходу.
  5. Вы сами верите во что пишете? Конечно, может быть здесь очень глубокая ирония зарыта. Ничего по этим картинкам не сделать полезного, не обладая опытом в этом деле. Как только вы попробуете что-то изменить, не понимая сути, схема сделает booom, ну или будет в защите попискивать, если повезет. Если же вы хотите сделать новую конкурентоспособную вещь - то даже и говорить не о чем...
  6. Это я предложил 5 страниц назад. Автор совершенно некомпетентен, но верит, что компетентен и поэтому по=прежнему ставит задачу в формате, в котором ее решать нет смысла. Он не понимает что такое прерывание.
  7. while без дополнительных конструкций, обеспечивающих таймаут подзволяет зависнуть на неопределенное время в цикле, если в условии стоит ожидание чего-то внешнего. Конечно конструкции типа while(--i) вряд ли могут быть опасными, но я и их обычно пишу как for(;i;--i) goto годится как выход их вложенного for, все равно в ассемблере он таким и будет
  8. Здесь я полностью с Вами соглашусь по обоим пунктам. Просто подтаскивание стандартного инструмента зачастую оправдано только если человек с ним полностью знаком, а если решение совсем lightweight, то лично у меня есть свое не хуже. В общем разобрались и дискуссия редуцировалась до тривиального. А вот в приведенном цикле main не разделены критические и некритические задачи вообще - все работает по принципу "сколько успею", будь это управление аппаратурой или ftp. Поэтому ему не розетками с оборудованием, а только елочной гирляндой я бы доверил управление. Лютый позор.
  9. Вы все с ног на голову перевернули. Изначально я сказал, что для решения исходной задачи (поставленной ТС в том виде, как он ее описал, без неизвестных подробностей) не нужна RTOS. Так же она не нужна для того, чтобы реализовать элементарные связки задач. Если у вас уже есть RTOS, которая другие задачи диспетчеризует, то реализовывать в виде задач LED и UART - это нормально, так все делают. А вот если вы ничего сложнее этого (образно выражаясь) не реализуете - то применение RTOS туда - это смешно. "Фоновые задачи" - это те, для которых строгая периодичность и джиттер некритичны, "не содержат неожиданных блокировок" - это значит что возвращают управление не позже чем через N мкс. Поэтому во многих случаях вытесняющая RTOS не нужна (собственно, одно из ее назначений - позволить исполняемым потокам не думать друг о друге, уменьшая связность в архитектуре системы).
  10. А я с 2012 - будем меряться?))) Ссылочку не дам, так как такой код пишу сам, код сертифицирован. Почему о кооперативной многозадачности - потому что она дешевле в реализации, при следующих условиях: - диспетчеризуются фоновые задачи; - код фоновых задач не написан третьей стороной, и соответственно, не содержит неожиданных блокировок; Применение RTOS в некотором смысле аналогично динамическому выделению памяти - имеет смысл только при превышении системой определенного порога сложности. А конструкции типа - один поток у нас за blinker отвечает, а другой байтики в UART шлет - это студентам в университет. Потом такие люди не понимают, как выжимать производительность из железа и просят для решения любой задачи жирный процессор.
  11. Надо разобраться в терминах блокировки - блокирующая это что? 1. Функция API крутится в цикле, ожидая желаемого ею события запретив при этом прерывания на все время ожидания? 2. Функция API крутится в цикле, ожидая желаемого ею события? Если случай (2), то ничего не помешает написать обмен по SPI хотя бы в прерывании таймера. Тут можно скорее не говорить о боязни RTOS, а о том, что зачем стрелять из пушки по воробьям. RTOS надо использовать когда есть много разных задач, в остальных случаях она только мешает выживать скорость из аппаратуры, так то можно хоть .NET Micro прикрутить, потом поставить MCU помощнее :))) Если нужно просто в background несколько задач обслужить, то невытесняющий автомат запускающий список задач с разными периодами занимает максимум 100 строк. Использовать RTOS не потому что без нее нельзя, а потому что в остальном лень разбираться - это путь в никуда. Никто вашу задачу решать не будет, пока вы решите заплатить нормальные деньги. Обучение программированию в данной ветке вряд ли будет иметь результат в конечном итоге.
  12. Не будет блокировать она ничего - данные будут собираться в прерывании. Если задача действительно ограничивается описанным ТС, то этого неуниверсального решения будет достаточно, чтобы обойтись и без RTOS и не менять прослойку работы с SD. Какой там буфер будет - кольцевой или нет, это вообще мелочи. Но все равно - как ни делай, быстрее 4-5 дней стабильное решение не получится. Так что мечты про 9 т.р. ТС может забыть, а студент будет ему месяц делать в лучшем случае.
  13. Вам не нужна ни RTOS, ни прочие танцы: 1. Отключаете WDT, на время отладки этой проблемы; 2. Обеспечиваете обмен данными с ADC, который на первой SPI шине по таймеру (время конверсии и обмена ведь фиксированные), данные складываете в буфер. 3. Буфер организуете из двух половин, как только одна половида заполнилась - заполняете другую. В этот момент стартует очередная запись на SD. 4. Пока ADC заполняет половину буфера - вторая половина сбрасывается на SD, потом меняется. Размер буфера определяется соотношением максимальной задержки записи (250ms?) и скорость, с какой вы данные накапливаете. 5. Как только это заработает - можно подключать DMA для сброса буфера на SD, чтобы разгрузить процессор для других задач (если они есть). Тут достаточно одного ядра с огромным запасом. Можно еще один канал DMA и для ADC задействовать, только смысла нет.
  14. А потом вы узнаете, сколько будет стоить производство так и так и думаете: одно дело Coilcraft, который делает продукцию миллионами на продажу и другое дело серийное, но кастомное изделие, для которого вакуумная заливка не оправдается по сравнению с многослойной ПП. Конечно, когда появляются дополнительные факторы (особо малый габарит), то придется пойти на затраты, главное чтобы ваши покупатели готовы были вам это оплачивать :-) Так что делать можно, остальное вопросы конструкции.
  15. Целью является достижение желаемого (устойчиво работающей схемы) с минимальными затратами, особенно в массовом производстве. Поэтому конденсторов надо ставить не более нужного и если можно не пихать их под брюхо в простых схемах (мы обсуждали один из самых простых контроллеров) то лучше их туда не засовывать. Требования к FPGA обычно сильно другие, и сложность ПП там значительно выше, так что не надо стрелять из пушки по воробушкам.
×
×
  • Создать...