[rx3apf 0]

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

Логику -то включите. Адаптеры идут залитые и в экране. 

Правда, что ли ? Вы, простите, их (китайские адаптеры) вообще когда-нибудь в руках держали, или только по картинкам ?

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

А тут голая байда с пинами наружу. 

И что с того ? Каким боком тут супрессоры и прочий бред ?

 

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

По любому три отдельный адаптера будет удобней и функциональней 

Вот тут стоит вставить волшебное слово "IMHO". _Вам_ удобнее. А вот _мне_ - нет.

 

 

[AlexandrY 3]

Just now, rx3apf said:

Правда, что ли ? Вы, простите, их (китайские адаптеры) вообще когда-нибудь в руках держали, или только по картинкам ?

Вот тут стоит вставить волшебное слово "IMHO". _Вам_ удобнее. А вот _мне_ - нет.

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

[r2axz 0]

5 minutes ago, AlexandrY said:

Логику -то включите. Адаптеры идут залитые и в экране. 
А тут голая байда с пинами наружу. 
Читайте Hardware Design Guidelines от FTDI.

Далеко не все адаптеры идут залитые и в экране. И вам должно быть это хорошо известно, если вы "в теме". А те что идут залитые и в экране стоят на порядки больше денег. Еще раз, вам ничего не мешает залить и экранировать эту плату...

7 minutes ago, AlexandrY said:

По любому три отдельный адаптера будет удобней и функциональней  чем лишняя борда на столе представляющаяя собой постоянный головняк.  

У вас есть хотя бы один факт подтверждающий тезис о том, что эта плата представляет собой постоянный головняк? Если есть, не могли бы вы его, пожалуйста, озвучить? Я вот, например, гоняя эту плату с этой прошивкой на протяжении месяца, фигача в нее статикой, замыкая переодически не то и не туда, очень хорошо представляю как эта плата работает и что выдерживает. И мне просто интересно, что я упустил. Может быть поделитесь мудростью?

На счет удобства тоже странный тезис. Если для вашей задачи три занятых порта на хосте (или хаб) + провода является более удобным решением, чем одно устройство, то, пожалуйста, пусть так и будет. Для моих задач удобнее иметь одно композитное устройство.

И по поводу функциональности тоже прошу пояснить, в чем функциональнее?

[Vasily_ 45]

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

Читайте Hardware Design Guidelines от FTDI.

Они что стали выпускать адаптеры обвешанные супрессорами ?

Лично разбирал FTDI залитый адаптер, супрессоров и других защит не обнаружено, от слова совсем!

[r2axz 0]

2 minutes ago, AlexandrY said:

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

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

[rx3apf 0]

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

Китайские мы перестали покупать еще много лет назад.

Т.е. Вы вообще о их устройстве (конструктивном) представления не имеете. Ожидаемо.

 

Цитата

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

Это - не минусы. Это вообще ни о чем, просто фантазирование, не имеющее никакого отношения к обсуждаемой теме. Да и просто "ни о чем". Естественно, занимаясь макетированием-отладкой "открытого" устройства на столе, любой разработчик по возможности соблюдает аккуратность (дабы избежать улетучивания волшебного дыма из конструкции и приборов). Но, простите, тут ведь не ликбез для умственных инвалидов ? И каким образом какие-то супрессоры помогут ? Тут разве что пересадка головного мозга...

Изменено 26 ноября, 2020 пользователем rx3apf

[AlexandrY 3]

8 minutes ago, rx3apf said:

Тут разве что пересадка головного мозга...

А че так нервничаете?
Я же дал направление. Читайте Guideline и просвящаетесь.
Спорьте с авторитетными производителями, а не со мной.
 

12 minutes ago, r2axz said:

 материальный профит с которого равен нулю.

А в курсе что больше всего сейчас в мире зарабатывают на бесплатном софте? 

[r2axz 0]

40 minutes ago, AlexandrY said:

