Smalltalk › русский язык (Russian)

Pharo 1.3 и serial port

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

17 messages Options

vmusulainen-2

Pharo 1.3 и serial port

CONTENTS DELETED

The author has deleted this message.

kirand

Re: Pharo 1.3 и serial port

А как вы ответ получаете? Ставите опрос на цикл?

--
http://groups.google.ru/group/sugr

vmusulainen-2

Re: Pharo 1.3 и serial port

CONTENTS DELETED

The author has deleted this message.

kirand

Re: Pharo 1.3 и serial port

http://forum.world.st/serial-port-access-td108547.html

в последнем абзаце кое-что написано как правильно организовать считывание через #readInto:startingAt:. может поможет...

--
http://groups.google.ru/group/sugr

Борис Беркгаут

Re: Pharo 1.3 и serial port

In reply to this post by vmusulainen-2

Я очень извиняюсь за глупый вопрос, а зачем нужна задержка?

On Oct 24, 5:20 pm, Владимир Мусулайнен <[hidden email]> wrote:

> работает вот так
>
> initialize
> readProcess := [ [ self readFromSerialPort ] repeat ] fork.
>
> readFromSerialPort
> | read |
> (Delay forMilliseconds: 100) wait.
> read := serial readString.
> read
> do: [ :each |
> each ~= Character cr
> ifTrue: [ readBuffer nextPut: each ]
> ifFalse: [
> | answer |
> self addRoboAnswer: readBuffer contents.
> readBuffer reset ] ]
>
> Приведенная мною реализация вроде работает стабильнее, чем та, для
> которой я приводил логи, но тоже временами случается съедание
> ответов...
> Причем по ощущениям, чем чаще я читаю с порта данные, тем больше
> шансов, что они пропадут.
>
> On Oct 24, 5:08 pm, kirand <[hidden email]> wrote:
>
>
>
>
>
>
>
> > А как вы ответ получаете? Ставите опрос на цикл?

--
http://groups.google.ru/group/sugr

kirand

Re: Pharo 1.3 и serial port

очевидно, для того, чтобы программа не занимала все процессорное время?

--
http://groups.google.ru/group/sugr

Борис Беркгаут

Re: Pharo 1.3 и serial port

Правильно ли я понял, что readString неблокирующий, т.е. он вычитывает
сколько есть в буфере (в частности, пустую строку) и сразу
возвращается?

On Oct 25, 5:16 pm, kirand <[hidden email]> wrote:
> очевидно, для того, чтобы программа не занимала все процессорное время?

--
http://groups.google.ru/group/sugr

kirand

Re: Pharo 1.3 и serial port

ну да. читает все, что доступно из порта и выдает в виде aString

--
http://groups.google.ru/group/sugr

vmusulainen-2

Re: Pharo 1.3 и serial port

In reply to this post by Борис Беркгаут

CONTENTS DELETED

The author has deleted this message.

vmusulainen-2

Re: Pharo 1.3 и serial port

In reply to this post by Борис Беркгаут

CONTENTS DELETED

The author has deleted this message.

kirand

Re: Pharo 1.3 и serial port

In reply to this post by vmusulainen-2

У вас что-то получилось/решилось с проблемой?

--
http://groups.google.ru/group/sugr

vmusulainen-2

Re: Pharo 1.3 и serial port

CONTENTS DELETED

The author has deleted this message.

Борис Беркгаут

Re: Pharo 1.3 и serial port

Мне кажется, стоит задаться вопросом, насколько хорошо работает
буферизация при вычитывании из последовательного порта. Потому что
если ОС ничего не буферизует и VM ничего не буферизует, то вот и
объяснение: данные просто дропаются, ибо аппаратный буфер у
последовательного порта крохотный (16 байт).

Объяснить, почему чем чаще опрашивается порт, тем больше данных
теряется, я не могу.

On Oct 25, 10:03 pm, Владимир Мусулайнен <[hidden email]> wrote:

> Код который я привел в 3 посте этого треда работает относительно
> стабильно. Общие задержки перед очередным вычитыванием составляют 500
> мс.
> Если задержки уменьшать начинаются проблемы.
> Код, на который который вы дали, делает примерно тоже самое. В коде у
> них кстати ошибка, есть ;). Точнее, недочет сильный. но это ладно...
>
> Резюмируя: проблема пока отступила, но что-то там не так чисто. Я еще
> буду её исследовать подробнее.
>
> On 25 окт, 20:29, kirand <[hidden email]> wrote:
>
>
>
>
>
>
>
> > У вас что-то получилось/решилось с проблемой?

