Средства и методы разработки

На компрессию ссылка не по теме. По сути ASN.1 это такая форма "бинарного XML". Когда данные передаются не неким блобом с неизвестной структурой, а в этом же блобе закодированы правила по декодированию блоба на элементарные составляющие. Т.е. раскодировать всегда сможешь, а понять -- только если знаешь смысл конкретных полей (назначение их номеров), иначе можешь просто распечатать или игнорировать. По поводу 4kB ОЗУ и сразу уточняя ответ на вопрос LightElf -- см. приложенный файл (для успешной сборки make вызывать 4 раза -- мне лень исправлять). Там проект из двух программ (proto1 и proto2), которые используют как бы общий протокол. proto1 -- базовую версию протокола, proto2 -- расширенную. Каждая из программ умеет генерировать DER в hex-виде при запуске с аргументом "send" или разбирать BER из hex при запуске с аргументом "recv". Программы совместимы между собой. Т.е. программа proto2 полностью понимает вывод программы proto1, а программа proto1 понимает известные ей поля из вывода программы proto2 (часть новых полей не понимает). Свой вывод обе программы, разумеется, принимают. Ответ на вопрос как это достигается заключается в т.н. "extension marker" (см. parse1.asn, а так же ссылку: http://lionet.info …ility-removing-fields/). В файлах *.hex содержится вывод обоих программ в текстовом виде, в hex (можно использовать в веб-декодерах, ссылки на которых я давал в предыдущем сообщении). Расход памяти следующий:

sysop@pc:asn1$ ltrace ./proto2 recv < proto2.hex  2>&1 |grep alloc
calloc(1, 64)                                    = 0xb85ff170
realloc(0, 16)                                   = 0xb85ff1c0
calloc(1, 4)                                     = 0xb85ff1e0
calloc(1, 28)                                    = 0xb85ff1f0
calloc(1, 48)                                    = 0xb85ff210
realloc(0, 16)                                   = 0xb85ff250

sysop@pc:asn1$ ltrace ./proto2 recv < proto1.hex  2>&1 |grep alloc
calloc(1, 64)                                    = 0xb881f170
realloc(0, 16)                                   = 0xb881f1c0

sysop@pc:asn1$ ltrace ./proto1 recv < proto1.hex  2>&1 |grep alloc
calloc(1, 52)                                    = 0xb9106170
realloc(0, 16)                                   = 0xb91061b0

sysop@pc:asn1$ ltrace ./proto1 send 2>&1 > /dev/null |grep alloc
malloc(12)                                       = 0xb94f9160
malloc(10)                                       = 0xb94f9170
malloc(10)                                       = 0xb94f9170

sysop@pc:asn1$ ltrace ./proto2 send 2>&1 > /dev/null |grep alloc
malloc(12)                                       = 0xb808c160
malloc(4)                                        = 0xb808c170
malloc(28)                                       = 0xb808c180
malloc(48)                                       = 0xb808c1a0
malloc(8)                                        = 0xb808c1e0
malloc(10)                                       = 0xb808c1f0
malloc(10)                                       = 0xb808c1f0
malloc(10)                                       = 0xb808c1f0
malloc(10)                                       = 0xb808c1f0
malloc(10)                                       = 0xb808c1f0

Я думаю, говорит о какой-то существенной нагрузке для MCU с 4 кБайт памяти нельзя. У меня в таком МК был и вовсю использовался аллокатор и без него проект просто невозможно было бы довести до рабочего состояния... Тем более после окончания цикла работы (кодирование/декодирование) вся память высвобождается. Это лишь временные аллокации. При отсутствии многозадачности они на ту же фрагментацию вообще не влияют. А вот с кодом проблемы: после всех ухищрений оно на ровном месте ест 28 кБайт памяти кода (x86), порядка 4 кБайт констант, и больше килобайта ОЗУ (статически). Большая часть проблем из-за запутанности кода (многое не используется, но не выкинуть из компиляции), и из-за того, что автор забил на const местами и хранит по сути константные структуры в ОЗУ (отдельные элементы там модифицируются что ли, но подход совершенно неразумный). Выправлять смысла может нет, есть и другие библиотеки для работы с ASN.1 Действительно, в существующем виде для pic18 точно не подойдёт. Впрочем из-за 8-битности наверное тоже (наверняка во многих местах код полагается на 32-битный int). Но для большого ARM -- вполне сгодится. Про eCall не понял. Проблемы совместимости старый->новый в принципе нет. Если заранее не предусмотрели (нет "..." в описателе), то можно не предусмотреть совместимость новый->старый. В общем техническая возможность есть, а при наличии кривых рук всё возможно. 4) Сжатие совершенно ортогональная задача. Она может делаться на данных до упаковки в BER, так и на потоке после упаковки. И совершенно разные подходы в этих случаях (специфический пакер, или обощённый работающий с потоком байт). 5) Ну можешь написать парсер руками. Это не так уж и сложно, а генератор вообще тривиально. Только нужно учитывать всякие фокусы, типа возможной перестановки полей местами и т.п. Многие кто написали парсеры для работы с модемами этим не запаривались и могут ещё нарваться. А с точки зрения ASN.1 всё будет чётко -- не прикопаешься. 6) Можно подумать, самодельный протокол чем-то лучше. Там комитеты годами решали, выбирали, принимали. В сотнях мест используется и все кривые углы обтёсаны. А ты тут бах, такой умный, за две недели свой супер-протокол сделал. Так бывает, как сам думаешь? Для какого-то частного случая, где 99% из ASN.1 не нужно -- бывает. Иначе нет. Но не дай бог в этом частном случае что-то где-то подвинуть надо и вполне может статься, что ASN будет много лучше огромной горы самодельных костылей и подпорок.