AlexRayne

Я к тому проглобальный клок завел, что одним из важнейших преимуществ асинхронщины считается как раз ненужность глобального клока. В синхронных микрухах - он главная головная боль, и расход энергии/тепловыделение.

Увлечение асинхронщиной на плисе у меня кончилось после того как я сравнил асинхронный и синхронный проекты, простенькие: Асинхронщину очень тяжело отлаживать, гонки убивают всякие гарантии. и даже если будет создан дизайн, его надо обконстрейнивать во всех местах, иначе при разводке на другом кристале все развалится. асинхронщина, ради гонок, требует усложнения дизайна, и посему расзодует сильно больше ячеек. за счет большего количества логики, весь дизайн получается медленнее. а учитывая, то как ведется анализ времянок - тактовые частоты предельные получаются ниже плинтуса. Вобчем посое пары асинхронных дизайнов, быстро приходит просветление - зачем народ синхонку придумал, и парится с разведением глобального клока.

Наверно ни в чем.

а ACK как принимать?

Поправьте меня, может я ошибаюсь? Но вроде КАН предоставляем максимум 8байт данных в пакете?

К сожалению моя плохая привычка, не архивировать вместе с проектом найденную литературу по теме меня подвела. Нет у меня даже намеков на статью. остались только смутные воспоминания: название имело в себе слово predictive (иди prediction). я искал литуратуту по буст-регуляторам для PFC. В принципе статья типового уровня для курса силовой техники института - рассматривает работу импульсного регулятора, с особенностями семплирования тока, и немногоо режимах прерывистых/непрерывных токов. Вся эта дребедень есть везде. Основной цимес занимал пару абзацу, идею которых я выше изложил. Ну и экспериментальное обсуждение результатов: если кратко то получается регулятор без инерции и колебательности, присущей ПИДам. А постоянный и предиктивный (там расчитывается ток который получится после планируемого шима) контроль тока, позволяет ему гарантированно избегать насыщения дроселя. Но вычислительно это весьма затратно - надо проворачивать петлю измерений-вычислений каждый шим. Что в те времена могли себе позволить только приличные ДСП. свистелки уровня атмеги такое управление не вытягивали.

Ну я попробую найти статью, но 10лет тому уж жто было. Нет, там идея прямо от физики идет - если нам известны все параметры, то мы все можем прямо расчитать, а не подбирать последовательно приближаясь пидом. В бак или буст преобразователе всего один дросель, и емкость - так что уравнения описывающие ток дроселя не выше 2го порядка. А если мы работаем в малых приращениях (напряжение скжем меняется небрежимо медленно) - то они вырождоются в производные 1го порядка. Конкретно я регулировал именно ток дроселя. Для него формула же очень простая dI/dt = Ul * L, кажется из него получается сразу вычислить dT , и если поколдовать с единицами измерения и множителями, то можно прямо из АЦП в шим пересчитывать. К этому надо добавлять калибовочные поправки - на нелинейности ключей, дедтаймы... Формула вполне точна, на больших сравнительно токах. В малых токках выходит на прерывистый режим - это даже более простой режим (нет опасности дросель в насыщение загнать), но в момент перехода меняются характеристики регулирования. (это от точки семплирования тока зависит) в совсем малых токах начинают превалировать нелинейность ключей, или скорее дискретность шим. Но в этих местах я почти не работал, не успел дойти до вылизывания проекта. И этим уже должен был заниматься как раз пид.

Если у Вам надо хорошую импульсную обеспечить, то любыми ОС Вы получите довольно птличную инерцию, и чем медленее импульсная, тем точнее выходное. Раз у Вас есть известная индуктивность, наверняка вы меряеье напряжения и перед и после дроселя - т.Е можете оценить напряжение на нем. Тогда Вы можете применить предиктивное управление - т.Е. вычислять скважность по требуемомк току и напряжениям на дроселе. В моем опыте это требовало всего одного деления.

это Вы со своими сверстниками меряйтесь. я пожалуй мимо пройду...

Встречал галюны зависания и2ц на некоторых камнях (не стм) изза глючного ядра. При повышении емкости нагрузки линии чтото происходило с клоками мастера. Специфически это выглядело, но лечилось простым снятием нагрузок с линии - оставлял один чистый слейв, и галюн исчезал.

он же написал - на вход подавать квадрат сигнала. что думаете на выходе будет?

неслучайно не получается. ибо черный-фин прав, а Вы нет.

А Вы смотрели фреймвррк xpcc? Там они сильно в мета закинулись, порты описывать. Не катит их решение?

Ищу: работу на полный/неполный день в СПб в пешей доступности офиса от метро (до 20мин), или удаленку. прошу 80круб Умею: - C/C++ с stl ем и шаблонами. contikiOS, freeRTOS, uOS embedded, keil RTX. PHP - сопровождал рукописные сайты, и joomla. pyton - любительский. delphi/lazarus - умею, но давно не работал с этим. - программировал микроконтроллеры 8051, AVR8, pic33, H8, MIPS32, ARM32. имел дело с интерфейсами uart, rs232/485, modBUS, spi, i2c, can. с периферией - флеш, дисплеи spi, adc/dac, pwm, dma, radio ti cc1200. - в ПЛИС altera cyclon2. - в разработку цифры и аналога. ( Практически разрабатывал блок питания 1.5кВт, 3фазный корректор к нему. ) резюме тут лучше звонить 89522164457 или ватсап, или скайп alexraynepe196. или писать [email protected]