--
http://groups.google.ru/group/sugr

vmusulainen-2

Re: Pharo 1.3 и serial port

In reply to this post by vmusulainen-2

CONTENTS DELETED

The author has deleted this message.

Dennis Schetinin

Re: Pharo 1.3 и serial port

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

10 ноября 2011 г. 0:24 пользователь Владимир Мусулайнен <[hidden email]> написал:

Я еще раз наткнулся с проблему работы Pharo с последовательным портом.
На этот раз уже с другим устройством (ультразвуковой радар URM37).
Вот описание проблемы:
Есть устройство, подключается к виртуальному последовательному порту.
Устройство в ответ на запрос отвечает после некоторой паузы (десятки
миллисекунд) некие данные размером 4 байта. Данные имеют следующий вид
1 байт - тип данных.
2 и 3 байты - полезные данные
4 байт - сумма предыдущих трех байт.

Я реализовывал два алгоритма работы с устройством в pharo.
Вариант А.
1. Отправляем запрос на устройство.
2. Ждем 200 миллисекунд.
3. Читаем ответ с порта методом readString.
4. Отправляем следущий запрос

Результат: ответ всегда в pharo получаем верным. То есть размер ответа
равен четырем байтам и он есть всегда.

Вариант Б.
1. Отправляем запрос на устройство.
2. В цикле (но не более 500 мс) читаем с порта данные методом
readString, пока размер считанных данных не станет больше или равным 4
байтам. То есть если в течении 500 мс мы так и не прочитали с порта
данных на 4 или более байт, то отправляем следующий запрос. Задержки
между запросами данных с порта нет.
3. Отправляем следущий запрос.

Результат: данные читаются неустойчиво.
Иногда мы можем с порта прочитать 5 байт. Иногда 0 байт.
Наиболее показателен получение 5 байт. Устройство отвечает по 4 байта.
Предыдущий ответ мы вычитали полностью (все 4 байта). Делаем следующий
запрос и тут к нам прилетело 5 байт. Откуда?! Итог: нельзя постоянно
дергать в Pharo последовательный порт запросами на чтение.

Портировал алгоритм Б на VisualWorks 7.7 Использовал пакет
NTOSSupportApp. Там есть класс который оборачивает вызовы WinApi.
Читает все отлично. Все приходит верно, по 4 байта.

Вывод: SerialPortPlugin в pharo имеет огрехи в работе.
Я пока не готов писать свой плагин дла Cog VM. Вероятно, реализую
обертку вызовов WinAPI через FFI.

Вот как-то так.

