Mirn

есть HRы а есть секретари.
Секретари они просто квадратно - гнездовым методом подбирают сотрудников сопоставляя ключевые слова в резюме и вакансии. Им всё равно на соискателя. Они ничего не предлагают им, да блин, они даже не удосуживаются представиться как юр лицо (непонятно что за фирма и что за проект, не твоего ума это дело холоп!). Да они могут иметь хорошую базу данных соискателей, да они могут хорошо договариваться с людьми, согласовывать даты собеседований и сглаживать факапы, да они могут уметь навешать лапши на уши и уболтать рок-зведу работать на галеро-легаси, но они не перестают от этого быть секретарями.

А есть HRы которые работают не только с соискателями, а с заказчиками.
Они обязаны заставить заказчика определиться кто им вообще нужен, заставить заказчика раскрыть карты хотя-бы в виде зарплатной вилки и предлагаемых проектов, они обязаны свести и познакомить заказчика вакансии и соискателя и уровнем повыше чем барин-холоп. Это их обязанность. И именно так можно привлечь реальных сеньёров и найти ключевые кадры, заинтересовав заказчиком вакансии соискателя а не держа его в абсолютной тайне. Например: они обязаны не только понимать что из 5 собеседований 3 собеседования с зам директорами, деректорам и собственниками бизнеса не только маразм, но и гарантированно отпугнёт любого вменяемого сотрудника с опытом работы (а потом он ещё и кучу негативных отзывов потом везде и всюду оставит о таком АДЕ). Но они обязаны отговорить заказчика от такого поступка или прекратить общаться с ним. Они обязаны выудить зарплатную вилку и заставить работодателя описать свою фирму в положительном ключе, а не показушные "есть печеньки" которые никому не нужны. Т.е. они должны сформировать сделку, показать ОБОИМ сторонам предлагаемые бонусы и обосновать ОБОИМ сторонам цену. Они формируют ПРАВИЛЬНЫЙ бизнес процесс найма. А не тот маразм что творится на рынке найма ИТ в СНГ (особенно дико отечественный найм воспринимать после опыта найма в Японии).
Поэтому я считаю что Вам следует попытаться начать становиться HR рекрутером ;)

Для робототехники системы компьютерного зрения сейчас самое критичное и просто "не паханное поле".
Современные МК системы не умеют или слабы в реалтайм обработке видео.
Но новые мк имеют достаточно производительности и есть векторизация.
Поэтому самое интересное сделать на STM32F7 / STM32H7 например распознавание налету геометрических примитивов.
Детектирует три точки расположенных правильным тре...
На это требуется 100 микросекунд на кадр.

или даже
глубокие нейросети на 1000 объектов.

Любую среду программирования Си или плюсов понимающую дизасм и GCC.
Я бы порекомендовал Eclipse и MinGW или GCC.

Изучать ассемблер нужно только в контексте интеграции в языки типа Си.
Иначе опять придётся "забудьте всё чему вас учили" и придётся изучать с нуля то что и как генерит си компилятор,
а на -O2 и выше он генерит очень сильный код или очень дурной который и нужно исправлять и за это очень солидно платят, а не за поделки в 4к озу (если это не ардуино конечно).

Для простых задачь однозначно лучше WizNet
его сильные стороны:
1. Есть паралельная 8 битная шина - её хватает для достижения скорости в 700 тыс мелких пакетов по 3-5 байт. т.е. 3-5 мегабайт в секунду можно достичь
2. Внутри уже есть TCP стек и он настроен на скорость - алгоритм деления пакетов на двое и всё прочее.
3. Есть примеры кода и они реально полезны
4. Есть хорошая документация и коммунити

слабые стороны:
1. TCP стек урезанный и в экзотических пакетах особено бродкастинге может косячить.
2. мало одновременно открытых каналов (около 4 чтоли).
3. корпус плохопаябельный мелкий и привередлевый - лучше брать готовую миниплатку.
4. требования к ген тактов или кварцу особые, можно забить и забыть - но можно вспомнить после пары месяцев безпомощной отладки идиотских и нелепых багов. - хотя это и к стм32 относится тоже, сам езернет не прощает кривого тактирования.

