[mantech 42]

10 минут назад, quark сказал:

Прием, так же, придется обрабатывать.

Это уже сделано и работает норм, к счастью))

 

11 минут назад, quark сказал:

Большинство аппаратных UART в МК или ПК не дают возможности оперативно "рулить" девятым битом.

Ну не знаю, в АВРках например такой проблемы нет от слова вообще, а вот там, где 16550 уарт - там да, есть...

[quark 48]

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

Ну не знаю, в АВРках например такой проблемы нет от слова вообще, а вот там, где 16550 уарт - там да, есть...

В PIC-ах такой проблемы тоже нет. Проблема потом пристыковать устройство с таким протоколом, например, к ПК, напрямую.

[Arlleex 160]

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

Ой, ну может объясняю недоходчиво, есть протокол, работает с 9и битными посылками ВСЕГДА. Я должен передавать пакеты с установленным 9 битом 1 байт и сброшенным остальные, принимаю тоже 9и битные посылки, но не анализирую принятый 9 бит.

Если не секрет, что за чудо-устройство сделано с таким протоколом обмена? Потому как мне это до боли знакомая ситуация.

[quark 48]

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

Потому как мне это до боли знакомая ситуация.

Есть такие чудо-устройства. Причем, силовые...
С разработчиком одного из них мне как-то довелось пообщаться. На прямой вопрос - зачем такой геморрой? - он ушел от ответа...
Как я понял, люди совершенно не заинтересованы в легкой интеграции своей аппаратуры в какие-либо сторонние системы.
Видимо, считают, что пользователь должен покупать именно их аппаратуру управления...

[mantech 42]

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

Потому как мне это до боли знакомая ситуация.

Протокол платежной системы MDB.

2 часа назад, quark сказал:

например, к ПК, напрямую.

Ну да, просто уже давно не использую ПК в качестве контроллера)))

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

На прямой вопрос - зачем такой геморрой? - он ушел от ответа...

Если это более-менее какой-то стандарт - то этот вопрос бессмысленный, никто переделывать не будет. Как в моем случае, какие-то "гении" в свое время вкорячили этот 9й бит, при том, что он там нафиг не нужен, и для контроля целостности применяется CRC...

[mantech 42]

19 часов назад, quark сказал:

В PIC-ах такой проблемы тоже нет.

Вообщем, как оказалось и тут проблема не большая. Сначала думал, что rs485 режим больше подходит, но т.к. так и не понял, что за флаг там нужно сбрасывать, а без сброса он принимает только 1й байт, да и самое главное - мне этот протокол нужен и в v3s, а там такого режима нет вообще, решил работать с битом четности, там нет ничего сложного, кроме проблемы перезаписи бита в прерывании, но решение нашлось само собой:

В результате не нужно выжидать первый байт - все работает в прерываниях.

Изменено 20 апреля, 2023 пользователем mantech

[GenaSPB 11]

22 hours ago, mantech said:

очему не нужен, нужен, причем желательно фулл дуплекс...

Прием делаете на UART, передачу на SPI (по 16 бит всего)
zero-b0 b1 b2 b3 b4 b5 b6 b7 b8 one one one one one one one one...
Можете переключить в режим LSB FIRST чтобы не переставлять биты

 

unsigned v = (0xFFFF << 10) | (bytetosend << 1);
* (volatile uint16_t *) & SPI0->SPI_TXD = __bswap16(v);

 

Изменено 20 апреля, 2023 пользователем GenaSPB

[mantech 42]

4 часа назад, GenaSPB сказал:

Прием делаете на UART, передачу на SPI (по 16 бит всего)

Нее, так не подошло бы, для уарта выделено 2 ноги, т.к. может использоваться не только с MDB, но и с другими протоколами, которые используют обычный 8-n-1 режим, а смультиплексировать ноги с spi я не смогу, да и не за чем - все и так работает...