[AlekErm 0]

5 минут назад, AlexandrY сказал:

Эт чесно говоря не прикладная задача. Тут вы явно попутали понятия. 
Прикладная была бы если вы сказали что собираетесь делать кухонного робота с заданным меню. 
А у вас чисто низкоуровневая,  я бы  даже сказал не задача, а процедура.    
Самая  сложная часть этой процедуры будет на строне связи с компьютером. 
На это дело есть разных либ.  Больше всего их кстати под Arduino.
И тогда начать надо с того почему не устраивает ардуина? Их же есть и на Cortex-ах

 

На ардуино скоростей таких нет.

И отлов потока на USARTe - это пока самый низ подводной части айсберга, эти данные потом уже пойдут наверх, на прикладной уровень.

И связь с компьютером пока нужна только для отладки, чтобы понять 4хотя бы какие там вообще данные в потоке.

Изменено 10 декабря, 2020 пользователем AlekErm

[Arlleex 131]

51 минуту назад, jcxz сказал:

Я бы ещё добавил и ассемблер...

Ну да. И это лишь только для программирования конкретного МК.
Сюда сколько лопатой не накидывай - все равно будет полдела.
Ведь все это лишь инструментарий для решения прикладной задачи.

Любой вменяемый проект похож на айсберг - верхушка это прикладной уровень (логика приложения).
А под ней вся остальная ж*па - от оптимизации схемы и планнинга ресурсов МК до оптимизации самого кода.
Чтобы грамотно спланировать взаимодействие периферии нужно тоже тонны мануалов прошерстить. Оценить возможности.
А чего уж про RTOS-ы или стеки каких-то протоколов или сервисов говорить. Своя наука, в которой тоже надо разбираться (с наскоку тоже не получится).
А сформировать окружение для поддержания нормального функционирования изделия и его жизненного цикла (всякие WDT, сервисы, bootloader-ы и т.д.) как?

Ну у прикладников все несколько проще - чуть какой глюк - бэкэнд саппорт пофиксил все глюки и команда работает дальше. Даже перекурить не успели.
А в embedded что? Что-то глючит - ты виноват. Сиди и разбирайся, чини. Исходники все открыты, ничего не мешает. На кривые библиотеки не пожалуешься.

У дилетантов всегда все просто. Только потом оказывается, что на "какой фреймер поверх UART юзать будем?" выкатывают  и просят больше так не ругаться.
 

42 минуты назад, AlekErm сказал:

Ничего секретного в ящике нет...

Так вот и ответили бы сначала себе на вопрос, как Вы будете синхронизировать скорости двух UART-ов, как будете буферизовать, где парсить.

[AlexandrY 3]

6 minutes ago, AlekErm said:

И связь с компьютером пока нужна только для отладки, чтобы понять 4хотя бы какие там вообще данные в потоке.

Так это что, подпольный реверс? Чужой самокат решили клонировать? 
Так с этого надо было и начинать.
Ничего против реверса не имею, но это в корне меняет весь подход.
Тут во-первых не экономят, во-вторых платформа должны быть беспроводной, чтобы реверсить на реальном объекте и без опасений за наводки и сбои. 

[AlekErm 0]

12 минут назад, Arlleex сказал:

Ну да. И это лишь только для программирования конкретного МК.
Сюда сколько лопатой не накидывай - все равно будет полдела.
Ведь все это лишь инструментарий для решения прикладной задачи.

Любой вменяемый проект похож на айсберг - верхушка это прикладной уровень (логика приложения).
А под ней вся остальная ж*па - от оптимизации схемы и планнинга ресурсов МК до оптимизации самого кода.
Чтобы грамотно спланировать взаимодействие периферии нужно тоже тонны мануалов прошерстить. Оценить возможности.
А чего уж про RTOS-ы или стеки каких-то протоколов или сервисов говорить. Своя наука, в которой тоже надо разбираться (с наскоку тоже не получится).
А сформировать окружение для поддержания нормального функционирования изделия и его жизненного цикла (всякие WDT, сервисы, bootloader-ы и т.д.) как?

Ну у прикладников все несколько проще - чуть какой глюк - бэкэнд саппорт пофиксил все глюки и команда работает дальше. Даже перекурить не успели.
А в embedded что? Что-то глючит - ты виноват. Сиди и разбирайся, чини. Исходники все открыты, ничего не мешает. На кривые библиотеки не пожалуешься.

