У нас с вами разный подход к комментированию кода. Я считаю, что сам код должен быть написан так, чтобы был понятен без комментариев. От этого у меня в коде длинные и осмысленные названия имен переменных, функций и так далее. Комментарии я использую для описания важных и неочевидных вещей, когда это действительно требуется, а также для отделения логических блоков в коде друг от друга. До сих пор я как-то умудрялся разбираться в своих проектах даже 20 летней давности. И другие люди тоже разбирались без проблем. А еще есть blame в Git и commit messages…
А если уж совсем позанудничать...
То я посмотрел код вашего проекта MIDI2USB, давайте для примера возьмем main() из main.c
WDT_Init(); // Disable WDTimer (not used)
PORT_Init(); // Initialize ports (UART, LEDs)
SYSCLK_Init(); // Set system clock to 48MHz
UART0_Init(); // Initialize UART0 @31250, 8-N-1
USBD_Init( &usbInitStruct ); // Initialize USB, clock calibrate
LED_IN = 1; // Blink LED
LED_OUT = 1; // Blink LED
IE_EA = 1; // Global enable IRQ
Если у вас функция WDT_Init не инициализирует watchdog, а запрещает его, функция PORT_Init() инициализирует не порт, а порты и так далее, то да, такой код лучше комментировать.
Я уже не говорю о том, какие проблемы бывают при расхождениях в коде и комментариях. И о том, что код вызывающий UART0_Init() не должен и не может знать о том что это на самом деле "// Initialize UART0 @31250, 8-N-1" в случае если он не передает эти параметры явно при вызове функции.
Да в конце-концов, посмотрите как оформлены дескрипторы у меня и у вас. И учитесь писать код так, чтобы не надо было комментировать каждую строчку. Судя по коду в вашем репозитории, вы пока еще это не очень хорошо умеете.
Максимальная скорость FT2232 по RS232 — 12 Mbaud, это оправдывает наличие больших буферов для того, чтобы не потерять данные в ситуации, когда мы приняли сразу большой пакет, а ПО не успело среагировать. Максимальная скорость, которая у меня получилась на STM32F103C8T6 — около 2 Mbaud, то есть в 6 раз медленнее. При этом, отношение размера буфера к максимальной скорости в моем случае даже выше.
Я очень консервативно отношусь к внесению изменений в прошивку. Изменение должно либо решать существующую и воспроизводимую проблему, либо добавлять новую функциональность. Избегание непонятных проблем вида «вдруг, где это надо…» не являются поводом для модификации прошивки.
Однако, если вы действительно встретитесь с проблемой правильным решением которой будет увеличение размера буферов, я с удовольствием это сделаю.
Если увеличивать только буфера на прием, то до 2 Кбайт точно можно. До 4 Кбайт возможно можно, надо смотреть. Только я не понимаю, зачем? Какую проблему вы хотите таким образом решить?
В этом проекте буфера на приём / передачу равны 1024 байтам. Если ПО успевает вычитывать данные из последовательного порта быстрее, чем они поступают по uart, то все будет хорошо. Если нет, то однажды случится переполнение буфера и часть данных будет потеряна. О таком событии прошивка сообщает хосту. На тестах я передавал многие мегабайты на скорости более 2 Мбит/с с порта на порт, и никаких переполнений не возникало. Но, конечно, если ПО или ОС «задумается», то шанс потерять данные есть. Если нужно гарантированно не терять данные, следует использовать аппаратный контроль потока (RTS/CTS).
RS-485 все же будет. К сожалению, аппаратной поддержки для этого в микроконтроллере нет, делаю программно. Пока непонятно до каких скоростей получится выдерживать требуемое стандартом время переключения DE.
Да, похоже от судьбы не уйдешь и придется все-таки делать поддержку управления конвертерами RS-485. Базово уже сделал, но не выкладывал. Там надо выдержать достаточно жесткие тайминги по управлению DE при переходе от передачи к приему и я сейчас пытаюсь это обеспечить.
Да FT4232H (FT2232H) — это прекрасная микросхема, кто бы спорил. И datasheet на нее я читал. Просто, как говорится, right sizing, для одних применений лучше она, для каких-то других — вариант на STM32 Blue Pill. Особенно, если последняя уже валяется в ящике стола. Опять же, у FT GPIO, а у STM32 Blue Pill возможность установки выходов в открытый сток… Под каждую задачу — свое решение.
В моем варианте, из всего перечисленного, отсутствует только /RI. Не самый нужный сигнал. "Полноценность" не сильно пострадала. Зато присутствует возможность управления параметрами сигнальных линий. Впрочем, надо будет подумать о реализации и /RI тоже, благо это делается тривиально. Спасибо за подсказку!
Вы забыли упомянуть, что FT4232 — это микросхема, а не готовая плата. Да, ее не нужно прошивать, но зато её нужно к чему-то припаять. Максимальная скорость действительно впечатляет — 12Mbaud, согласно datasheet. Но и цена кратно больше: отладочная плата на AliExpress стоит 800 руб. против 120 руб за STM32 Blue Pill. И если можно, расскажите поподробнее про "полноценность". Единственное различие, которое бросилось в глаза — это наличие на FT4232 сигнала RI, но с другой стороны, на FT4232 отсутствует возможность тонкой настройки входов/выходов (полярность, подтяжка, тип выхода).
В таких проектах очень важна мотивация. А что может мотивировать лучше, чем создание устройства, которым в первую очередь будешь пользоваться самостоятельно? Мне в повседневной жизни RS-485 совершенно ни зачем не нужен, а вот RS-232 очень даже. Но если вдруг понадобится RS-485, и я не найду подходящего мне устройства, то обязательно займусь.
Драйвер ничего не скажет, даже не узнает, что этот endpoint в действительности отсутствует. Драйвер в этот endpoint ничего сам не отправляет, это IN endpoint. Но это все-таки хак с точки зрения периферии микроконтроллера. Вот пример того как это сделано: https://github.com/eddyem/stm32samples/tree/master/F1-nolib/SevenCDCs
Один CDC требует для своей работы следующие endpoints: BULK IN, BULK OUT, INTERRUPT IN. В STM32F103C8T6 есть 8 двунаправленных endpoints. Один CDC ACM занимает два из них. Если надо ужаться и не жалко потерять возможность отправки notifications, то в качестве INTERRUPT IN endpoint в дескрипторе можно указать несуществующий номер endpoint. Таким образом на STM32F103C8T6 можно реализовать 7 CDC. Если надо ужаться, но при этом не хочется терять возможность отправки notifications, то рекомендую попробовать поделить один INTERRUPT IN endpoint между всеми CDC устройствами. Из стандарта не следует, что это не будет работать, более того, в структуре notification есть поле для номера интерфейса. Но я не тестировал такой вариант с реальными драйверами и ничего не могу сказать о том, как это работает на практике.
Хм. А как на счёт 10 см (или сколько там у автора) свитого из двух проводов кабеля с неизвестно каким волновым сопротивлением? На фоне этого сантиметр кривой разводки не выглядит таким уж жутким :) Но вообще, конечно, все по делу.
Автор дико крут. Целеустремленность и усидчивость уровня бог. Брюзжание на тему «извне пишется слитно» хочется произнести с поклоном и обращением «Простите, большой белый господин»...
Да, тогда понятно. Вы правы, без драйвера никак.
По USB? А что еще с этими данными происходило? Чем еще прошивка занималась, расскажите, пожалуйста. Это интересно!
У нас с вами разный подход к комментированию кода. Я считаю, что сам код должен быть написан так, чтобы был понятен без комментариев. От этого у меня в коде длинные и осмысленные названия имен переменных, функций и так далее. Комментарии я использую для описания важных и неочевидных вещей, когда это действительно требуется, а также для отделения логических блоков в коде друг от друга. До сих пор я как-то умудрялся разбираться в своих проектах даже 20 летней давности. И другие люди тоже разбирались без проблем. А еще есть blame в Git и commit messages…
То я посмотрел код вашего проекта MIDI2USB, давайте для примера возьмем main() из main.c
Если у вас функция WDT_Init не инициализирует watchdog, а запрещает его, функция PORT_Init() инициализирует не порт, а порты и так далее, то да, такой код лучше комментировать.
Я уже не говорю о том, какие проблемы бывают при расхождениях в коде и комментариях. И о том, что код вызывающий UART0_Init() не должен и не может знать о том что это на самом деле "// Initialize UART0 @31250, 8-N-1" в случае если он не передает эти параметры явно при вызове функции.
Да в конце-концов, посмотрите как оформлены дескрипторы у меня и у вас. И учитесь писать код так, чтобы не надо было комментировать каждую строчку. Судя по коду в вашем репозитории, вы пока еще это не очень хорошо умеете.
Максимальная скорость FT2232 по RS232 — 12 Mbaud, это оправдывает наличие больших буферов для того, чтобы не потерять данные в ситуации, когда мы приняли сразу большой пакет, а ПО не успело среагировать. Максимальная скорость, которая у меня получилась на STM32F103C8T6 — около 2 Mbaud, то есть в 6 раз медленнее. При этом, отношение размера буфера к максимальной скорости в моем случае даже выше.
Я очень консервативно отношусь к внесению изменений в прошивку. Изменение должно либо решать существующую и воспроизводимую проблему, либо добавлять новую функциональность. Избегание непонятных проблем вида «вдруг, где это надо…» не являются поводом для модификации прошивки.
Однако, если вы действительно встретитесь с проблемой правильным решением которой будет увеличение размера буферов, я с удовольствием это сделаю.
Если увеличивать только буфера на прием, то до 2 Кбайт точно можно. До 4 Кбайт возможно можно, надо смотреть. Только я не понимаю, зачем? Какую проблему вы хотите таким образом решить?
В этом проекте буфера на приём / передачу равны 1024 байтам. Если ПО успевает вычитывать данные из последовательного порта быстрее, чем они поступают по uart, то все будет хорошо. Если нет, то однажды случится переполнение буфера и часть данных будет потеряна. О таком событии прошивка сообщает хосту. На тестах я передавал многие мегабайты на скорости более 2 Мбит/с с порта на порт, и никаких переполнений не возникало. Но, конечно, если ПО или ОС «задумается», то шанс потерять данные есть. Если нужно гарантированно не терять данные, следует использовать аппаратный контроль потока (RTS/CTS).
Извините, но я не понял ваш вопрос. Максимальный размер какой посылки имеется в виду?
Спасибо, я уже тоже выше про этот AN написал. Примерно так и буду делать.
Почему нельзя? Вроде можно, у ST даже есть App note AN3070 на эту тему. Понятно, что это не так быстро, но все же лучше, чем ничего.
RS-485 все же будет. К сожалению, аппаратной поддержки для этого в микроконтроллере нет, делаю программно. Пока непонятно до каких скоростей получится выдерживать требуемое стандартом время переключения DE.
Да, похоже от судьбы не уйдешь и придется все-таки делать поддержку управления конвертерами RS-485. Базово уже сделал, но не выкладывал. Там надо выдержать достаточно жесткие тайминги по управлению DE при переходе от передачи к приему и я сейчас пытаюсь это обеспечить.
Добавил поддержку RI, обновил статью. Спасибо!
Да FT4232H (FT2232H) — это прекрасная микросхема, кто бы спорил. И datasheet на нее я читал. Просто, как говорится, right sizing, для одних применений лучше она, для каких-то других — вариант на STM32 Blue Pill. Особенно, если последняя уже валяется в ящике стола. Опять же, у FT GPIO, а у STM32 Blue Pill возможность установки выходов в открытый сток… Под каждую задачу — свое решение.
В моем варианте, из всего перечисленного, отсутствует только /RI. Не самый нужный сигнал. "Полноценность" не сильно пострадала. Зато присутствует возможность управления параметрами сигнальных линий. Впрочем, надо будет подумать о реализации и /RI тоже, благо это делается тривиально. Спасибо за подсказку!
Вы забыли упомянуть, что FT4232 — это микросхема, а не готовая плата. Да, ее не нужно прошивать, но зато её нужно к чему-то припаять. Максимальная скорость действительно впечатляет — 12Mbaud, согласно datasheet. Но и цена кратно больше: отладочная плата на AliExpress стоит 800 руб. против 120 руб за STM32 Blue Pill. И если можно, расскажите поподробнее про "полноценность". Единственное различие, которое бросилось в глаза — это наличие на FT4232 сигнала RI, но с другой стороны, на FT4232 отсутствует возможность тонкой настройки входов/выходов (полярность, подтяжка, тип выхода).
В таких проектах очень важна мотивация. А что может мотивировать лучше, чем создание устройства, которым в первую очередь будешь пользоваться самостоятельно? Мне в повседневной жизни RS-485 совершенно ни зачем не нужен, а вот RS-232 очень даже. Но если вдруг понадобится RS-485, и я не найду подходящего мне устройства, то обязательно займусь.
Драйвер ничего не скажет, даже не узнает, что этот endpoint в действительности отсутствует. Драйвер в этот endpoint ничего сам не отправляет, это IN endpoint. Но это все-таки хак с точки зрения периферии микроконтроллера. Вот пример того как это сделано: https://github.com/eddyem/stm32samples/tree/master/F1-nolib/SevenCDCs
Хм. А как на счёт 10 см (или сколько там у автора) свитого из двух проводов кабеля с неизвестно каким волновым сопротивлением? На фоне этого сантиметр кривой разводки не выглядит таким уж жутким :) Но вообще, конечно, все по делу.
Автор дико крут. Целеустремленность и усидчивость уровня бог. Брюзжание на тему «извне пишется слитно» хочется произнести с поклоном и обращением «Простите, большой белый господин»...