С такими объемами кодов как у нас и с сегодняшней стоимостью гпрс-интернет трафика - сжатие наверное будет лишним - разве что как метод дополнительного кодирования прошивки

Да с FTP никак не возьмешь... Можно и с mail-сервера забирать по pop3 но фактически это будет одно и тоже...

Как другой альтернативный вариант смены ПО можно было бы использовать CSD, тогда можно было бы реализовать программирование напрямую без промежуточной памяти, но на Украине большинство операторов его не поддерживают...



у 161 2 буферные страницы - можно еще и поочередно писать ( как обычно и делают)...

Скорее я имел ввиду то что с порту сим300 может литься и служебная информация, а при таком объеме различить ее не будет возможности...

По GPRS чем меньше размер файла тем больше вероятность его скачать.
Речь не о цене трафика, а вообще о вероятности доставки. Условия upload-а резко отличаются от download-а у провайдеров.
Часто приходилось видеть как после 100 кБ GSM сеть резко тормозила передачу файлов. Если на компе легко берут и рестартуют, то в embedded дивайсе это выливается в долгий зависон.
Еще хуже ситуация когда upload надо делать сразу на сотне, а то нескольких сотнях дивайсов. Тут лишний десяток килобайт может стать критическим.

Ну а FTP и Mail отличаются принципиально количеством логических каналов связи при перекачке. Это может оказаться важным в некоторых случаях.

Ну а патчи для программы можно и SMS-ами посылать. Вполне хороший и надежный способ.

я имел ввиду HTTP и mail

Здесь тоже не так просто. WEB сервера умеют поддерживать сжатие контента по gzip. Интересная фича, если есть ресурсы памяти на этот алгоритм.

Если Ваш клиент не будет передавать HTTP заголовок типа Content-Encoding: x-gzip, то Вам эта проблема не грозит. Сервер не будет сжимать передаваемое содержимое.
Ну и трафик конечно будет побольше

Бинарные если не зашифрованные. Зашифрованная программа при архивировании только увеличивается в размерах.

Использовать at45 - идея хорошая. Просто предусмотрите 2 банка для прошивки (текущая рабочая и обновляемая). При сбое в одном из банков программу можно будет всегда восстановить из другого.
По поводу метода перепрошивки. У нас было реализовано 2 способа:
1. Сервер даёт команду устройству на загрузку блока данных размером со страницу памяти at45. Устройство принимает её, проверяем crc посылки, сохраняет и отправляет подтверждение. После приёма всех страниц прошивки даётся команда на перепрошивку. Вариант довольно сложный т.к. требует написание сервера.
2. Устройство само скачивает прошивку с сервера с помощью http-запросов. Метод GET позволяет скачивать не только весь файл, а и выбранный диапазон байт (0-1023, 1024-2047 и т.д). Плюс метода в том что устройство само контролирует процесс загрузки, перезапрос выбранных страниц если не получено обновление, реконнект к серверу. Значительным плюсом является то что не нужно писать специальный сервер для обновления и все HTTP-сервера с которых я пытался скачивать прошивку поддерживали Partial Get. Минус - данные пришлось делать ascii-кодированными (хотя сейчас вижу вариант решения без кодирования) и оверхед при каждом запросе порядка 300 байт (шапка http-запроса).


В целом второй вариант показался более простым и сейчас успешно реализован. Осталось немного подрихтовать его чтобы обойтись без ascii-кодирования. Обновление ПО размером 64к (~150к gprs-траффика после доработки может уменьшится наполовину) занимает 2-3 минуты.

Или я торможу или чего-то не понимаю. А почему "пришлось ASCII-кодированными" ? Чем бинарник хуже ? Ведь вроде как нет совершенно никаких сложностей получить по GET бинарник ?

Проблема была в ключевых словах возвращаемых от модема (NO CARRIER и ERROR) которые могли попасться в передаваемой прошивке. Основня программа могла принять их за сбои в работе tcp/ip стека модема и решить что связь прервана. Не хотелось вводить дотошную обработку текста получаемого от http-запроса от того и возникла такая проблема. Сейчас всё уже исправил - зашифровал прошивку, получил бессмысленный набор байт в котором подобные ключевые слова не встречаются и не мешают работе основной программы.