Бутлоадер в стиле "Спектрума"

[MasterMushi]

У меня появилась идея сварганить бутлоадер который бы зашивал прошиву не по UART или USB а по примерно тому же формату данных, который имеют старые компы. Тоесть прошиваться из аудио файла, передавая данные с выхода наушников MP3 плеера или даже кассетного магнитофона.

Теория по магнитофонке лежит тут
http://zxspec.ru/?rc=4&n=5&ar=0

Единицы и нули кодируются длительностью цикла.
Классическая несущая для данной процедуры составляет порядка 900бод. А если использовать MР3 с шириной потока в 360КБС то можно приподнять до 1500-1800 бод. чем больше у нас количество ключевых кадров аудио потока тем меньше потерь на генерацию промежутков что в результате дает бОльшую теоретическую скорость. Хотя, всеравно мы ограничены тем, что воспроизведение идет на 44 килогерцах частоты семплирования. И при минимальной длительности импульса потери во время кодирования возрастают до полной недостоверности выхода.

На вопрос который возникнет у многих "А зачем это вообще нужно?". Отвечу: Велосипедисту, обывателю по форме "шорты и футболка" проще взять с собой MP3 плеер или телефон чем тащить ноутбук, нетбук, системник, специально сделанное устройство которым с другом не поделишся.
Памяти в портативных плеерах нонче хоть отбавляй. 5-6 мегабайт ради 4-16 килобайтовой прошивы не жалко )))))

Есть у кого нибудь наработки на такой бутлоадер?

Я планировал сделать все в таком формате
- Пилот тон где длительность цикла 2мс. Давать пилот тон в течении 3-4 секунд. За которые устройство надо включить и бутлоадер должен отработать захват пилот тона
- небольшой пакет переходов с 1 на 0 который будет формировать контроллеру понятие о длительности 0 и длительности 1 (фактически установим тут скорость потока)
к примеру подаем П_ 600 мкс + 600 мкс а затем П_ 800мкс и 800мкс
И контроллер посчитав время соображает что единица к нас имеет длительность 550-650мкс а ноль соответственно 700-900мкс
- Сведения о размере файла в байтах
- Собственно поток данных по 16 байт + контрольная сумма
- Снова пилот тон

[ut1wpr]

Классическая несущая для данной процедуры составляет порядка 900бод. А если использовать MР3 с шириной потока в 360КБС то можно приподнять до 1500-1800 бод. чем больше у нас количество ключевых кадров аудио потока тем меньше потерь на генерацию промежутков что в результате дает бОльшую теоретическую скорость. Хотя, всеравно мы ограничены тем, что воспроизведение идет на 44 килогерцах частоты семплирования. И при минимальной длительности импульса потери во время кодирования возрастают до полной недостоверности выхода.

Ну совсем ничего не понял. На 900 герцах передавать 44 килогерца? Котельников отдыхает. Несущая в бодах? Какой вид модуляции? Как защищать? Не. Не дорос я...

[alexgap]

У меня появилась идея сварганить бутлоадер

Прекрасное начинание. Можно взять реализацию Спектрума. Преимущество: есть готовые звуковые файлы на которых можно потренироваться. Ну и конечно же, это уважение к истории.

[st_1]

Прекрасное начинание.

И сразу окончание.
Чего куда грузить то собираемся? Может вспомним сколько у Спектрума было ОЗУ и сколько ПЗУ?
Такс, иголочку нашёл, молоточек есть... как там люди в каменном веке Мегу пробивали, пардон, прошивали? Дырочка это ноль или единичка? Наверное всё таки единица, одна единица убитого чипа! Или ноль? Все чипы пробиты, ничего не осталось? Значит ноль!

[niXto]

По-моему проще к мелкому контроллеру прикрутить что-то типа AT45DB, заливать в него прошивки с идентификатором, а целевое устройство своим бутлодырем будет само вытаскивать через СОМ прошивку со своим идентификатором... И скорости можно поднять хоть до мегабита (не напоминайте мне про 900 бод)

[realid]

Можно прикрутить микроСД/СД, PetitFatFS и обновлять прошивку из файла на этой СД.

[alexgap]

И сразу окончание.
Чего куда грузить то собираемся?

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

Все будет работать. Флeш записывать блочно из бутлоадера - не проблема.
Зашел в подвал, включил бумбокс - прошивка котла обновилась.

Конечно, нужно закрывать прошивку паролем/подписью, чтобы не обновилась чем нибудь неправильным.

Красивый и дешевый способ

[MasterMushi]

ut1wpr,
Смотри - у нас аудио файл имеет частоту семплирования. Как правило это 44 килогерца. Нам надо на эту "несущую" в 44 килогерца наложить 900 бод поток закодированный PWM так, чтобы при сжатии МП3 мы не потеряли данные. А данные теряться будут. Потому что сам смысл MP3 в обрезании оригинального потока до "сходных" пакетов которые затем декодер расколошматит в звук.

На самом то деле у нас нифига не несущая, а просто частота с которой ADC и DAC отмеряют входящий сигнал. Следовательно для точного определения 1 и 0 мы ограничены в несжатом файле примерно шестнадцатью "позициями". Что дает предел "идеальной" записи-воспроизведения системы 2756 бод. 16 позиций также цифра не с проста! При передаче прямоугольного импульса через конденсатор мы получаем "пилу". Если сократить количество отсчетов до 8ми, эта пила будет гораздо короче. Устройство может не захватить фронт или спад в нужный временной промежуток (тайм слот), даст ложное срабатывание или не сработает вообще.
Так как мы будем сжимать в МП3, то на предельной скорости шесть-семь единиц или нулей данных подряд будут ужаты до четырех. И при воспроизведении выйдут как 4 единицы. Формат сжатия тут нам подсовывает заподлянку. Чтобы этого избежать надо еще уменьшить скорость - до 900 бод.
Хотя эту цифру (900) задали стандартом магнитной "цифровой" записи во времена когда MP3 и в проекте не было, она справедлива и теперь. А все потому что на магнитофонной ленте подмагничивание идет на тех же 44-60 килогерцах. и цифра в 900 бод рассчитывалась как раз для того, чтобы запись после стирания-подмагничивания была наиболее четкой.
В магнитофоне из за размагничивания и смещения магнитных доменов мы теряем достоверность информации а в МП3 из за того что чем меньше по времени и более повторяющийся по периодам сигнал, тем сильнее он подрезается при переходе от кадра к кадру во время декодирования.

[realid]

Конечно, нужно закрывать прошивку паролем/подписью, чтобы не обновилась чем нибудь неправильным.

Помимо этого CRC для блоков данных.
Этот способ плох из-за того что не будет обратной связи с передающей блоки данных стороной.
Как вы будете реализовывать ОС?
Бутлодер должен быть БЕЗОПАСНЫМ.

[ТКН]

Бутлодер должен быть БЕЗОПАСНЫМ.

А ностальгия ?..