У дилетантов всегда все просто. Только потом оказывается, что на "какой фреймер поверх UART юзать будем?" выкатывают  и просят больше так не ругаться.
 

Так вот и ответили бы сначала себе на вопрос, как Вы будете синхронизировать скорости двух UART-ов, как будете буферизовать, где парсить.

Так я выше писал как буду парсить. Поток разложу по регистрам, а прикладной уровень будет читать эти регистры по запросу, на порядок меньшей скорости.

3 минуты назад, AlexandrY сказал:

Так это что, подпольный реверс? Чужой самокат решили клонировать? 
Так с этого надо было и начинать.
Ничего против реверса не имею, но это в корне меняет весь подход.
Тут во-первых не экономят, во-вторых платформа должны быть беспроводной, чтобы реверсить на реальном объекте и без опасений за наводки и сбои. 

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

[AlexandrY 3]

10 minutes ago, AlekErm said:

Практически да, реверс, но не самоката :) 

Реверс протоколов удобнее всего делать на PC.
Я бы подключился прямо к компьютеру через UART-USB адаптер, и анализировал бы в Simulink.
Лучшей среды для парсинга неизвестно чего не найти.  

[AlekErm 0]

8 минут назад, AlexandrY сказал:

Реверс протоколов удобнее всего делать на PC.
Я бы подключился прямо к компьютеру через UART-USB адаптер, и анализировал бы в Simulink.
Лучшей среды для парсинга неизвестно чего не найти.  

А вот именно этого мне и не удалось сделать, тот переходник что у меня имеется хоть и можно разогнать до таких скоростей, но по логическим уровням он не проходит, поскольку черный ящик выдает 1.8В логические уровни. А переходнику выше 2В надо. Пробовал логический согласователь, но не поехал он почему то, сильно искажает сигнал. В итоге я решил что два МК одного семейства вполне сдружатся по логике.

[jcxz 184]

1 час назад, AlekErm сказал:

И отлов потока на USARTe - это пока самый низ подводной части айсберга, эти данные потом уже пойдут наверх, на прикладной уровень.

Но если этого "низа" нет, то работать ведь ничего не будет? Или если он криво работает.

А теперь представьте, что осуществилась Ваша мечта и как-то запилили ява-машину на STM32. И написали Вы свою прогу. А потом она у вас в целом работает, но иногда почему-то глючит (теряет часть данных из UART-потока). А всё потому, что встроенный сборщик мусора (выполняющий работу за ленивого программиста, не желающего её делать самостоятельно) иногда забирает часть времени на себя и в это время происходит переполнение буфера (поток-то 3Мбода). И никак исправить это нельзя, от слова "совсем".

Либо что-то ещё.

И чем более высокоуровневую среду программирования будете применять, тем таких подводных камней в её работе будет больше. Так как неизмерима далека она будет от народа железа. И что-то серьёзное, реалтаймовое, по этой причине сделать на ней не получится в принципе. Потому - оно нафиг никому не нужно. А если кто-то и сделает что-то подобное, то будет это только на уровне "поиграться и выбросить".

1 час назад, AlekErm сказал:

А вот именно этого мне и не удалось сделать, тот переходник что у меня имеется хоть и можно разогнать до таких скоростей, но по логическим уровням он не проходит, поскольку черный ящик выдает 1.8В логические уровни. А переходнику выше 2В надо. Пробовал логический согласователь, но не поехал он почему то, сильно искажает сигнал. В итоге я решил что два МК одного семейства вполне сдружатся по логике.

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

embedded-программирование не такое простое как вам кажется (пару строк накалякать). И в 1000 раз лучше разобраться с согласованием уровней (или найти другой переходник) чем вместо этого строить новый дом лепить рядом систему на МК. И уж если даже с согласованием уровней UART не удаётся разобраться, то боюсь что с программированием МК - и подавно.  

 

PS: Лучше выложите сюда схему вашего "согласователя". Толку будет больше - подскажут. И спокойно будете дальше писать на ПК на любимой яве.  

[AlexandrY 3]

50 minutes ago, AlekErm said:

