да эта. слои одинаковые и дублируются, смысл показывать все светодиоды нет. так часто делают при многократном повторении. но вот как формируется один слой непонятно.
озу не просто больше. она не сдохнет так быстро как eeprom, и по скорости работы во много раз выше
Последний девятый сдвиговый регистр определяет какой именно слой будет подключен к положительному выводу питания. Например в нем записано 01111111, тогда на базу первого транзистора, подастся 0 и он откроется ввиду того, что он pnp, а все остальные останутся закрытыми.
Предыдущие 8 регистров определяют какие из вертикалей будут сидеть на нуле, а какие на 1 (5v). Если на лапе регистра стоит 0, то ток пойдет через светодиод, так как на горизонтальной шине (слое, этаже) висит +5 V (если слой включен), если же на выводе регистра тоже 5v, то ток естесственно не пойдет, так как нет разности потенциаллов.
А геометрически в кубе подключение к выводам регистров следующее: допустим мы смотрим на куб сверху, тогда в этом виде есть матрица 8x8: 8 сток и 8 столбцов. 8 выводов превого регистра подключены к первой строке, 8 выводов второго ко второй и т.д. получается, что первый регистр имеет координату x=1, второй x=2 и т.д. А внутнри одной строки 1 пин регистра подключен первому столбцу (y=1), второй к y=2 и т.д. x и y можно переобозначить, если хочется.
Ну, можно и в оперативку загрузить строки из флешки. Кстати, а сколько бит влезет в оперативку arduino? Я так понимаю нас интересует EEPROM, там 512 байт, то есть 4096 бит. Ага пусть будет так:
1 кадр определяет свечение всех 512 светодиодов, и представляет 3-d изображение, сформированное разверткой по слоям.
...
Однако важно, чтобы EEPROM работала подобно сдвиговым регистрам не перезаписываясь полностью, а сдвигая информацию в хвост. С хвоста же и будем читать текущий кадр.
...тогда получится однофигственно, что с SD-карты читать напрямую, что через EEPROM. А с другой стороны у нас есть 1/24 секунды на запись нового кадра в EEPROM. Короче пока непонятно, слишком много тусовок информации с места на место получается. Может кто уже этим занимался?
Только-что заказал с алиэкспресса sd-шилд и sd-карту :)
EEPROM и RAM (она же ОЗУ, она же оперативка) - это разные виды памяти.
Для Ваших целей EEPROM вообще не нужна.
Если планы не слишком грандиозны, для хранения данных лучше всего использовать ту же flash, в которой хрянятся программы. И емкость этого вида памяти, кстати, максимальна. Если же этого недостаточно, можно посоветовать хранить данные на карте памяти, считывая оттуда в оперативку. Скажем, фрагментами по килобайту.
И еще, ни один из видов памяти нельзя напрямую использовать как стек или очередь (аналог сдвигового регистра), хотя такую структуру и можно организовать программно. ПРавда, не понимаю, зачем это может понадобиться.
Кстати, Вы говорите о имеющейся паузе в 1/24 секунды. Это значит, что яркостью светодиодов Вы никак не управляете?
Один кадр содержит 576 бит. Будем считать что мультик длится скажем 10 секунд, если делать 24 кадра в секунду, то какой-нибудь мультик танцующего человека, потребует 10*24*576=138240 бит=17,28 кБ. А это уже исчерпает все ресурсы, поэтому sd-карта или другой носитель информации необходим.
Вы правы, необязательно делать сдвиговые регистры из памяти ардуино.
Говоря о паузе 1/24 секунды (это кстати 40 мсек) я имел ввиду, что человеческому глазу достаточно частоты 24 Гц, чтобы ему казалось что все плавно и без скачков движется (хотя в кубике 8*8*8 этого эффетка все равно не будет). То есть каждый кадр висит на кубе 1/24 секунды, и пока у нас есть свободное время можно загружать следующие кадры. А яркостью можно управлять, если при развертке одного кадра по слоям некоторые светодиоды в слое зажигать чаще других. Но не знаю стоит ли этим заморачиваться, это сильно усложнит процесс вывода изображения на куб. В этом случае проще ввести в стоку информацию о яркости (яркости одного слоя) и делать развертку уже в самом слое, где время простоя будет зависеть от параметра яркости.
Ну и кроме того, сейчас мы вообще мало чем управляем :) Мы этот кубик только собрали и залили в него пару очень простых эффектов типа рандомного дождя и бегания светодиодов по кругу. Я вот просто думаю как теперь раскрыть потенциал этого кубика.
А также правильнее, наверное, и информацию о времени в течении которого висит один кадр записывать в том-же файле, тогда проще сделать динамику. Основная задача в разработке ПО на компе которая будет генерировать строки по нарисованным картинкам. Вообще, задача мне видится очень интересной!
fss4, вероятно, Вы ориентируетесь на время показа одного кадра в кино. Должен заметить, это далеко не единственный вариант и далеко не самый лучший. ПРактика показывает, что без motion blur этой частоты смены кадров для обеспечения плавности движения совершенно недостаточно. Это во-первых.
Во-вторых, Вы применяеие динамическ4ую индикацию, т.е. в течение 40 мс Вы по очереди показываете 8 слоев, т.е. на 1 слой приходится по 5 мс с интевалом 35 мс, а это уже весьма заметное мерцание. Т.е. изображение будет восприниматься как мерцающее на манер стробоскопа.
Чтобы мерцания не было заметно, период отогбражения сделует уменьшить по крайней мере до 16, а лучше до 12 мс.
Опираться нужно именно на время гашения, которое в Вашем случае составит 35 мс, тогда как в кино оно примерно 13 мс - там 2/3 времени кадр экспонируется и лишь 1/3 времени тратится на то, чтобы передвинуть пленнку.
Другими словами, еще на стадии проектирования неплохо бы ориентироваться на физиологию зрительного анализатора человека, а не пытаться использовать непонятно откуда взявшиеся цифры.
Еще, непонятно, почему у Вас в "изображении" 576 бит, когда, казадлсь бы, должгл быть 512. Откуда еще 64? Или у Вас куб 8*8*9?
Ну и по поводу эффектов. Как правило, эффекты используются циклические, т.е. одну и ту же последовательно "кадров" прокручивают по много раз. Сделать "кино" с уникальными от начала до конца кадрами - это задача несколько другой ресурсоемкости, и неочевидно, что она под силу Ардуине. По крайней мере, на 328 чипе.
...Вы ориентируетесь на время показа одного кадра в кино.
Да, я на это и ориентировался, вполне может быть, что зря. Делать эффекты размытия мне не хочется, это сильно усложнит процесс рисования кадров.
andriano пишет:
Во-вторых, Вы применяеие динамическ4ую индикацию, т.е. в течение 40 мс Вы по очереди показываете 8 слоев, т.е. на 1 слой приходится по 5 мс с интевалом 35 мс, а это уже весьма заметное мерцание. Т.е. изображение будет восприниматься как мерцающее на манер стробоскопа.
Чтобы мерцания не было заметно, период отогбражения сделует уменьшить по крайней мере до 16, а лучше до 12 мс.
Я предполагал без задержек последовательно выводить 8 слоев без искуственных задержек в течении 1/24 сек, тогда мерцаний недолжно быть. Какая у системы будет скорость непонятно, возможно придется либо ввести дополнительный delay(1), либо наоборот попытаться увеличить скорость, как это предлагал jeka_tm через SPI.
andriano пишет:
Опираться нужно именно на время гашения, которое в Вашем случае составит 35 мс, тогда как в кино оно примерно 13 мс - там 2/3 времени кадр экспонируется и лишь 1/3 времени тратится на то, чтобы передвинуть пленнку.
В нашем кубе каждый слой будет гореть не больше чем 1/8 от времени кадра, а по факту даже меньше, так как еще сколько-то времени затратится также на загрузку данных в регистры. Чтобы увеличить время экспонирования придется делать каждый слой независимым, а это затруднительно с точки зрения пайки и кол-ва регистров. В бегущих строках всего один слой, и поэтому можно себе позволить все время затратить на экпонирование, а в многослойной структуре слои друг другу будут мешать, так как будут зажигаться лишние пикселы, придется зажигать лишь один слой из восьми.
andriano пишет:
Еще, непонятно, почему у Вас в "изображении" 576 бит, когда, казадлсь бы, должгл быть 512. Откуда еще 64? Или у Вас куб 8*8*9?
Дело в том, что в каждой строке помимо 64 бит, задающих состояние светодиодов в слое есть еще и адрес слоя, на котором должны загореться светодиоды, это еще 8 бит. И того в одной строке 72 бита. А строк в одном кадре 8 штук, 8*72=576.
andriano пишет:
Ну и по поводу эффектов. Как правило, эффекты используются циклические, т.е. одну и ту же последовательно "кадров" прокручивают по много раз. Сделать "кино" с уникальными от начала до конца кадрами - это задача несколько другой ресурсоемкости, и неочевидно, что она под силу Ардуине. По крайней мере, на 328 чипе.
Но это гораздо интереснее. Думаю из ресурсов необходим только достаточный объем памяти и быстрое чтение из нее + загрузка в регистры. А вообще, говоря о мультике я предпологал сделать циклический мультик, делать большие мультики сложно просто с точки зрения рисования огромного количества кадров, а делать какой-то 3d-софт автоматизирующий процесс мне кажется черезчур сложной задачей.
Я подумываю над редактором, типа paint, где было бы удобно рисовать матрицу 8x8x8. Программа эта должна поддерживать копирование внутри подматриц 8x8 и между ними, также трансляцию и возможно поворот. Тогда процесс рисования кадров упростится. Естесственно, она должна уметь визуализировать нарисованное в виде похожем на кубик, экспортировать последовательность кадров и показывать мультик.
Но сначала, конечно, нужно убедиться что система с sd-картой будет адекватно работать.
Я предполагал без задержек последовательно выводить 8 слоев без искуственных задержек в течении 1/24 сек, тогда мерцаний недолжно быть. Какая у системы будет скорость непонятно, возможно придется либо ввести дополнительный delay(1), либо наоборот попытаться увеличить скорость, как это предлагал jeka_tm через SPI.
Это как?
Распишите поподробнее, сколько мс предполагается экспонировать каждый слой и с каким интервалом.
Цитата:
В нашем кубе каждый слой будет гореть не больше чем 1/8 от времени кадра, а по факту даже меньше, так как еще сколько-то времени затратится также на загрузку данных в регистры.
Время на загрузку регистров вычитать из времени свечения не нужно. ПОка загружается следующий, светится предыдущий слой.
Цитата:
Дело в том, что в каждой строке помимо 64 бит, задающих состояние светодиодов в слое есть еще и адрес слоя, на котором должны загореться светодиоды, это еще 8 бит. И того в одной строке 72 бита. А строк в одном кадре 8 штук, 8*72=576.
Ну, вообще-то, адрес для 8 слоев - это всего 3 бита.
А поскольку идут они во вполне конкретном порядке, хранить этот адрес вообще не нужно.
Распишите поподробнее, сколько мс предполагается экспонировать каждый слой и с каким интервалом.
Алгоритм примерно следующий:
Пока не прошло 40 мс делай следующее {
for (int i=1; i<=8; i++){
1. включай регистры в режим записи
2. записывай i-тую строку
3. включай регистры в режим вывода
4. здесь возможно нужно будет сделать задержку пару мс для повышения средней яркости или вообще ничего не делать.}
}
Если в 4 пункте поставить задержку, то первый цикл можно будет заменить на for и сделать количество итераций в расчете на общую продолжительность цикла 40 мс.
andriano пишет:
Время на загрузку регистров вычитать из времени свечения не нужно. ПОка загружается следующий, светится предыдущий слой.
Я так понимаю, что как только мы переводим регистры в режим записи на его лапах предшествующая информация теряется и лапа отлючается и от земли и от 5v, но в этом я не уверен. Если так, то к сожалению вычитать нужно, а если нет, то Вы правы, и это хорошо.
andriano пишет:
Ну, вообще-то, адрес для 8 слоев - это всего 3 бита.
А поскольку идут они во вполне конкретном порядке, хранить этот адрес вообще не нужно.
1. Задержка вообще-то нужна. Нужно дать светодиодам какое-то время посветиться. Хотя, у меня время записи в 2 последователдьных регистра занимает примерно 0.34 мс. Если регистров 8, вероятно, каждый слой будет экспонировать более 1 мс - все время, пока мы производим манипуляции с резистром.
2. Для перевода регистра в высокоимпедансное состояние служит отдельный вход (OE), мы его не используем. Пока мы не защелкнули очередные данные, на выходах будут предыдущие.
Я бы рекомендовал измерить время прохода по всем слоям. Например, запусить функцию отображения (без delay()) эдак с 1000 раз и измерить время выполнения. Инача все оценки времени выполнения, заполнения, периода свечения и пр. - просто взяты с потолка. Сдвиговый регистр - не очень быстрая штука.
Сдвиговый регистр - штука быстрая, работает до 30 МГц, это ардуина медленная :) Для регистров ОБЯЗАТЕЛЬНО нужно использовать SPI шину. Иначе системные прерывания будут давать артефакты на изображении. Строил я как-то бегущую строку 16х256 ...
Сдвиговый регистр - штука быстрая, работает до 30 МГц, это ардуина медленная :) Для регистров ОБЯЗАТЕЛЬНО нужно использовать SPI шину. Иначе системные прерывания будут давать артефакты на изображении. Строил я как-то бегущую строку 16х256 ...
да эта. слои одинаковые и дублируются, смысл показывать все светодиоды нет. так часто делают при многократном повторении. но вот как формируется один слой непонятно.
озу не просто больше. она не сдохнет так быстро как eeprom, и по скорости работы во много раз выше
Последний девятый сдвиговый регистр определяет какой именно слой будет подключен к положительному выводу питания. Например в нем записано 01111111, тогда на базу первого транзистора, подастся 0 и он откроется ввиду того, что он pnp, а все остальные останутся закрытыми.
Предыдущие 8 регистров определяют какие из вертикалей будут сидеть на нуле, а какие на 1 (5v). Если на лапе регистра стоит 0, то ток пойдет через светодиод, так как на горизонтальной шине (слое, этаже) висит +5 V (если слой включен), если же на выводе регистра тоже 5v, то ток естесственно не пойдет, так как нет разности потенциаллов.
А геометрически в кубе подключение к выводам регистров следующее: допустим мы смотрим на куб сверху, тогда в этом виде есть матрица 8x8: 8 сток и 8 столбцов. 8 выводов превого регистра подключены к первой строке, 8 выводов второго ко второй и т.д. получается, что первый регистр имеет координату x=1, второй x=2 и т.д. А внутнри одной строки 1 пин регистра подключен первому столбцу (y=1), второй к y=2 и т.д. x и y можно переобозначить, если хочется.
я знаю как работает, сам собирал, говорю твою схему тяжело читать
А-а-а, ну это уж как получилось :)
Ну, можно и в оперативку загрузить строки из флешки. Кстати, а сколько бит влезет в оперативку arduino? Я так понимаю нас интересует EEPROM, там 512 байт, то есть 4096 бит. Ага пусть будет так:
1 кадр определяет свечение всех 512 светодиодов, и представляет 3-d изображение, сформированное разверткой по слоям.
...
Однако важно, чтобы EEPROM работала подобно сдвиговым регистрам не перезаписываясь полностью, а сдвигая информацию в хвост. С хвоста же и будем читать текущий кадр.
...тогда получится однофигственно, что с SD-карты читать напрямую, что через EEPROM. А с другой стороны у нас есть 1/24 секунды на запись нового кадра в EEPROM. Короче пока непонятно, слишком много тусовок информации с места на место получается. Может кто уже этим занимался?
Только-что заказал с алиэкспресса sd-шилд и sd-карту :)
EEPROM и RAM (она же ОЗУ, она же оперативка) - это разные виды памяти.
Для Ваших целей EEPROM вообще не нужна.
Если планы не слишком грандиозны, для хранения данных лучше всего использовать ту же flash, в которой хрянятся программы. И емкость этого вида памяти, кстати, максимальна. Если же этого недостаточно, можно посоветовать хранить данные на карте памяти, считывая оттуда в оперативку. Скажем, фрагментами по килобайту.
И еще, ни один из видов памяти нельзя напрямую использовать как стек или очередь (аналог сдвигового регистра), хотя такую структуру и можно организовать программно. ПРавда, не понимаю, зачем это может понадобиться.
Кстати, Вы говорите о имеющейся паузе в 1/24 секунды. Это значит, что яркостью светодиодов Вы никак не управляете?
Один кадр содержит 576 бит. Будем считать что мультик длится скажем 10 секунд, если делать 24 кадра в секунду, то какой-нибудь мультик танцующего человека, потребует 10*24*576=138240 бит=17,28 кБ. А это уже исчерпает все ресурсы, поэтому sd-карта или другой носитель информации необходим.
Вы правы, необязательно делать сдвиговые регистры из памяти ардуино.
Говоря о паузе 1/24 секунды (это кстати 40 мсек) я имел ввиду, что человеческому глазу достаточно частоты 24 Гц, чтобы ему казалось что все плавно и без скачков движется (хотя в кубике 8*8*8 этого эффетка все равно не будет). То есть каждый кадр висит на кубе 1/24 секунды, и пока у нас есть свободное время можно загружать следующие кадры. А яркостью можно управлять, если при развертке одного кадра по слоям некоторые светодиоды в слое зажигать чаще других. Но не знаю стоит ли этим заморачиваться, это сильно усложнит процесс вывода изображения на куб. В этом случае проще ввести в стоку информацию о яркости (яркости одного слоя) и делать развертку уже в самом слое, где время простоя будет зависеть от параметра яркости.
Ну и кроме того, сейчас мы вообще мало чем управляем :) Мы этот кубик только собрали и залили в него пару очень простых эффектов типа рандомного дождя и бегания светодиодов по кругу. Я вот просто думаю как теперь раскрыть потенциал этого кубика.
А также правильнее, наверное, и информацию о времени в течении которого висит один кадр записывать в том-же файле, тогда проще сделать динамику. Основная задача в разработке ПО на компе которая будет генерировать строки по нарисованным картинкам. Вообще, задача мне видится очень интересной!
fss4, вероятно, Вы ориентируетесь на время показа одного кадра в кино. Должен заметить, это далеко не единственный вариант и далеко не самый лучший. ПРактика показывает, что без motion blur этой частоты смены кадров для обеспечения плавности движения совершенно недостаточно. Это во-первых.
Во-вторых, Вы применяеие динамическ4ую индикацию, т.е. в течение 40 мс Вы по очереди показываете 8 слоев, т.е. на 1 слой приходится по 5 мс с интевалом 35 мс, а это уже весьма заметное мерцание. Т.е. изображение будет восприниматься как мерцающее на манер стробоскопа.
Чтобы мерцания не было заметно, период отогбражения сделует уменьшить по крайней мере до 16, а лучше до 12 мс.
Опираться нужно именно на время гашения, которое в Вашем случае составит 35 мс, тогда как в кино оно примерно 13 мс - там 2/3 времени кадр экспонируется и лишь 1/3 времени тратится на то, чтобы передвинуть пленнку.
Другими словами, еще на стадии проектирования неплохо бы ориентироваться на физиологию зрительного анализатора человека, а не пытаться использовать непонятно откуда взявшиеся цифры.
Еще, непонятно, почему у Вас в "изображении" 576 бит, когда, казадлсь бы, должгл быть 512. Откуда еще 64? Или у Вас куб 8*8*9?
Ну и по поводу эффектов. Как правило, эффекты используются циклические, т.е. одну и ту же последовательно "кадров" прокручивают по много раз. Сделать "кино" с уникальными от начала до конца кадрами - это задача несколько другой ресурсоемкости, и неочевидно, что она под силу Ардуине. По крайней мере, на 328 чипе.
...Вы ориентируетесь на время показа одного кадра в кино.
Да, я на это и ориентировался, вполне может быть, что зря. Делать эффекты размытия мне не хочется, это сильно усложнит процесс рисования кадров.
Во-вторых, Вы применяеие динамическ4ую индикацию, т.е. в течение 40 мс Вы по очереди показываете 8 слоев, т.е. на 1 слой приходится по 5 мс с интевалом 35 мс, а это уже весьма заметное мерцание. Т.е. изображение будет восприниматься как мерцающее на манер стробоскопа.
Чтобы мерцания не было заметно, период отогбражения сделует уменьшить по крайней мере до 16, а лучше до 12 мс.
Я предполагал без задержек последовательно выводить 8 слоев без искуственных задержек в течении 1/24 сек, тогда мерцаний недолжно быть. Какая у системы будет скорость непонятно, возможно придется либо ввести дополнительный delay(1), либо наоборот попытаться увеличить скорость, как это предлагал jeka_tm через SPI.
Опираться нужно именно на время гашения, которое в Вашем случае составит 35 мс, тогда как в кино оно примерно 13 мс - там 2/3 времени кадр экспонируется и лишь 1/3 времени тратится на то, чтобы передвинуть пленнку.
В нашем кубе каждый слой будет гореть не больше чем 1/8 от времени кадра, а по факту даже меньше, так как еще сколько-то времени затратится также на загрузку данных в регистры. Чтобы увеличить время экспонирования придется делать каждый слой независимым, а это затруднительно с точки зрения пайки и кол-ва регистров. В бегущих строках всего один слой, и поэтому можно себе позволить все время затратить на экпонирование, а в многослойной структуре слои друг другу будут мешать, так как будут зажигаться лишние пикселы, придется зажигать лишь один слой из восьми.
Еще, непонятно, почему у Вас в "изображении" 576 бит, когда, казадлсь бы, должгл быть 512. Откуда еще 64? Или у Вас куб 8*8*9?
Дело в том, что в каждой строке помимо 64 бит, задающих состояние светодиодов в слое есть еще и адрес слоя, на котором должны загореться светодиоды, это еще 8 бит. И того в одной строке 72 бита. А строк в одном кадре 8 штук, 8*72=576.
Ну и по поводу эффектов. Как правило, эффекты используются циклические, т.е. одну и ту же последовательно "кадров" прокручивают по много раз. Сделать "кино" с уникальными от начала до конца кадрами - это задача несколько другой ресурсоемкости, и неочевидно, что она под силу Ардуине. По крайней мере, на 328 чипе.
Но это гораздо интереснее. Думаю из ресурсов необходим только достаточный объем памяти и быстрое чтение из нее + загрузка в регистры. А вообще, говоря о мультике я предпологал сделать циклический мультик, делать большие мультики сложно просто с точки зрения рисования огромного количества кадров, а делать какой-то 3d-софт автоматизирующий процесс мне кажется черезчур сложной задачей.
Я подумываю над редактором, типа paint, где было бы удобно рисовать матрицу 8x8x8. Программа эта должна поддерживать копирование внутри подматриц 8x8 и между ними, также трансляцию и возможно поворот. Тогда процесс рисования кадров упростится. Естесственно, она должна уметь визуализировать нарисованное в виде похожем на кубик, экспортировать последовательность кадров и показывать мультик.
Но сначала, конечно, нужно убедиться что система с sd-картой будет адекватно работать.
Я предполагал без задержек последовательно выводить 8 слоев без искуственных задержек в течении 1/24 сек, тогда мерцаний недолжно быть. Какая у системы будет скорость непонятно, возможно придется либо ввести дополнительный delay(1), либо наоборот попытаться увеличить скорость, как это предлагал jeka_tm через SPI.
Это как?
Распишите поподробнее, сколько мс предполагается экспонировать каждый слой и с каким интервалом.
В нашем кубе каждый слой будет гореть не больше чем 1/8 от времени кадра, а по факту даже меньше, так как еще сколько-то времени затратится также на загрузку данных в регистры.
Время на загрузку регистров вычитать из времени свечения не нужно. ПОка загружается следующий, светится предыдущий слой.
Дело в том, что в каждой строке помимо 64 бит, задающих состояние светодиодов в слое есть еще и адрес слоя, на котором должны загореться светодиоды, это еще 8 бит. И того в одной строке 72 бита. А строк в одном кадре 8 штук, 8*72=576.
Ну, вообще-то, адрес для 8 слоев - это всего 3 бита.
А поскольку идут они во вполне конкретном порядке, хранить этот адрес вообще не нужно.
Распишите поподробнее, сколько мс предполагается экспонировать каждый слой и с каким интервалом.
Алгоритм примерно следующий:
Пока не прошло 40 мс делай следующее {
for (int i=1; i<=8; i++){
1. включай регистры в режим записи
2. записывай i-тую строку
3. включай регистры в режим вывода
4. здесь возможно нужно будет сделать задержку пару мс для повышения средней яркости или вообще ничего не делать.}
}
Если в 4 пункте поставить задержку, то первый цикл можно будет заменить на for и сделать количество итераций в расчете на общую продолжительность цикла 40 мс.
Время на загрузку регистров вычитать из времени свечения не нужно. ПОка загружается следующий, светится предыдущий слой.
Я так понимаю, что как только мы переводим регистры в режим записи на его лапах предшествующая информация теряется и лапа отлючается и от земли и от 5v, но в этом я не уверен. Если так, то к сожалению вычитать нужно, а если нет, то Вы правы, и это хорошо.
Ну, вообще-то, адрес для 8 слоев - это всего 3 бита.
А поскольку идут они во вполне конкретном порядке, хранить этот адрес вообще не нужно.
Это ценное замечание! Спасибо!
1. Задержка вообще-то нужна. Нужно дать светодиодам какое-то время посветиться. Хотя, у меня время записи в 2 последователдьных регистра занимает примерно 0.34 мс. Если регистров 8, вероятно, каждый слой будет экспонировать более 1 мс - все время, пока мы производим манипуляции с резистром.
2. Для перевода регистра в высокоимпедансное состояние служит отдельный вход (OE), мы его не используем. Пока мы не защелкнули очередные данные, на выходах будут предыдущие.
Я бы рекомендовал измерить время прохода по всем слоям. Например, запусить функцию отображения (без delay()) эдак с 1000 раз и измерить время выполнения. Инача все оценки времени выполнения, заполнения, периода свечения и пр. - просто взяты с потолка. Сдвиговый регистр - не очень быстрая штука.
Сдвиговый регистр - штука быстрая, работает до 30 МГц, это ардуина медленная :) Для регистров ОБЯЗАТЕЛЬНО нужно использовать SPI шину. Иначе системные прерывания будут давать артефакты на изображении. Строил я как-то бегущую строку 16х256 ...
Сдвиговый регистр - штука быстрая, работает до 30 МГц, это ардуина медленная :) Для регистров ОБЯЗАТЕЛЬНО нужно использовать SPI шину. Иначе системные прерывания будут давать артефакты на изображении. Строил я как-то бегущую строку 16х256 ...
пост 91, а то все вокруг, да около