Читайте Hardware Design Guidelines от FTDI.

Ну что, открываем и читаем? AN_146_USB_Hardware_Design_Guidelines_for_FTDI_ICs.pdf, 2.2.1 Electrostatic Protection 

FTDI ICs are tested for ESD protection between 2.5KV and 3KV. While this is sufficient for most embedded applications, it is often desirable to provide additional ESD protection on the USB DP, USB DM and VBUS signals, as shown in Figure 2.2.

Из чего следует, что для большинства встраиваемых применений встроенная защита FTDI является достаточной. Да, дальше они пишут, что ЖЕЛАТЕЛЬНО установить дополнительную защиту по ряду линий, но достаточность встроенной защиты это никак не отменяет. Защита встроенная в STM32F103C8T6 имеет сходные характеристики. Опять же, дополнительная защита это хорошо, кто бы спорил, но категоричность ваших утверждений делает их неверными.

8 minutes ago, AlexandrY said:

А в курсе что больше всего сейчас в мире зарабатывают на бесплатном софте? 

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

 

8 minutes ago, AlexandrY said:

Я же дал направление. Читайте Guideline и просвящаетесь.

Я вот открыл гайдлайны. И увидел, что писали их адекватные люди, которые понимают что к чему и не делят мир на черное и белое. И с другой стороны вы со своим максимализмом. Цитата выше.

 

Изменено 26 ноября, 2020 пользователем r2axz

[jcxz 184]

35 минут назад, r2axz сказал:

Где вы тут увидели маркетинг? Я рассказал о бесплатном проекте, материальный профит с которого равен нулю.

Не обращайте внимания. Просто посмотрите другие посты этого же автора - всё поймёте.  

 

PS: Попробовал скомпилить Ваш проект под IAR, но не хватает файла "<stm32f1xx.h>". Понятно что в IAR-е есть аналогичный (iostm32f10xxB.h), но там описание I/O-регистров не один-в-один с GCC-шным - без полной перетряски всего исходного кода так просто не подменить этот файл. А GCC у меня нет и ставить лень.   Не могли бы Вы выложить этот файл? Вроде других недостающих файлов не заметил, но может ещё какие есть?

Да - и написано конечно компиляторо-зависимо. Так просто не перенесёшь на другой компилятор. Но это в принципе недолго поправить.

PPS: И на всякий случай и эти файлы тоже:

STM32_STARTUP = $(STM32CUBE)/Drivers/CMSIS/Device/ST/STM32F1xx/Source/Templates/gcc/startup_stm32f103xb.s
STM32_SYSINIT = $(STM32CUBE)/Drivers/CMSIS/Device/ST/STM32F1xx/Source/Templates/system_stm32f1xx.c
STM32_LDSCRIPT  = $(STM32CUBE)/Drivers/CMSIS/Device/ST/STM32F1xx/Source/Templates/gcc/linker/STM32F103XB_FLASH.ld

 

[r2axz 0]

2 minutes ago, jcxz said:

PS: Попробовал скомпилить Ваш проект под IAR, но не хватает файла "<stm32f1xx.h>". Понятно что в IAR-е есть аналогичный (iostm32f10xxB.h), но там описание I/O-регистров не один-в-один с GCC-шным - без полной перетряски всего исходного кода так просто не подменить этот файл. А GCC у меня нет и ставить лень.   Не могли бы Вы выложить этот файл? Вроде других недостающих файлов не заметил, но может ещё какие есть?

Да - и написано конечно компиляторо-зависимо. Так просто не перенесёшь на другой компилятор. Но это в принципе недолго поправить.

stm32f1xx.h является частью CMSIS, который доступен в составе куба вот отсюда: https://github.com/STMicroelectronics/STM32CubeF1

Выложить только один этот файл не получится: он тянет за собой кучу других include фалов, а кроме этого, я оттуда использую еще startup файл и скрипт линкера. Поэтому придется качать весь CMSIS.

