Недавно я изо всех сил пытался загрузить на свой Синяя таблетка (BP) и Maple Mini (мм) клоны. Проблема, возникшая в том, выбираю ли я /dev/tty.* или /dev/cu.* Порт моего USB в серийный конвертер.

С использованием STM32Flash, только а /dev/tty.* порт работает, а не /dev/cu.* порт. Для STM32Loader.пирог, Оба работают. Для maple_upload, только /dev/cu.* порт работает. Это было чрезвычайно запутанно.

После небольшого поиска я наткнулся на следующее: Arduino в OS X 10.9 Маверикс - Проблемы с последовательным портом. И вот это было, Appleusbftdi вызывал проблемы! Я использую FTDI базовый адаптер, и после выгрузки драйвера Apple FTDI и только загрузки драйвера FTDI, все снова работает на /dev/cu.* порт Только STM32Flash отказываться работать с /dev/cu.* порт, что бы.

Как всегда, ymmw

Мои адаптеры FTDI только что прибыли, поэтому, если у меня будет время на выходных, я посмотрю, есть ли у них такая же проблема на моих машинах OSX

Я должен сказать, что я уже применил этот взлом Apple_usb_ftdi давным -давно. (Энергия постоянно рухнула), так что это может быть причиной, по которой у меня не было таких неприятностей. Может быть, хороший момент для справки/ручного руководства?

Привет, Роджер

У вас было время проверить ваши адаптеры FTDI?
Rogerclark написал:Мои адаптеры FTDI только что прибыли, поэтому, если у меня будет время на выходных, я посмотрю, есть ли у них такая же проблема на моих машинах OSX

Да

Попробовал это сегодня днем

Проблема, по -видимому, заключается в STM32Flash

Кажется неспособным открыть устройства Cu

Я не писал это, и я не думаю, что он поддерживает кого -либо, так как мне уже приходилось делать некоторые исправления для ошибок на ПК, где он позволил номера порта только от 1 до 9 (i, e однозначная цифра числа)

STM32Flash немного запутан, поскольку он поддерживает как Windows, так и OX и Linux, поэтому он должен разделить наборы кода взаимодействия с низким уровнем коммуникации, и я думаю, что MakeFile решает, какой файл низкого уровня C в компиляцию

Я быстро посмотрел на код (он в репо https: // github.com/rogerclarkmelbourne/ ... Серийный/SRC
)

Таким образом, вы можете взглянуть на код, чтобы понять, почему вызов Open () выключается на устройстве CU

Но это не тот драйвер, который виноват, потому что я подключил серийный адаптер FTDI USB с HW Serial 1 (PA9 и PA10) и пишу эскиз, используя Serial1.println - затем загрузил эскиз через загрузчик на плату.
И IDE может открыть устройство Cu, и я вижу текст, подходящий из аппаратного сериала 1.

Так что это просто ошибка в STM32Flash

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

Посмотрев быстро на код, я думаю, что нашел виновную линию около 206 Serial_posix.c моего 0.4 Версия:
/* 1. check device name match */ if (strncmp(ops->device, "/dev/tty", strlen("/dev/tty"))) return PORT_ERR_NODEV;

Мартин

Хорошо замечен.

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

Или, если есть причина для проверки, нам нужно проверить на устройства "Cu", а также TTY.

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

Ну, может быть, решение № 1 тоже хорошо: удаление этой проверки !
Потому что почему автор хотел убедиться, что то, что мы написали в командной строке, является правдой, поскольку я могу решить создать символическую ссылку, такую ​​как /dev /ftdi, указывающий на /dev /ttyusb99, что мой выбор ...

Мартин

Хорошая мысль о символах

Я на самом деле только что попробовал вариант № 2, и это исправило проблему. Но так же полностью удалит чек.

Одна вещь, которую я только что заметил с клоном FDTI, у меня есть то, что это не так надежно при высокой скорости бода, я не дефол.

Редактировать кстати. Есть проблема с .Файл находится в GIT, мне нужно установить GIT, чтобы исключить его,

Я согласен с Мартином и Роджером.

Поскольку мы будем (в основном) использовать STM32Flash через Arduino IDE, Мы знаем, что устройство/порт отправлен STM32Flash будет либо /dev/tty или /dev/cu, Таким образом оба будут работать.

Если STM32Flash используется «автономный», тогда валидация имеет смысл, но для наших целей, я думаю, лучше удалить проверку, чтобы получить STM32Flash работа с обоими, так как STM32Flash мигает быстрее, чем STM32Loader.пирог

Сделанный.

Я удалил тест на /dev /tty

Есть еще тест, чтобы увидеть, действите ли путь вообще, но это все.

И, кажется, хорошо работает на OSX.

Спасибо, Роджер!