Трябва да осъществя USB-serial bridge посредством PIC32 + Arduino IDE, с който да може да се програмира ESP32 запоен на същата платка, на която се намира PIC.
Реализирането на задачата съм го направил посредством инициализация на USB Virtual COM Порта (Пикът е сетъп-нат като USB CDC Serial emulator), който ми се води в Arduino като Serial, и съм инициализирал UART1 като Serial0. Малко съм моднал CDC кодът, защото оригиналният нямаше подръжка на DTR/RTS, a за да вкарам ESP32 в bootloader трябва да клатя DTR и RTS-а. Двата серийни интерфейса (USB Serial и UART ) съм ги фикснал на 115200 баудрейт и esptool-а бачка. Така например свързам платката с miniUSB кабел от PC през PIC32 мога да чета и пиша в/от ESP32. До тук всичко е добре, но остава едно ограничение. Трябва да ползвам баудрейт 115200 за да програмирам ESP-то, което е страшно бавно. Желателно е да може да работи с baudrate поне > 1М . За да може да работи esptool-а с ESP на по-големи баудове, трябва в началото да направи синхронизацията на 115200 и после да качи баудрейта. Да, ама с моите фиксирани 115200 не мога да прехвърлям данни на по-голям бауд-рейт, защото Пикът ще прочете от компютъра глупости и ще изпрати още по-големи глупости на ESP32.
Та въпросът ми е, как да реша проблемът с динамичния баудрейт. Ясно е, че в началото скоростта ще е фиксната, но се чудя дали да се опитвам да хвана някакво съобщение казващо, че baudrate-а ще се смени, което струва ми се, ще забави трансфера на данни и ще умре комуникациятта между ESP и PC или да ползвам таймер и да гледам за колко време ще имам START условие, като по този начин рискувам най-много да изтърва един байт, а ESPТООL-а като види, че на някой пакет му изтече тайм-аута, се опитва да го изпрати наново.
Просто се опитвам да намеря някакво по-интелигетно решение в иначе супер дървения код.




Тука сигурно вместо да ползвам ардуиновските глупости за инициализация на УАРТ-а, можех да ползвам директно манипулиране на регистрите, но идеята е да го подкарам първо, като функционалност, после да го оптимизирам и да гоня бързодействие.

Няколко неща ще ти нахвърлям. Ако качиш бауда над 115200 ще имаш проблем с дебъгера. Т. е. в режим на дебъгер няма да можеш да осъществяваш комуникация, защото тогава контролерът ти работи по-бавно. На колко точно ще се прецака не мога да ти кажа. При мен с MPLab X на 400к някъде се прецаква. Само че ти емулираш COM на USB, което ти е 600к макс! Няма как да качиш бауда през high speed USB над 600к! Пробвай на 230400 би трябвало да работи, но от там нагоре....
Принципно ако имаш контрол над приложението на PC, можеш да разделиш комуникацията на 2 части - инициализация и работен цикъл. При това положение инициализацията можеш да я правиш на 115200, а работния цикъл на по-висока, на колкото тръгне там... Не съм гледаш превключването на бауд на USB дали можеше да става runtime, защото там на практика ти не използваш UART, а USB. Защо си го дал така в примера си, само ти си знаеш...
Поздрави!

Идеята на тоя пик е, да направи аналог на FTDI/CH340. Защо не се ползва FTDI/CH340 ами такава пародия, не ме питай. И защо съм задал бауд на USB, защото USB-то емулира RS-232, разбирай UART. Да приложението работи по този начин, доколкото разбрах. Инициализира на 115200, качва стъба и когато тръгне стъба в ESP32, вече според зависи от бауда, който си задал като параметър на TOOL-а, ESP32 почва да говори на такъв бауд. За дебъгване и дума не може да става, дебъгването е ползване на осцилоскоп и логически анализатор, най-тъпото в цялата работа е, че трябва да използвам готов линкер скрипт, като 1 седмица само се мъчих да променя някой от конфигурационните битове на пика, за да разбера от майната си в нета, че те били записани в линкер скрипт и са хардкоднати. Дори не знам на каква честота ми работи процесора и как е инициализирано USB-то. Направих програма, пак с три хиляди зора, заради Arduino IDE съвместимостта с ПИК-а, която да генерира най-малкото възможно прекъсване.. (Таймер, който да брои до 1 и да генерира прекъване) От прекъсване до прекъсване 4 микросекунди, около 1 микросекунда за обработка на прекъсването - да забрани прекъсванията, да вдигне и свали един пин, да разреши прекъсванията. Общо взето имам Arduino IDE, с ChipKit скриптове и тулове за програмиране и компилиране и платка с PIC, който да работи като USB-Serial bridge.