Написано действительно с прицелом на gcc. Используются его нотации атрибутов и наверняка какое-то количество gcc c extensions. Но gcc - это свободный и доступный каждому инструмент, а IAR все таки платный и проприетарный. У меня не было ни одной причины писать открытый проект оглядываясь на проприетарный toolchain. Это ведь не только обеспечить компиляцию, это еще все протестировать, убедиться что нигде случайно ничего не сломалось. Все это занимает время, а время - ресурс ограниченный.

Поэтому заранее извиняюсь перед всеми теми, кто использует что-то отличное от gcc, но тратить время на обеспечение совместимости я не готов.

21 minutes ago, jcxz said:

И на всякий случай и эти файлы тоже:

Вот, о чем я и говорил, эффективнее будет скачать куб, так как даже вместе с этими файлами - это не все.

[AlexandrY 3]

17 minutes ago, jcxz said:

Не обращайте внимания. Просто посмотрите другие посты этого же автора - всё поймёте.  

Ха-ха, посмотрим сколько сможет продержаться  jcxz не излив где-нить здесь  свой желчный сарказм. 
Програмка ведь, скажем так, для профессионалов интереса не представляет. 
В SDK от Infineon, TI, NXP, ST и т.д. везде нынче есть примеры двух VCOM портов да еще и с RTOS будут. 
А три порта на 8-и эндпоинтах - фейк. 

[r2axz 0]

3 minutes ago, AlexandrY said:

В SDK от Infineon, TI, NXP, ST и т.д. везде нынче есть примеры двух VCOM портов да еще и с RTOS будут. 

Не могли бы вы обоснованно объяснить необходимость применения RTOS для переходника USB-Serial?

3 minutes ago, AlexandrY said:

А три порта на 8-и эндпоинтах - фейк. 

Ну давайте посчитаем? Итак, STM32F103С8T6 имеет в составе USB 8 двунаправленных эндпоинтов. Для реализации одного порта, без включения режима грязных хаков, нам требуется один BULK IN, один BULK OUT и один INTERRUPT IN эндпоинт. Это займет нам два двунаправленных эндпоинта. Умножаем на 3 порта, и получаем 6 занятых эндпоинтов. К этому добавляем Control EP0. Итого 7 эндпоинтов требуется для реализации трех портов. Немножко правда упираемся в доступную память юсб, поэтому приходится первому порту дать по 32 байта на эндпоинт, а остальным портам по 64, но ничего. Можно было бы еще ужаться, сохранив функционал, но ценой возможных проблем совместимости.

[r2axz 0]

29 minutes ago, AlexandrY said:

В SDK от Infineon, TI, NXP, ST и т.д. везде нынче есть примеры двух VCOM портов да еще и с RTOS будут.

До кучи, покажите хотя бы один пример реализации USB CDC устройства в SDK от любого из вышеперечисленных вендоров в котором CDC был бы реализован не на уровне "так, а вот тут мы навешали операционной системе лапши на уши что поставили все параметры так, как она от нас хотела, получили байтики, а дальше делайте с ними все, что хотите". А где реально было бы реализовано все, что у меня. Или опять оставите без ответа?

Изменено 26 ноября, 2020 пользователем r2axz

[jcxz 184]

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

stm32f1xx.h является частью CMSIS, который доступен в составе куба вот отсюда: https://github.com/STMicroelectronics/STM32CubeF1

Ок, попробую. стартап-файл и скрипт линкера - не слишком критично - свои могу взять, вряд-ли там что-то уникальное есть.

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

Это ведь не только обеспечить компиляцию, это еще все протестировать, убедиться что нигде случайно ничего не сломалось. Все это занимает время, а время - ресурс ограниченный.

Не обязательно так строго. Достаточно просто вещи типа __attribute__ ((packed)) оформить как например:

#if defined   (  __GNUC__  )
#define __packed __attribute__((__packed__))
#endif

И вроде как я понял из соответствующих хидеров CMSIS - GCC тоже должен понимать ключевое слово __packed? Или нет? 