реализация в МК (именно на стм32 не щупал, только nxp и техасы)
минусы:
1. Надо самому подымать TCP стек и по хорошему тут нужна нормальная ОС и весьма не маленький скил программинга чего обычно нет у схематехников и инженеров.
2. Надо настравивать стек правильно иначе получишь пару килобайт в сек.
3. качество либ для стека не отличается дружелюбностью, а микроайпи вообще адовый треш
4. внутренние ДМА буфера часто мелкие и нередко пропускают данные из за обильного бродкастинга уровня DDOS, но хотябы не глючат роняя всю сеть совсем.
5. требуют для нормальной скорости ОЧЕНЬ МНОГО ПАМЯТИ.
6. жрут нереально много проц. времени на высокой скорости, хотя тот же целерон 500мгц на самбе тоже работал не быстро из за нехватки проца лет 15 назад.

плюсы:
1. можно сделать более сложные штуки - не только TCP протокол а старые и экзотику
2. все исходники доступны, можно баги в либах править - визнет железо закрытое
3. все ошибки можно прочесть и обработать (потратив вагон личного времени)

Я делал реализацию PS/2 клавиатуры на ванильном intel8051 что 24мгц 12 тактов на инструкцию. Ещё в 90ые этому МК хватало скорости чтоб по прерываниям прямыми ножкодрыганиями формировать коды клавиш, задержек нет, прерывание и опрос и начало передачи гораздо меньше времени занимают чем посылка кода клавишы который по сути UART с мелкими правками (физ уровень как i2c) - он сам по себе медленный и поэтому быстрее 3000-4000 раз в секунду невозможно что либо быстрее передавать - станет каша из бит если мы текущую передачу прервём и начнём нову.
Поэтому ответ прост - подойдёт любой МК который работает свыше 2 миллионов команд в секунду (вообще любой из современных) и имеет хотябы один вход прерывания - на него повесить через диодное И выход со всех кнопочек что на землю.

0. С разговорного английского, беглово с хорошим словарным запасом и умением понимать шутки и казалось бы странные фразы. Всем абсолютно плевать на Ваш опыт и знания и умения, даже устровшись задаром в корпорацию с шансом роста - его не будет как бы Вы не старались, это реальный мир а не сказочки. Высокий старт решает всё, а для этого надо выдавать бегло много красноречиво на собеседовании на остальное в 99.9999999999999999% случаев всем плевать всегда и даже проверять не будут даже выдав тестовые задания, даже если они толковые. пункты 1 и далее без этого пункта не нужны и бессмыслены.
Програмист при помощи человечьего языка работает с людьми при помощи инструментов сделаных другими людьми и опять же описанных человечьим языком. Даже код для людей а не для ПК. Запомнить и понять это надо.

1. Программирование на Си и С++. Усиленно изучать оба понимая что даже чистый си понадобится и очень часто, Вы же FPGA будете использовать не спроста - а значит шевелить огромными данными а их ввод-вывод надо организовать и нередко надо делать драйвера самому на люниксе например, а для этого они оба и понадобятся.
2. Умения ЧИТАТЬ ассемблер - ТОЛЬКО ЧИТАТЬ и умения исправлять код и параметры компилятора чтоб получить нужный дизасм с нужной скоростью или размера.
3. Никогда не писать на ассемблере. см пункт 0 (асм это нечитабельное неподдающееся правке г). Современные компиляторы на голову лучше асма делают, даже на мелочах ты продуешь, в целом разница будет и по размеру и по скорости в разы.
4. Не использовать старое гавно мамонта и не гордится им, забудтье как страшный сон авр и пик микро с чистым i51 если изучать 8051 то современные модели с одним тактом на инструкцию и с нормальным объёмом памяти с частотами 100 мегагерц и выше или в особых случаях. Аналогично забыть: например первые максы альтеры.
5. Готовиться к имиграции иначе интерес угаснет лет через 5 от такой зп в странах СНГ. Но надо понимать что по миру эта отрасль в среднем оплачивается на 50% ниже ИТ.
6. Умение работать с людьми и софт скилз. Человек и зп зависит от результативности и умения себя показать, неважно что ты делаешь, важен самопиар, я знаю отличных людей но "серых мышей" которых нафиг уволили а потом удивлялись почему всё перестало работать. Но я не знаю ниодного карьериста и балабола но весьма посредственного в технике который не смог бы обскакать всех по карьерной лестнице. [Социальные скилы при наличии тех минимума] >> [тех уровень лучше всех]. Молчуны быстро сталкиваются с тем что им дают шлак проэкты или не выделяют ресурсы и они загнивают в болоте легаси.
7. Изучать не только современное но и популярное и задвинуть подальше свои хотелки и свою лень, всем пофиг что серия А интересна если серия Б унылоге гавно но 90% проэктов на ней или она прото в полтора раза дешевле. Изучать надо то что требуется рынком а не то что ты себе внушил что требуется. Самоанализ а не "ну это статья понятная попробую я ка это" "хмм, я это знаю и поэтому дальше буду лепить на этой платформе" "блин а почему никому эта платформа не нужна?"
8. В начале надо набить ошибок на своих проэктах и потом начать изучать чужие похожие проекты а только потом теорию чтоб понять почему они так сделаны, и так рекурсивно. Не изучать неведомую теор хрень только для галочки - как изучишь так и забудешь сразу же если она без практики.
9. Изучить паттерны программирования и немного веба с бд (пригодятся и не раз - и как резерв для карьерного манёвра чтоб уйти в веб или гейм или интерпрайз если совсем всё плохо с финансами и зарплата нужна седня а не через пол года)
10. конечно же схематехнику но без переусердствований - на ардуино уровне вполне хватит

Из конкретики пример:
Ардуино на СТМ32 или голый СТМ32 (а лучше в начале ардуино стм32 а потом голый - идеально)
подключить тяжолые вещи, например: дисплей камеру память, понять ботлнеки, сделать что то годное на этом - поиск лиц например. (работать с живым видео полезно и очень интересно, даже наткнувшись на баги можно получить интересные результаты и их развить и понять причину бага, и самое главное видно сразу результат и он классный)

понять что МК вообще не годны к такому и потехоньку начать переписывать алгоритм поиска лиц на верилог
осилить Icarus Verilog или другой тулчейм симуляции
довести симуляцию до идеала - т.е. bit perfect когда результат симуляции побитово равен исходнику для СТМ32
купить ФПГА отладку или заказать свою ФПГА плату например минимум циклон 3-5 или спартан 6
замучаться с интерфейсами и изучить времянки и time constrains и иже с ними
довести до ума и до реалтайма этот проэкт с поиском лиц

примерно так

1. реализовать алгоритм на Си
2. скомпилировать GCC или иным современным компилятором с включенной векторизацией и всеми оптимизациями.
3. дизассемблировать или включить опцию показа промежуточного результата.
4. посмотреть итог и убедиться что там есть MMX или SSE инструции
5. обратить внимание на обработку краёв которые могут быть не выравнены или не попадать в ровно блок, массивов маленьких размеров меньше 16-4 элементов и прочие мелочи.
6. обратить внимание на вызов этой твоей функции и как организуется стек, временные переменные, как передаются параметры, какие регистры функция нахождения максимума изменяет а какие сохраняет и как.
7. попытаться безуспешно понять почему именно так.
8. попытаться самому повторить результат на асме не глядя в результат компилятора и получить в лучшем случае в 2-3 раза худшее быстродействие если вообще отладить сможешь
9. сделать вывод что страдаешь хернёй и использовать ассемблер для оптимизации столь тривиальной вещи полный дурдом и понять для чего асм всё таки нужен
10. понять что асм нужен для системных вещей, и понимания почему у компилятора торомзит код а не пытаться писать велосипеды не умея оптимизировать под современные процы.

для пункта 2-4 есть https://godbolt.org/#

с просмотра финансовой стороны,
какие нищенские зарплаты там обитают
какие большие расходы на нормальное оборудование
сколько ещё людей нужно и без них вообще никак в отличии от веба где один герой самоучка может огого
какая есть востребованность на рынке стран СНГ а точнее нет.
ну и про обж не забыть иначе можно убить себя даже батарейками от наручных часов.