А кто нить сталкивался с мелбканием окна редактора кода? На венде мало заметно, а вот на лине, из под виртуалбокса - ужасно. Бывает что окно стирается и текст возобновляется только если курсор подергать. Замесено на коде С, пхп, питоне, да почти на всем.

По моеиу опыту, китайцы из чип-дипа, может и годны для крупных клемм, но вот мелкие - на авг28 уже дохловаты. Недожимают, или жмут криво. Возможно если купить сменные губки к ним от какогото европейца, они смогут осилить мелкие клеммы. Еще видел что умельцы надфилем доводили губки до кондиции. Но профессиональный кремпер тико, или жст тот же, дает совершенно друго качество. Зато китает конечно универсал - им можно много чего обжать, одинаково плохо :)

это название из мира давно забытого MSDOS

а зачем для вашей зачи виртуалка? почему загрузка оверлея, или elf-объекта не катит?

1) если во время прерывания долетит символ - на него потратится отдельный вызов прерывания и шедулеры. а проверка на наличие символа - копеешная. 2) если вам долетит последний символ посылки, и дальше ваш абонент ждет ответа. Так вот Вы можете и не получить этот последний символ пока не проверите порт. Это в случае если прерывание потеряется, а это много от чего может зависеть в операционке и железе. проверка в коде делает поведение более предсказуемым чтоли.

ну вообчето 5мкс - это максимум, по осцилу видимый, а в среднем 0.5-2мкс было. это время - следствие отсутствия оптимизации атомарного доступа к данным мутеха, все ведется через тяжеловесное блокирование прерываний. АРМ и МИПС имеют специальные инструкции для атомарного теста переменой, и ГЦЦ даже сумеет их из С кода внедрить. но этого никто пока не сделал.

Я практически мерял переключение контекста на МИПС32 - ВМ10Я на 240МГц тактовой. так вот у него до 5мкс доходило время захвата мутекса. Но это специфика МИПСа. и неоптимизированный код мутеха в уОС. Про АРМ летом был разговор - приятель пытался понять можно ли сделать переключение задачи меньше чем за 10мкс (вроде такой порядок там был). повозились, пошарились по форумам, выяснили что лучше чем фриРТОС делает, уже не сделать - у них ассемблерные оптимизированные процедуры все это шедулят. И тоже получалось какоето сумасшествие - более 300-500 тактов это занимает. Вполне соглашусь что чисто прерывание, без шедулера, с оптимизированным прологом, будет занимать ваши сотни тактов и сделает кучу работы. но в реальности в которой крутился я - таких олимпийских рекордов нет. Если касаться СТМ23 - то у них еще очень ударяет по скорости кода латентность флеши. код прерывания лучше переносить в ОЗУ.

На медленных АРМ (до 100Мгц) время обработки прерывания любого 5-10мкс. так что я б сказал что у него обработчик совсем неплох, учитывая что он заодно и шедулинг ведет. во фриРТОС вызов шедулера/прерывания тоже имеет такие порядки. Другое дело что на одим символ - это расточительно так тратиться. надо включать фифо, и обрабатывать пореже но пачку символов прекрасные стеки. надо искать почему портится очередь задач. скорее всего изза этого при переключении он переключается на задачу по какомуто левому адресу. для отладки таких бед я лично накручивал систему контроля целостности очередей, и стеков. жаль что этот код утерян Пожалуй надо такую систему включить в проект уОСи. Сейчас могу Вам только предложить в main.c:task_schedule ввести свои функции контроля качества задачи на которую переключаетесь. и ассертить подозрительные вещи - выход указателя кода за пределы кода, и/или стека за пределы рам. Я думаю стоит потратить время на этот контроль, он очень пригодиться дальше. ибо это имхо не последнее крашение проекта. Имхо, самая вероятная причина потери очереди - потеря указателей, ваш код гдето пишет мимо буферов, и очень удачно крашит очередь. если вы введете глобальных пременных, то поползет раскладка ваших указателей, и портить начнет чтото другое. галюн вылезет в другом месте.

ещё вопрос. Как понять, что приводит к краху ? " попробуйте добавить стекам задач байт по 250?

Диги, оч тяжелый код Вы сделали для этой простой задачи. Блокировки мутехов очень тяжелы на платформе мипс, на арм может полегче. Имхо, все операцию с портом<->очередью стоит вынести в хэндл прерывания. Он выполнится атомарно, на уровне прерывания. А В мутехи приемника/передатчика можно послать сигналы из прерывания, тем ниткам кто их ждет. Имхо, не хватает цикла, выбирающего из очереди порта все что там есть. С проверкой, на наличие в приемнике символов, перед выходом из обработчика. Это может сильно облегчить нагрузку на проц при интенсивном потоке, если не успевапет за приемом.

"Это ошибка выполнения при использовании нерекурсивных мьютексов, на этом месте мы должны вылететь по ассерту внутри mutex_lock. " по идее нерекурсивный мутех должен выдать хальт/останов нитки при попытке повторного захвата, а не полагаться на ассерт? "опять захватывается - попытка захватить захваченный мьютекс! Смысла в этой операции нет никакого: мьютекс и так уже захвачен нашей задачей." видимо он попытался использовать один мутех и для блокировки доступа к буфферу и для сигнала от прерывания? это могло бы проканать как раз еслиб он использовал mutex_attach_irq, или разлочил мутех перед ожиданием сигнала.