А компиляторо-зависимые вещи и в свободно-распространяемом коде обычно описываются подобно:

#if   defined ( __CC_ARM )
  #define __ASM            __asm                                      /*!< asm keyword for ARM Compiler */
  #define __INLINE         __inline                                   /*!< inline keyword for ARM Compiler */
  #define __STATIC_INLINE  static __inline

#elif defined(__ARMCC_VERSION) && (__ARMCC_VERSION >= 6010050)
  #define __ASM            __asm                                      /*!< asm keyword for ARM Compiler */
  #define __INLINE         __inline                                   /*!< inline keyword for ARM Compiler */
  #define __STATIC_INLINE  static __inline

#elif defined ( __GNUC__ )
  #define __ASM            __asm                                      /*!< asm keyword for GNU Compiler */
  #define __INLINE         inline                                     /*!< inline keyword for GNU Compiler */
  #define __STATIC_INLINE  static inline

#elif defined ( __ICCARM__ )
  #define __ASM            __asm                                      /*!< asm keyword for IAR Compiler */
  #define __INLINE         inline                                     /*!< inline keyword for IAR Compiler. Only available in High optimization mode! */
  #define __STATIC_INLINE  static inline

#elif defined ( __TMS470__ )
  #define __ASM            __asm                                      /*!< asm keyword for TI CCS Compiler */
  #define __STATIC_INLINE  static inline

#elif defined ( __TASKING__ )
  #define __ASM            __asm                                      /*!< asm keyword for TASKING Compiler */
  #define __INLINE         inline                                     /*!< inline keyword for TASKING Compiler */
  #define __STATIC_INLINE  static inline

#elif defined ( __CSMC__ )
  #define __packed
  #define __ASM            _asm                                      /*!< asm keyword for COSMIC Compiler */
  #define __INLINE         inline                                    /*!< inline keyword for COSMIC Compiler. Use -pc99 on compile line */
  #define __STATIC_INLINE  static inline

#else
  #error Unknown compiler
#endif

(взято из того же CMSIS). Опять же, судя из этого фрагмента, GCC должен понимать слово __packed.

 

PS: Хотя конечно - хозяин-барин.  

[r2axz 0]

56 minutes ago, jcxz said:

Не обязательно так строго. Достаточно просто вещи типа __attribute__ ((packed)) оформить как например:

Спасибо, я знаю как это обычно делается, я сознательно этого не делал. Моя позиция такая: либо я заявляю поддержку компилятора, но тогда я (или тот, кому я доверяю) должен протестировать сборку на этом компиляторе, либо я не поддерживаю компилятор, и тогда я не делаю усилий для того, чтобы проект собирался этим компилятором. Если у вас есть время и желание, то вы можете внести все необходимые правки и оформить pull-request. Я буду только за. Но мне нужна будет бинарная версия прошивки на тесты.

56 minutes ago, jcxz said:

Опять же, судя из этого фрагмента, GCC должен понимать слово __packed.

Нет, в CMSIS packed для gcc определяется так (cmsis_gcc.h)

#define __PACKED                               __attribute__((packed, aligned(1)))

 

Вдогонку: кроме атрибутов, я использую также: zero-length arrays, offsetof, unnamed struct/union fields within structs/unions, designated initializers. Это так, навскидку. Наверняка что-то еще. Можно без этого было обойтись? Ну, конечно! Вот только мотивации у меня это делать не было, а удобство это мне дало. И я понятия не имею о том, как это все поддерживается IAR. Даже если я решу проблему атрибутов, я все равно не буду уверен, что код компилируется не попробовав его скомпилировать :) А оно мне надо? И потом, а почему собственно только IAR? Вон, там в вашем посте выше еще четыре компилятора... Поэтому no hard feelings, но половинчатых и непроверенных вариантов в main branch не будет.

Изменено 26 ноября, 2020 пользователем r2axz