От гледна точка на USB CDC класа баудрейта е просто параметър, който хоста може да чете и да пише. Но това по никакъв начин не оказва влияние върху скоростта по USB-то. То винаги си работи на колкото може.
На практика се случва следното - когато от хоста смениш баудрейта, той изпраща заявка към девайса. Пикльото я получава и тъй като го играе бридж вероятно си програмира серийния порт с тоя баудрейт. Стойността на баудрейта не е толкова важна, стига пикльото да си програмира серийния и той да бачка.
Другото важно е да не се препълват буфери после. Примерно ако на серийния канал нямаш хендшейк, сетнал си много висок баудрейт и ако ESP-то тръгне да приказва то ще дава на пикльото повече данни, отколкото USB-то претаква и ще почне да изпуска.

До тук разбирам, че бауда на USB-то, колкото и да го сетна, няма да има значение, но остава да сетвам бауда на UART-а, като все пак тряба да знам с каква скорост ми плямпа USB HOST-а, за да знам с каква скорост да накарам пикльото да плямпа на ESP32. И пак опираме до въпроса, как е културно да се детектне баудрейта. Ясно ми е, че все ще изпусна един пакет. Модването на esptool не мисля, че ще бъде решение, т.е от едната страна имам независим дивайс, от другата независим дивайс и Пика играе ролята на свързочник. Трябва да следи колко бързо ще си говорят двата края на връзката и да препредава съобщенията в синхрон. От тук следва, че пикльото трябва да се нагажда според HOST-а, защото ESP-то изпълнява каквото му кажат, като го питат - отговаря, като му кажат плямпай по-бързо, той започва да плямапа по-бързо.

Гледах кода, там си прозрачен... няма никакъв анализ, няма пакети.
PC-то сменя бауда,нали? И прща към USB стека някаква команда , към контролните точки в ПИКа.
Там трябва да слушаш/проверяваш - както следиш виртуалните DTR/RTS.
Така ми звучи логично, не че съм се занимавал.

Като за академичен кадър можеше една идея по-добре да си формулираш въпросите

Значи имаш esptool който доколкото виждам има опция -b с която да задаваш произволен баудрейт. Имаш и някакъв бридж, който ако е написан като хората трябва да следва зададения баудрейт (стига да е в рамките на поддържаните).

Та какъв казваш ти е проблемът?

@miro_atc, въпросът е как, да засега баудрейта на HOST-а, за да задам същият баудрейт на UART-а на пика. Когато ползваш -b параметъра, тулът не започва веднага да говорои със зададения от теб баудрейт, а започва на 115200, докато не качи Stub кода в ESP32. Когато вече го качи, той променя баудрейта на ESP32 UART-а и съответно тогава трябва и PIC32 да си е сменил baudrate-а.


Това значи ли, че HOST-a изпраща сетъп пакет/рикуест към Device-а, за да му каже колко бързо да чете/пише в буферите, т.е един вид задава baudrate-a. Ако е така, значи би трябвало да мога да прочета в даден момент какъв баудрейт е сетнал хоста и да го използвам за настройка на UART-а ?

@Stefan63, да. HOST-a сменя бауда, но едновременно с това и ESP32 сменя бауда. Само пикльото изостава, защото неговият бауд е предварително зададен.

Esptool-a е писан на пайтън, ползвайки модула "serial". Не съм наясно какво точно прави Serial модула на по-ниско ниво. Използвал съм го да сетна баудрейт/тайм аут, да клатя DTR/RTS и да получавам/изпращам данни.

ПИК ът трябва да може да види промяна на бауда откъм ПЦто.
В твоята задача интересно е как се синхронизират ПЦто и ЕСП32, кой първи минава на висока скорост.
Който и да е,който и да превключва първи , какъвто и символ да ползват за синхронизация -
- ЕСП може да се опита да анализира символа на ниво продължителност на стартовия бит.
- В ПЦ-то това е почти невъзможно.
Ерго - гледай контролните пакети откъм УСБ хоста и сменяй според виртуалния бауд- сетъп.

