AlexRayne

Ищу: работу на полный/неполный день в СПб в пешей доступности офиса от метро (до 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. или писать alexraynepe196@gmail.com

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

По моеиу опыту, китайцы из чип-дипа, может и годны для крупных клемм, но вот мелкие - на авг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, или разлочил мутех перед ожиданием сигнала.

Насколько я понял, Вы используете мою ветку ядра. Специально для ожидания данных из прерываний я ввел bool_t mutex_wait_until (mutex_t *m , scheduless_condition waitfor, void* waitarg ) она позволяет не уходить в ожидание сигнала от прерывания, если по факту есть данные. Это позволит избежать пропуска прерываний. Функция waitfor выполняется атомарно, в ней можно проверить - есть ли в уарте данные.

А ваше прерывание не реентантно? текущий обработчик мутехов mutex_activate не реентантен - он не должен прерываться и вызываться внутри другого прерывания. операции с очередью задач task_active должны быть атомарны. если есть сомнения, можно вставить асерт в mutex_activate на вложенный вызов и убедиться срабатывает ли он. if (test_get_receive_data(u->port, &c)) { mutex_lock(&u->receiver); switch (c) { case 0xff: Вот этот код както опасно выглядит: сначала получаются данные, а потом ожидается прерывание? и потом полученные данные обрабатываются?

И отладчик не работает?