Вакансия embedded разработчик (stm32, tms570), SPb, от 80 кр

офис - п. Ольгино. Прямо напротив платформы

Хех.

Сотрудникам выдается почетное звание «Ольгинский троль»

80 круб чистыми или сналогами ?

Чистыми Разработка контроллеров для автомобиля.

Опыт работы с данными контроллерами критичен ?

А с чем есть? Но вообще STM32 редкостью совсем не является, и думаю, что с ним имеет опыт много народу. TMS570 специфичная штука.. Еще могут заинтересовать люди с опытом управлением моторами (BLDC)

О, еще и город не написал. Как бы дать понять, что и за МКАД тоже есть жизнь?

Вакансия embedded разработчик (stm32, tms570), SPb, от 80 кр

SPb

Санкт-Петербург, видать

Мне пора к офтальмологу :3

Вова, денег же мало! :)

офис - п. Ольгино. Прямо напротив платформы

именно тот офис? )

http://s27.postimg.org/ttjm7utc3/trolls_olgino.png

Именно тот. Даже можно посидеть в тех-же помещениях. Делаем на stm32 робота блоггера, который автоматически троллит в фейсбучике и на ЛОРе

Написано же ОТ.

Клево. А зачем RTOS обязательно? Судя по

телематика, автомобильная тема
Желательно знание автомобильных интерфейсов CAN, LIN, итд

вы собираетесь делать "мозги" для автомобиля. Я бы не рисковал под RTOS это делать.

от, она же начало разговора.

Я просто смотрю на текущий курс и 80 тысяч очень дерпесивно, не правда?

Ты лучше посмотри на зарплаты бюджетников. И их, кстати, планируют снижать на 10% + как минимум 10% народу увольнять...

Вот это — депрессивно. Ведь уволенным останется разве что пойти, да повеситься!

Почему?

Я бы боялся тех людей кто делает это не под ROTS, честно. Кадилаки которые сходят сума и начинают мигать как при парковке в ряд пугают, четсно.

А бюджетники уже умеют RTOS?

Почему?

Потому что RTOS имеет смысл использовать там, где лень самостоятельно диспетчеризацию задач делать. Управление же автомобилем полностью решается конечными автоматами, зачем тратить бесценные тики на RTOS?

Если надо будет, изучу и RTOS. Пока же мне за глаза хватает КА. И вообще, новые технологии без проблем можно изучить всегда. Я, например, когда в 2009-м устраивался, и в электронике был почти ни в зуб ногой, и с погромированием у меня очень плачевно было, а сейчас спокойно рисую в кюкаде чертежи для узлов оборудования, в кикаде рисую схемки для управления, пишу прошивки и софт... Когда астрофизику заканчивал в 2003-м, даже не думал, что подобными вещами буду заниматься!

Начнем с того, что есть специлизированные автомобильные серии RTOS. Например, всякие OSEK, AutoSAR итд. Правда стоят как два железных парохода. Ну и в автомибиле есть куча разных девайсов. И для части из них имеет смысл использовать RTOS, а часть можно сделать попроще.

Кстати, а что там со свободными "мозгами" на STM32? Смотрели? Насколько тот проект хорош?

Все проще — грустно ездить на машине где контролер тормозов не RTOS.

Нам другое нужно. Но вообще они достаточно тупые и там многого нет

В студенческие годы, когда писали в качестве курсовика RTOS, то главным условием зачета, была соответствие OSEK-VDX. И насколько помню OSEK-VDX - это спека, говорящая какой должна быть РТОС и разумеется проходить API compliance. Как таковой разработкой OSEK-VDX коммитет не занимается, его дело написать спеку и чтобы все в промышленности её придерживались. А вот сертификация на соответствие - это да, стоит дохрена и больше :)

Еще RTOS в машинах контролирует впрыск топлива, interrupt latency должен быть адски мал :)

А зачем всё это вешать на электронику? Баг в прошивке - хана тормозам. Сколько ни тестируй, а риск допустить ошибку есть всегда.

Или это для всяких круиз-контролей?

interrupt latency должен быть адски мал

зачем вообще interrupt, можно просто поллить регистры. с питанием же проблем нет.

Снова актуально

Эдик, а ты большие гетерогенные проекты в глаза вообще видел? Ну когда много узлов, их все связать надо, много гетерогенных параметров между узлами с разными приоритетами передается, вот это вот все?

КА конечно можно написать, даже нормальный. Но люди занимаются разработкой автомобильных контроллеров, а не КА, который на такой задаче в RTOS выльется.

Тех, кто предлагает полить регистры - не возьмем точно

Сейчас нам в общем пофиг использовать rtos или нет. Склоняется к тому, что без нее пока проще. Но может и вернемся к этому вопросу на другом уровне.

А у нас расширение протоколов в системе уперлось в развитый КА на изделиях. Со РТОС было бы проще. Но в общем смысле это конечно вкусовщина.

Сейчас у нас получилась следующая архитектура 1) Бутлоадер по кану. 2) Шелл на USART, всякие красивые цветные логи итд 3) По кану можно менять всякие настройки и калибровать. Сейчас прикручиваю диагностику 4) Логика высокого уровня делается в Simulink 5) CAN складывается в очередь и выгребается в основном потоке. Парсер для пакетов генерится на основе DBC файлов.

Все это рабоатет и на STM32 и TMS570. Api одинаковый, для прошивки используетс один и тот же тул на C#.

Ясно. Ну так оно конечно логично все, не будучи специалистом в области, какую-либо оценку дать сложно. Но если не секрет, для CAN бывают стандартные протоколы, типа TCP/IP для Ethernet?

Там все значительно проще. Протоколы есть, но они скорее уровня приложения, например, OBD-II, J1939, CanOpen (не знаю особо о чем там), NMEA2000 итд. Особо сложного там не накрутишь, т.к. часто узлы сети имеют, например, по 20кб памяти.