1. Возможно это блокировки шины памяти.
Они бывают если что-то занимает озу или флешь надолго или уарт очень быстрый, 500кБод и выше.
Классика жанра - прошивка параметров в флеш или самого флеша. Или работа другого канала ДМА на макс скорости.
2. Возможно ошибки приёма уарта, советую глянуть осцилографом стабильность уровней напряжения и временную стабильность фронтов.
3. Баг в коде и порча ОЗУ - советую поменять раскладку памяти, если использовать LD файлы то это прощее, в других более закоренелых системах типа кейла непонятно как. Но метод такой - если перенести буфер уарта на другое место в ОЗУ и всё исправилось то это оно и есть. Можно размер стека изменить, поиграться с размером прочих буферов, массивов и тд.
4. Попытаться покускам поотключать бизнес код.
5. Не использовать RTOS - да фантастика, но очень часто причина в нём. Он не идеален, да даже если он был бы идеален, можно накосячить с его использованием.
6. Неправильно настроенная прочая аппаратура - поотключать левое.
7. Подумать когда возникла ошибка и об обстоятельстве её возникновения, нередко бывает например когда ошибка в ячейке c смещением 0х13 и тут вспоминаешь что была добавлена стркутура и третий байт массива в этой структуре как раз с смещением 0х13 после вызова уарта меняется ... опа!

Судя из приватного общения у Вас небольшой бюджет и слишком общие задачи.

Поэтому советую ориентироваться на студентов 3-4 курсов, но не столичных вузов а глубинки.
Есть области где очень много технических университетов, например у нас в Удмуртии, где делают всё от электро дивигателей до отечественных ПК Эльбрусов. Я за 10-20тр в месяц находил отличных рукастых на вырост. Один вообще целый год за 15тр обучался отладочным платам, управлению и немножко даже выдал результат под конец года. Кстати эту сумму он сам захотел - в обмен на свободное посещение, 5 минут от дома и возможность набраться опыта.
(цены 2010-2014 года)

Можно начать с малого - договориться с кафедрами и развесить рядом с расписанием объявление о подработке, можно провести бизнес тренинги или просто дать немного лекций. Мне помогли вообще личные беседы и знакомство с кафедрами где сам учился или преподавал. Приятным бонусом то что аренда офиса в кукуево существенно дешевле Москвы.
Это работает, это помогает, но минус в том что результат будет через год-два, и очень сырой и глючный. А дальше могу я взять и переписать это нечто в нормальный вид ;)

работодатель за тебя это обычно делает, суть: в России море аутсорс компаний которые работают с зарубежом и у них два этапа, первый этап на русском собеседование, далее просят оформить на английском CV, смотрят его, если помелочи проблемы то правят и выводят на собеседование с заказчиком проекта, если совсем всё плохо то "мы оставили Вас в базе данных".

вот после правки и можно глянуть чуть более лучший свой вариант, но если будут совсем непонятные предложения и темболее несколько таких то ты автоматом в пролёте

потому что указатель "a" непонятно куда указывает, а ты в это непонятно куда ещё пытаешься ввод с клавиатуры организовать, и в итоге получаешь непонятно что.

например в сборке GNU GCC для ARM есть такая утилита как objcopy, она конвертирует форматы, в том числе может перегнать ELF в голый бинарник, например так:
arm-none-eabi-objcopy -O binary "Boot_F4_fast_uart.elf" "Boot_F4_fast_uart.bin"
так что советую ознакомиться с маном на objcopy
https://sourceware.org/binutils/docs/binutils/objc...

Я понять одного не могу: Почему люди всё ещё используют keil?

Да оптимизирует местами лучше чем gcc но очень часто нарываешся на то что некоторые участки кода на ровном месте крайне неоптимальны (не в десятки, в СОТНИ РАЗ!), и не арифметика и не ветвления, а порой обычные структуры например. Это как суперскоростной балид, непонятно в какой столб врежется, но зато сделает это реально молнеиностно!

А ещё он содержит либы без исходников а эта закрытость добавляет ещё большей неопределённости. Компилирую всё из исходников под GCC и эклипсом - все вопросы решаются тем что можно глянуть исходник.
В Кейле надо "понять и простить" или перестраховаться и сделать самому, но зачем тогда его библиотеки нужны?
Да библиотеки там хорошие не спорю. Но они вряд ли смогут потягаться с сообществом для GCC.

О себе: много работал с проектами на кейле или переносил их на gcc и всегда удивлялся тому количеству странностей которые его сопровождают и нет в GCC, так что моё мнение сугубо субъективно и эмоционально.