А вот именно этого мне и не удалось сделать, тот переходник что у меня имеется хоть и можно разогнать до таких скоростей, но по логическим уровням он не проходит, поскольку черный ящик выдает 1.8В логические уровни. А переходнику выше 2В надо. Пробовал логический согласователь, но не поехал он почему то, сильно искажает сигнал. В итоге я решил что два МК одного семейства вполне сдружатся по логике.

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

[mantech 35]

18 часов назад, AlekErm сказал:

Такой вопрос назрел - неужто до сих пор нет нормальной среды программирования под STM на JAVA языке? Один из популярнейших языков! Камни все сложнее, возможности все больше, грызть их уже никаких зубов не хватает программить их на уровне плинтуса.

Не понял, почему в СТМ-то все уперлось, чем мелкий одноплатник на линукс-андроид не угодил?

[AlekErm 0]

4 минуты назад, mantech сказал:

Не понял, почему в СТМ-то все уперлось, чем мелкий одноплатник на линукс-андроид не угодил?

И такое тоже будет. Пока мне нужно данные отловить, понять, стоит ли ввязываться.

[AlexandrY 3]

5 minutes ago, mantech said:

Не понял, почему в СТМ-то все уперлось, чем мелкий одноплатник на линукс-андроид не угодил?

Чел же ясно сказал - преобразователь уровней искажает сигналы. 

[AlekErm 0]

19 минут назад, AlexandrY сказал:

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

Этот черный ящик (он на STM реализован) вероятно все равно придется программировать, так что я начал изучение STM с простой, но заодно нужной мне функции работы с USART

Изменено 10 декабря, 2020 пользователем AlekErm

[mantech 35]

29 минут назад, AlekErm сказал:

я начал изучение STM с простой, но заодно нужной мне функции работы с USART

А, ну это правильно...

[MrBearManul 0]

3 часа назад, AlekErm сказал:

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

Ну наймите же уже толкогового специалиста, заплатите ему деньги. Их всё равно платить придётся.

 

З.Ы. Вам уже ни один раз правильно сказали: мир встраиваемых систем это вам не мир ПК. На ПК вам доступны, по сути, безграничные ресурсы. Всё самое сложное (операционная система, драйвера, материнская плата) за вас уже сделаны. Вам остаётся взять только вашу яву или qt и начать ваять ПО. Не всегда, кстати, оптимальное по использованию этих ресурсов. Но ведь их много, и стоят они копейки. Вот и выходит, что программа, выводящая окно и кнопку весит под 8 (восемь) мегабайт сразу под Qt. Ну да ладно, не в этом суть. Суть в том, что на микроконтроллере вам придётся делать это всё самому. И не забывайте о железе. Отладочные платы не всегда подходят для установки в конечное устройство. Как правило, они нуждаются в доработке, ну хотя бы нужно обеспечить питание, защиту от статики, помех. Кто это всё сделает вам? А из-за неправильно подобранного железа вы иногда можете ловить программные ошибки, природу которых выяснить будет весьма трудоёмко без специальных знаний. Подумайте об этом.

Изменено 10 декабря, 2020 пользователем MrBearManul

[AlekErm 0]

1 час назад, MrBearManul сказал:

Ну наймите же уже толкогового специалиста, заплатите ему деньги. Их всё равно платить придётся.

 

З.Ы. Вам уже ни один раз правильно сказали: мир встраиваемых систем это вам не мир ПК. На ПК вам доступны, по сути, безграничные ресурсы. Всё самое сложное (операционная система, драйвера, материнская плата) за вас уже сделаны. Вам остаётся взять только вашу яву или qt и начать ваять ПО. Не всегда, кстати, оптимальное по использованию этих ресурсов. Но ведь их много, и стоят они копейки. Вот и выходит, что программа, выводящая окно и кнопку весит под 8 (восемь) мегабайт сразу под Qt. Ну да ладно, не в этом суть. Суть в том, что на микроконтроллере вам придётся делать это всё самому. И не забывайте о железе. Отладочные платы не всегда подходят для установки в конечное устройство. Как правило, они нуждаются в доработке, ну хотя бы нужно обеспечить питание, защиту от статики, помех. Кто это всё сделает вам? А из-за неправильно подобранного железа вы иногда можете ловить программные ошибки, природу которых выяснить будет весьма трудоёмко без специальных знаний. Подумайте об этом.

И сколько стоит нынче такой специалист? Применительно к моей задаче