Значи става номерът със сетъп пакетите, така ще е най-интелигетно, само трбява да модифицирам стека на пика, да може да ми изведе баудрейта при поискване от функция. За стартъп бит продължителността и аз го видях в нета, за това реших да сондирам за още мнения.
Относно кой минава първи на висока скорост, предполагам, че е почти едновременно, като важното е, че след ъплоудване на стъба, РС-то започва да пише във флаша на ESP-то, а ESP-то изпраща АCK/NACK байтове. При първоначалната инициализация, преди да зпаочне самия трансфер на стъба, РС-то започва да клати DTR/RTS пиновете, за да вкара в ресет ESP-то и после да го вкара в буутлоадъра. После предполагам РС-то изпраща хедърни байтове, като в същото време слуша за отговор от ЕСП-то и накрая изпраща командата или стъба или и двете. После в зависимост дали си му задал да влезне във флаша или не, клати или не отновно RTS-а, за да рестартира ESP-то.
Това е когато искам само да прочета мак адреса на ESP-то. Когато искам да го програмирам, просто вместо командата за четене на мак-адреса започва да пише в паметта на ESP-то, а ако съм му задал параметъра -b, тогава при изпълнение на стъб програмата, ESP-то преинициализира UART-а с новия баудрейт, който е зададен в кода на стъба. И така ESP-то и PC-то не се изслушват, ами просто PC-то започва да говори и очаква от ESP-то да отговори със същата скорост, ако тайм-аутът изтече опитва още 20-на пъти и накрая ако не стане, казва на програмиста да си гледа работата. Най-тъпото е, че логическият ми анализатор не се подържа от новите верси на софтуера на производителя си, а линка им за сравнително нова версия, която се води за тях архаична има бъг и не мога да слушам едновременно на два различни канала. То и съпортът им е един път.
Така остана да снифна USB трафикът и да модифицирам PIC USB стека, да модифицирам моята програма да чете баудрейта и пренастройва UART-а. Сега ми светна и още един въпрос, колко често и кога да слушам за промяна в бауда, надали ще мога да създам прекъсване, когато баудрейта се смени, остава циклично да чета баудрейта, което не знам до колко ще ми наруши синхронизацията с пика и PC-то.

Нали си постнал кода на главния цикъл в първия си пост.

Слагаш тук една функция , те нещата стават бързо, ама не чак светкавично.
Предполагам, че УСБ стекът отговаря някак си към хоста -на бауд-чейндж пакет, потърси из стека.

Когато esptool-a смени баудрейта пикльо ще получи set_baudrate заявка по контролния еднпойт. Най-малкото което трябва да направи по стандарт е да запомни стойността, защото има и get_baudrate и трябва да може да връща текущата стойност.
С това приключва USB CDC стандарта, както и доста USB библиотеки. Но тъй като имаш бридж, т.е. CDC се пренасочва към УАРТ то при сет баудрейт заявка е редно да се сетва баудрейта на УАРТ-а. Казвам редно е, ама дали е направено ти си знаеш...

Те тогава едва ли не USB stack-а трябва да ми сетъпне и UART-a, което е все едно в библиотека за i2c да вкараш инициализация на 16х2 LCD дисплей. Не ми се струва много удачно. Освен това по този начин всеки път като инициализирам USB COM ще инициализирам и UART.
Хавата е малко по-сложна. Тоя USB stack не се вижда от обикновения Arduino User. Той си се компилира, когато извикаш Serial.begin(), Ако е Serial.begin, то най-вероятно ще инициализира USB стек (ако платката няма FTDI), ако обаче нямаш FTDI и напишеш Serial0.begin(), тогава ще инициализира UART1, оттам Serial1.begin() ти е UART2. Имаш онаследяване на класове и инклуудване на библиотеки, при извикване на функции, макроси и т.н. За това най-просто и най-нагледно го представих така, както е показано на кодът ми. Едната функция инициализира USB Serial а другата UART. Модвам един път USB стека и ако потребителят иска, да си извиква функцията Serial.get_baud(). Ако ли не да си ползва платката, все едно, че ползва Пингуино (това е Пик аналогията на Ардуино).

Нищо не ти разбрах, нали имаш сорс на стек, който модифицираш?
Класове, наследявания...все някъде има някоя променлива и метод да я прочетеш.



Така написано, звучи като интерпретатор с джава .

На мен пък ми се струва, че точно в CDC имплементацията е мястото да сетъпваш UART-a. За какво друго ще я ползваш? Аналогията с I2C не ми се вижда правилна.
Като гледам автора на пиковското ардуино го е имплементирал някога (mySetLineCodingHandler), но после се е поотказал явно.
Ако толкова държиш да е извън CDC-то - допиши си някой callback функция, която да ти се вика от CDC при промяна на конфигурацията.