Cianid

Я уже решил проблему через проективное преобразование. Но спасибо за совет.

Всем привет. Подскажите. У меня стоит задача определять смещение объекта в пикселях на камере. Камера висит под углом и имеет 2 степени свободы. Методы распознания не волнуют, это делается на стороне, я получаю только смещение объекта относительно центра окна в пикселях. Копаю в сторону проективного преобразования. Т.е. перевод реальных координат в координаты сенсора через матрицу гомографии. Но, для расчета коэффициентов необходимо выбрать 4 калибровочные точки, с априорными координатами. Я пока нашел только 2 - это центр камеры и точка на нижней грани обзорного окна(можно рассчитать через FOV камеры). В общем здесь пока тупик. Может есть еще какой нибудь метод?

Советую изучить в начале базовый синтаксис верилога, а потом уже здесь задавать вопросы. https://kit-e.ru/circuit/kratkij-kurs-hdl-chast-2-1/ https://marsohod.org/verilog Этих двух курсов вам с лихвой хватит, чтобы вам все стало ясно по счетчику.

А вы уверены, что сгенерится больше 1.5В, чтобы диод стабилизировал излишки? Может там 1В максимум при таких условиях.

Это которая радстойкая на 4к элементов? На ней особо не развернешься, разрабы сами говорили, что задача такой ПЛИС просто держать простую логику в одном корпусе.

Да в том то и дело, что хочется работать в этом направлении. Но получается какой то тупик. Всякие бэкенды и веб - скука смертная. Работать с ПЛИС у нас- это околовоенщина с 1.5 вакансиями. А релоцироваться не хочется. Вот и получается что заниматься интересным с душевным спокойствием тяжело.

Про уход, я имел в виду смену профессии.

Вот кстати можете подсказать? Я тоже активно ЦОС изучаю (SDR, Радиолокация, радиосвязь). Именно интересно работать с алгоритмами с последующей имплементацией в железо. Вот только все пишут, что с ПЛИС и вообще с железа уходят. Настолько все плохо?

Ну вот ровно так же я и сделал.

Не совсем понимаю какой информации не хватает. Просто опишу контекст. Я c 1986ВЕ1Т по uart кидаю через union массив, который отображается на структуру. А принимаю уже через QT-minGW. И получилось что у меня в контроллере 33 байта занимает структура, а в Qt уже 38. Вот там и обернул прагмой на выравнивание по 1 байту. Забавно, пишут что Microsoft ABI МОЖЕТ упаковать отлично от gcc. В общем необходимо указывать атрибут gcc_struct, если хочется меньше головной боли.

Не так выразился, не разные компиляторы. Я сравнивал arm и windows компиляторы. Ну вот и получилось, что для minGW пришлось дописывать #pragma pack(push,1).

Добрый день. Увидел разницу в работе атрибута у разных компиляторов. typedef struct __attribute__((packed)) { uint8_t a; uint8_t b; uint8_t c; float d; } str; gcc сразу упаковал в 7 байт. MinGW в 8 байт, т.е. ему пришлось принудительно указать выравнивание по 1 байту. Собственно где то можно подсмотреть по каким границам gcc выравнивает данные по умолчанию?

В общем не хочу тратить на это время. У меня есть отладочная плата nucleo, через нее и буду общаться с компом. Всем спасибо за советы.

FT232RL. Test на земле. VCCIO проверял.

Я менял FT232. Проблема точно не в этом. Vcc четко 5В.