Is it possible to Develop ASN.1 protocol in Embedded c for 32-bit microcontroller (without OS) ?
I am using ARM micro(32-bit) and cubesuite compiler.
Asked
Active
Viewed 771 times
-2
-
may i know the reason for down vote – maasi Jun 19 '15 at 10:48
-
This question is unclear. To little information, not clear what you are asking. Do you have any **specific** probpem about code you have written? Do some research yourself. No offense, but: if you would know enough about both subjects, you should be able to answer the question yourself. Note that [`ASN.1`](https://en.wikipedia.org/wiki/Abstract_Syntax_Notation_One) is a description language, not a protocol. – too honest for this site Jun 19 '15 at 11:32
-
Note there is no "embedded C". There is only [ISO/IEC 9899:xxxx](http://port70.net/~nsz/c/c11/n1570.html) current version:2011, aka C11. – too honest for this site Jun 19 '15 at 11:43
-
@Olaf, in essence maasi is asking whether any of the available ASN.1 tool sets (OSS Nokalva, Objective Systems, etc) have runtime libraries that do not assume there to be a POSIX or Win32 operating system underneath. Such an OS would provide routines like `read()`, `write()`, and more importantly `malloc()`, and generally they're not available (as such) on an embedded platform. – bazza Aug 30 '15 at 06:16
-
@bazza: Late comment. However, I don't think a FS is always required,but I agree they might use `malloc` & friends. But as OP uses a 32bit MCU, it is not _that_ improbable/atypical to be available/implementable as on smaller MCUs. This does not need a (full-grown) OS (wheras on such platforms a small RTOS is generally advantageous). However, he should have searched himself. As given the question is too broad, unclear and/or asking for off-site resources. And apparently it has been abandoned anyway. – too honest for this site Aug 30 '15 at 11:37
2 Answers
2
Maasi,
It's certainly possible: ASN.1 standardizes both protocol notation syntax (X.680-X.683) and encodings (X.690-X.696). Specifications are freely available at ITU-T, although this list appears to be missing the Octet Encoding Rules (X.696).
Is it practical? This is a little more questionable. If you're writing your own protocol, you have the freedom to design something that can be implemented in hardware or firmware without the use of external tools. On the other hand, supporting current standards (e.g., LTE) is harder: the protocols are quite complex.
If you have this design freedom, you may find that non-ASN.1 options could be easier to implement. One of the main virtues of ASN.1 is that tool support exists for generating APIs. The encoding rules are otherwise complex enough that implementing by hand is likely to be quite error prone.
Ethan
- 252
- 2
- 8
-
I've often thought that any kind of complex data types are going to be a challenge on an embedded platform that doesn't have dynamic memory allocation. It doesn't matter if it's in ASN.1, JSON or whatever, things get very difficult without a implementation of `malloc()` / `free()` unless one starts restricting oneself to a subset of the grammar (e.g. no variable length arrays, no extensibility, etc). – bazza Aug 30 '15 at 06:22
-
@bazza: Sorry, but this is not true. If it is only for memory allocation, there are other ways to maintain extensible data structures, some of them are even useful on systems providing `malloc` & friends. The serialization itself is not that much different. Things might be different if you are only used to use external tools for this, but that is a matter of comfort. – too honest for this site Aug 30 '15 at 11:43
-
@Olaf, yes, I was indeed referring to the difficulties with use of external tools. One ASN.1 tool set I used allows one to provide one's own implementation of malloc / free, and my point is that if one is having to do that then it's a whole lot more work. Having an OS makes it a whole lot easier! – bazza Aug 30 '15 at 22:12
-
@bazza: Not being bound to an OS and left only with the bugs you created yourself is more fun and (often) less frustrating:-). And - bad enough - very costly libraries/tools do not guarantee less errors, I assure you. There are many functions an experienced developer can implement faster than getting such a lib running and integrated into your system architecture (or adopt your architecture to what the designers of that lib **think** is a good idea ...). – too honest for this site Aug 31 '15 at 00:15
-
@Olaf, all true indeed! It's a balance between how complex a system has to be, the time taken for a bare metal software development, the cost and risk. If the system has a lot of things to do there's nothing like being able to use libraries one already trusts. And yes I've found bugs in commercially available ASN.1 tools and libraries, but I've been lucky that the projects I've worked on have been bug enough to be able to fund the support costs. I wish Google had done some good open source ASN1 tools instead of Google Protocol Buffers... – bazza Aug 31 '15 at 11:03