On 24 окт, 03:12, Владимир Мусулайнен <[hidden email]> wrote:
> Кто-нибудь работал из pharo с последовательным портом?
>
> У меня ситуация такая, что я шлю на внешний микроконтроллер команду и
> слушаю ответ.
> Потоки записи (отправки команды) и чтения (ожидания ответа) - два
> разных потока.
> Задержки, примерно, по 300 мс в каждом после каждого цикла записи/
> чтения.
>
> Так вот, чтение из порта временами возвращает пустую строку, теряет
> данные, хотя сниффер COM-порта показывает, что данные с
> микроконтроллера поступают.
> Например, это лог чтения порта в pharo
>
> 02:51:05
> distance: 76
> 02:51:05
> distance: 76
> 02:51:05
> distance: 75
> 02:51:06
> distance: 75
> 02:51:06
> distance: 75
> 02:51:06
> distance: 76
> 02:51:18
> distance: 77
>
> Последний ответ принят позже предпоследнего на 12 сек. Хотя
> предыдущие ответы читаются по три в секунду. После приема ответа в 18
> секунд больше ничего из порта не прочитали.
> А это лог сниффера, по нему видно, что данные на порт приходили.
>
> 34985 2:51:05 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 36 0d 0a
> distance: 76..
> 34991 2:51:05 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 36 0d 0a
> distance: 76..
> 34997 2:51:06 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 35 0d 0a
> distance: 75..
> 35003 2:51:06 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 35 0d 0a
> distance: 75..
> 35009 2:51:06 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 35 0d 0a
> distance: 75..
> 35015 2:51:06 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 36 0d 0a
> distance: 76..
> 35021 2:51:07 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 36 0d 0a
> distance: 76..
> 35027 2:51:07 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 35 0d 0a
> distance: 75..
> 35033 2:51:07 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 35 0d 0a
> distance: 75..
> 35039 2:51:08 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 36 0d 0a
> distance: 76..
> 35045 2:51:08 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 36 0d 0a
> distance: 76..
> 35051 2:51:08 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 35 0d 0a
> distance: 75..
> 35057 2:51:09 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 36 0d 0a
> distance: 76..
> 35063 2:51:09 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 35 0d 0a
> distance: 75..
> 35069 2:51:09 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 35 0d 0a
> distance: 75..
> 35081 2:51:10 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 36 0d 0a
> distance: 76..
> 35087 2:51:10 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 35 0d 0a
> distance: 75..
> 35093 2:51:10 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 35 0d 0a
> distance: 75..
> 35099 2:51:11 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 35 0d 0a
> distance: 75..
> 35105 2:51:11 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 35 0d 0a
> distance: 75..
> 35111 2:51:11 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 35 0d 0a
> distance: 75..
> 35117 2:51:12 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 36 0d 0a
> distance: 76..
> 35123 2:51:12 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 35 0d 0a
> distance: 75..
> 35129 2:51:12 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 36 0d 0a
> distance: 76..
> 35135 2:51:12 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 36 0d 0a
> distance: 76..
> 35141 2:51:13 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 36 0d 0a
> distance: 76..
> 35147 2:51:13 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 36 0d 0a
> distance: 76..
> 35153 2:51:13 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 36 0d 0a
> distance: 76..
> 35159 2:51:14 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 36 0d 0a
> distance: 76..
> 35165 2:51:14 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 36 0d 0a
> distance: 76..
> 35171 2:51:14 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 36 0d 0a
> distance: 76..
> 35177 2:51:15 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 36 0d 0a
> distance: 76..
> 35183 2:51:15 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 36 0d 0a
> distance: 76..
> 35189 2:51:15 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 36 0d 0a
> distance: 76..
> 35195 2:51:15 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 36 0d 0a
> distance: 76..
> 35201 2:51:16 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 36 0d 0a
> distance: 76..
> 35207 2:51:16 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 36 0d 0a
> distance: 76..
> 35213 2:51:16 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 35 0d 0a
> distance: 75..
> 35219 2:51:17 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 36 0d 0a
> distance: 76..
> 35225 2:51:17 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 37 0d 0a
> distance: 77..
> 35231 2:51:17 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 37 0d 0a
> distance: 77..
> 35237 2:51:18 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 37 0d 0a
> distance: 77..
> 35243 2:51:18 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 37 0d 0a
> distance: 77..
> 35249 2:51:18 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 37 0d 0a
> distance: 77..
> 35255 2:51:18 IRP_MJ_READ UP 64 69 73 74 61 6e 63 65 3a 20 37 37 0d 0a
> distance: 77..
>
> По баг-треккерам Cog VM особо про последовательный порт не говориться.
> Понятно, что направление неприоритетное...

--
http://groups.google.ru/group/sugr

--
Dennis Schetinin

--
http://groups.google.ru/group/sugr

vmusulainen-2

Re: Pharo 1.3 и serial port

CONTENTS DELETED

The author has deleted this message.

Denis Kudriashov

Re: Pharo 1.3 и serial port

Да, очень интересно.
Хорошо, что я в свое время не стал заморачиваться с ком портом в фаре, отдали задачи сишнику, а я уже использовал его длл-и

10 ноября 2011 г. 6:21 пользователь Владимир Мусулайнен <[hidden email]> написал:

Было бы неплохо еще хотя бы примерно обозначить проблему в плагине. Я
думаю, в этом случае, быстрее и исправят.

On 10 ноя, 06:00, Dennis Schetinin <[hidden email]> wrote:
> Очень полезные и основательные наблюдения. Очевидно, нужно проинформировать
> фаро-сообщество.
>

--
http://groups.google.ru/group/sugr

--
http://groups.google.ru/group/sugr