Адресная лента и zigbee

А не может случиться так, что “шевеление” появится сразу (после отправки первого “цвета” а то и вообще первого байта либо первого бита)?
Светодиод ведь не знает, последний он или нет, поэтому, что-то получив, должен что-то передать дальше.

Шевеление, теоретически, может начаться всегда.
Но, по спецификации, пиксель начинает форвардить только забрав себе 3 байта.

Я допустил 3 варианта именно потому, что не читал спецификацию.
Теперь понятно, что вариант только один - “шевеление” на выходе последнего появится после передачи на первый трех байт.

Не, пока к последнему диоду не придет посылка от предпоследнего - шевеления быть не должно.

Я вижу проблему в другом - @Komandir предлагает считать сколько передано посылок в ленту до получения ответа:

но ведь передача сигнала по ленте из, скажем, 300 пикселей - дело вовсе не мгновенное. И в момент, когда из хвоста ленты вылезет ответ - вполне возможно мы успеем послать “в голову” уже не 300 посылок, а 301 или 302… а может и все 350… лень прикидывать с цифрами

По-моему это делает метод сложным и ненадежным. Посылать в ленту посылки. содержающие номер диода - куда как проще. и Главное. однозначнее.

1 лайк

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

Данная ситуация предполагает существование некоего буфера, о котором не знает МК. Однако, в WSxxxx такового нет. Будет задержка на пролёт байта до последнего пикселя, но разницы в штуках между посланным количеством и принятым я не ожидаю.

Можно поступить другим образом, если существуют опасения - к концу приближаться неким методом половинного половинного деления. Чтобы точно выплёскивать в страйп известное кол-во байт и слушать - вылезет с того конца или нет.

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

Вот, что пишут наши китайские собратья:

IC use single NZR communication mode.After the chip poweron reset, the DIN port received data from controller, the first IC collect initial 24bit data then sent to the internal data latch, theother data which reshaping by the internal signal reshaping amplification circuit sent to the next cascade IC through the DO port. After transmission for each chip, the signal to reduce 24bit.

это, как бы, входит в противоречие с твоими же словами:

Получается, что задержка всегда будет ЗАВЕДОМО более одного пикселя

Т.е. ты имеешь ввиду, что пока в элементах по цепочке происходит регенерация сигнала, МК успеет напихать в первый ещё 50 байт?
Я представляю это так: после ресета пиксель начинает получать биты, отсчитывает 24 шт и закорачивает вход и выход (условно, через регенератор). Потом синхронно начинают телепаться выходы всех принявших данные пикселей. Т.е. распространение как-бы просто по проводу идет.

1 лайк

Да, может и так.
Твой вариант весьма разумен.

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

Kakmyc.
А почему бы не проверить свою ошибочную теорию ?

Выход крайнего пикселя заводим на INT0 (2ой IO в концепции Arduino).

Я понимаю что в каждом процессоре сидит по миллиону китайцев они всё там внутри разруливают, но пихать даже 100 китайцев внутрь каждого NeoPixel это где же их (китайцев) столько взять то ???

А где гарантия того, что это будет работать точно так же как это работает на физическом уровне ?
У меня вот лента (точнее плашка на 8 диодов)при выключении и повторном включении выдает те же цвета, которые были на ней в момент выключения.
В эмуляторе вряд ли это реализовано.

Это нигде не реализовано. Если выключить и дать постоять, то ничего само не включится

Kakmyc
Вам фото моей живой ленты прислать ???

attachInterrupt(0, check_out, CHANGE);

CHANGE гарантирует отлов именно шевеления на выходе ленты, а оно происходит даже если мы одни нули шлём в ленту - протокол такой

поинтересуюсь, в 50 строке в коде NOP с какой целью вставлен?

ua6em
Это для соблюдения интервалов по протоколу
NOP - один такт
RJMP .+0 - два такта

Data Transfer Time
T0H 0-code, High-level time 220ns~380ns
T1H 1-code, High-level time 580ns~1.6µs
T0L 0-code, Low-level time 580ns~1.6µs
T1L 1-code, Low-level time 220ns~420ns
RES Frame unit, Low-level time > 280µs

У меня интервалы 250ns и 625ns (4 такта и 10 тактов при 16 МГц)

Спасибо за информацию. Но все почитав, я понял, что помнить количество диодов на каждой ленте, не такая и проблема))

Этот вывод - неплохой результат для дискуссии в полтораста сообщений…

На самом деле, все это интересно и будет реализовано.