Уж коль дозволено иметь собственную флудильню, заведу и я себе такую. А то частенько возникают всякие глупые вопросы и идеи, не заслуживающие собственного топика.
Добавлено спустя 6 минут 58 секунд: Кому-нибудь встречалось описание протокола GSM мультиплексора (07.10 multiplexer protocol), написанное нормальным языком, чтоб понять можно было? Читаю стандарт и сименсовский users guide, но что-то общая картинка не складывается
Ну просто звонить и смс отправлять/принимать я научился. Теперь хочется заюзать мультиплексор. Теоретически вроде разобрался, буду пробовать использовать.
Вкратце, что такое GSM мультиплексор и зачем он нужен. Модуль GSM обычно выполняется в виде отдельного устройства, которое управляется через асинхронный последовательный порт. Мультиплексор позволяет организовать на одном физическом канале несколько виртуальных портов. Когда модем находится в нормальном режиме приема AT-команд, специальной командой его можно перевести в режим мультиплексора. В мультиплексированном режиме, данные передаются пакетами, в которых помимо данных содержится служебная информация, в частности номер виртуального канала. Управление мультиплексором осуществляется через нулевой канал. Остальные каналы, число которых зависит от реализации, используются для передачи AT-команд и данных. В частности, в MC35 3 канала (не считая управляющего), в SIM300 - 4.
Зачем все это нужно? модем может одновременно осуществлять прием/передачу данных по GPRS, отправлять SMS и звонить, но при передаче команд и потока данных через один порт нужно переключаться между этими задачами. Например, когда идет передача через GPRS, чтобы прочитать или отправить SMS, или ответить на входящий звонок, необходимо переключиться из режима передачи данных в режим команд, что занимает не менее секунды. С использованием мультиплексора, передачу данных можно вести через один канал, и не прерывая ее, отправить десяток сообщений через другой, параллельно осуществляя голосовые вызовы через третий.
Есть МК с АЦП. Есть внешний вход. Надо организовать схему, позволяющую измерять либо напряжение на внешнем входе до 15 вольт, либо сопротивление между внешним входом и землей от 0 до 10 кОм, с разрешением 100 Ом (режим сопротивление/напряжение переключать программно). Зависимость между сопротивлением и значением на выходе АЦП надо линейную, то же само для напряжения. Можно задействовать дополнительно один выход МК. Как это сделать с минимумом внешних компонентов?
Добавлено спустя 4 минуты 57 секунд: Пропеллер разогнанный до 96МГц, ЖКИ от сименса. Кадры размером 88x66 пикселов, до 25 fps. Кадр полностью считывается в память, потом выплевывается на экран. Если распараллелить, то можно 176x132 выводить до 10 fps. ВИдео разумеется на карте памяти несжатое, просто последовательность кадров, каждый из которых просто выводится в ЖКИ. SPI на частоте 24 МГц
Делаю проигрывание видео с SD-карты на ЖКИ от сименса (см. пост выше), на пропеллере. Just for fun Если все получится - будет видеобудильник Получилось сделать 20 FPS , 16-битный цвет. Звук - 16 битный PCM, 16 кГц.
Подумалось - а получится ли сделать то же самое на контроллере попроще, например atmega? Попробую прикинуть...
SPI интерфейс у нас только один, поэтому надо читать кусок кадра в буфер и затем выплевывать его на экран. Программный SPI совместно с аппаратным и два буфера думаю можно не рассматривать - получится всяко медленнее, кроме того придется задействовать прерывания - возникнут проблемы со звуком. Для вывода одного кадра надо считать с карты 176*132*2 = 46464 байт, и выплюнуть их на экран. Цикл записи на экран будет примерно такой:
В лучшем случае 23 такта на байт (16 - на передачу на максимальной скорости, 7 - оверхед цикла). Пусть тактовая частота 20 МГц. Тогда 46464 байта будет выведено за 53 мс. Если применить реализацию файловой системы от Elm Chan, то судя по его бенчмаркам, максимально можно получить чтение 740 КБ/сек при буфере в 2048 байт, то есть 62 мс на кадр. Итого 62+53=115 мс на кадр, или чуть более 8 кадров в секунду, реально меньше, так как кроме вывода на экран собственно видео надо еще рисовать текущее время. Делать это надо в памяти, до вывода считанного куска кадра на экран, чтобы не было мерцания. В буфер 2048 байт поместится 11 строк кадра. Цифры надо выводить большие (я использовал шрифт 16x32), то есть придется прорисовывать текст кусками - сначала верхнюю часть, потом среднюю, затем нижнюю. И чтобы смотрелось красиво, надо делать не черные цифры на фоне белого прямоугольника, а рисовать цифры одним цветом, а вокруг ободок другого, контрастного цвета. Кроме того, надо еще выводить звук, делать это придется в прерывании, и надо его еще прочитать с карты. В итоге думаю получится максимум (оптимистично) 5-6 FPS. Маловато будет. Да и звук будет скорее всего 8-битный.
Вот такие вот дела Пропеллер рулез
Ежели взять какой-нибудь ARM, то наверно получиться достичь таких же параметров что и с пропеллером. Кто в армах шарит - можете прикинуть? Только не надо всякие ARM9 на 400 МГц рассматривать - с ними все очевидно
хмега я думаю потянет нормально, думалось попробовать на экран от сименса вывод, но чот руки не доходят совсем не до чего... беготни больше блин чем нормальных занятий...