![]() We have used a 350kB application (debug build) of embOS with our TCP/IP stack emNet and with an emSSL test programs, with multiple cipher suites, public key algorithms, and so on, so a representative application. Here it is…not yet ready for release, the first results are very encouraging. Optionally eliminating functions that have identical bodies at the instruction level.Different ways of sorting input fragments (functions and data): alphabetically, by call distance to improve locality, by alignment to improve packing, by size - these are but a few.Tail optimization for code that calls another function as last operation, so that the tail can be merged with the called function.Compatibility options for other popular linkers such as IAR and ARM.Compression options to minimize flash-copy space for initialzed data and code in RAM.Option to compute how much code / data is pulled in because of one or multiple particular symbols - important to measure code size for middleware options, such as”How much Flash (RO) memory does a particular cipher (for emSSL) need?”.Modular linkage: only link in what is required, automatically.High linkage speed, even for large applications.The design goals of the SEGGER linker are easily stated: The linker’s design brief is simply to avoid the disadvantages of the GNU linker, making linking simple, and solving linking problems for the embedded developer. Yes, we would write the SEGGER Linker, from scratch and without any legacy code or legacy thinking. Because memory allocation, function and data sizes, and what goes into a microcontroller is highly important, not having an accurate, easy-to-read map file is unforgivable. The map file is almost incomprehensible.And the GNU linker cannot compress the initialization image to reduce flash use or automatically compute a CRC to support image integrity checks. ![]() In embedded systems the user is responsible for copying the initialized image from flash to RAM and zeroing “bss” sections before entering main(). It does not automatically handle initialization of read-write sections, delegating that to the loader in Unix systems.When linking large megabyte-order firmware images, with even larger multi-megabyte debug data, time can seep away when linking over and over again. Linkage speed is acceptable, but not fast.With multiple RAM regions, it cannot automatically split data over those RAM regions, requiring the user to choose the placement of data manually across the regions.calibration data, flash protection bytes, fixed-address jump tables for ROM or bootloader APIs and so on. It’s not flexible enough to deal with typical “keep-out” areas common to embedded firmware envonments, e.g.The GNU linker has a number of deficiencies in this alien world: But, to enhance performance, RAM is usually divided into distinct regions so they can be accessed simultaneously by the CPU and peripherals, or even other CPUs in the same device. Typically they have separate memory areas for flash and RAM. Small embedded systems – usually microcontrollers with built-in memories -are complex. This is as far from a low-end embedded system as you could imagine. The GNU linker has evolved from the Unix world, where megabytes of linear virtual addressing is commonplace, disk space is unbounded, and processing power is plentiful. When comparing Embedded Studio to other commercial products, we realized that one weak point is the GNU linker. Optimized to the bone, it leaves not only the GNU runtime, but also its commercial counterparts, in the dust. It is a great piece of software that can be used free of charge for non-commercial purposes! Ready for development out of the box, with both GCC and Clang/LLVM compilers.Įmbedded Studio comes with our own runtime library, which I believe is second to none. I think we have come a long way and have great products pretty much in every area.įor an IDE, we have completely switched to Embedded Studio. Using our own products in house helps us to check usability and improve them. And the other way round, utilizing the same hardware products, most of all the J-Link, to develop, test and constantly improve our middleware. That includes using our middleware, such as embOS, emNet, emUSB, emFile, web and FTP Servers and so on, as part of the firmware of our J-Link, J-Trace and Flasher products. At SEGGER, we pretty much use our own tools and products to develop our products.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |