From a6856d757a7960e9c50cb2cdce3e31ace9671541 Mon Sep 17 00:00:00 2001 From: gdisirio Date: Sun, 3 Oct 2010 13:20:13 +0000 Subject: Removed redundant articles in the generated documentation. git-svn-id: svn://svn.code.sf.net/p/chibios/svn/trunk@2232 35acf78f-673a-0410-8e92-d51de3d6d3f4 --- docs/src/memory.dox | 138 ---------------------------------------------------- 1 file changed, 138 deletions(-) delete mode 100644 docs/src/memory.dox (limited to 'docs/src/memory.dox') diff --git a/docs/src/memory.dox b/docs/src/memory.dox deleted file mode 100644 index f41dff32f..000000000 --- a/docs/src/memory.dox +++ /dev/null @@ -1,138 +0,0 @@ -/* - ChibiOS/RT - Copyright (C) 2006,2007,2008,2009,2010 Giovanni Di Sirio. - - This file is part of ChibiOS/RT. - - ChibiOS/RT is free software; you can redistribute it and/or modify - it under the terms of the GNU General Public License as published by - the Free Software Foundation; either version 3 of the License, or - (at your option) any later version. - - ChibiOS/RT is distributed in the hope that it will be useful, - but WITHOUT ANY WARRANTY; without even the implied warranty of - MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - GNU General Public License for more details. - - You should have received a copy of the GNU General Public License - along with this program. If not, see . -*/ - -/** - * @page article_manage_memory How to manage memory - * ChibiOS/RT is a static kernel so you don't need to manage memory at all - * if your application doesn't really require it. This doesn't mean that - * the OS is unable to manage memory but just that memory management is an - * optional part of the whole.
- * The OS offers three distinct ways to manage memory, each one with its - * weaknesses and strengths: - * - Core Memory Manager. See @ref memcore. - * - Heap Allocator. See @ref heaps. - * - Memory Pools. See @ref pools. - * . - * The three mechanisms are able to coexist and are well integrated, as example - * the heap allocator uses the core memory manager in order to get more - * memory blocks, memory pools can optionally do the same thing. - * - *

The three subsystems

- * This is a small comparison table regarding the three subsystems, C-runtime - * and static objects are thrown in there for comparison:

- * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - *
- * Subsystem - * - * Free capable - * - * Constant time - * - * Safe - * - * From IRQ - * - * Notes - *
- * Static Objects - * N/AN/AYESYES - * Preferred solution for safety applications. - *
- * Core Memory Manager - * NOYESYESYES - * Fast and safe but unable to free allocated memory. - *
- * Heap Allocator - * YESNONONO - * Unsafe because fragmentation and not constant time, cannot be used - * from IRQ handlers. - *
- * Memory Pools - * YESYESYESYES - * Fast and safe but it can handle fixed size objects only, you may have - * multiple memory pools however. - *
- * C-Runtime - * YESNONONO - * Unsafe because fragmentation, not constant time, cannot be used - * from IRQ handlers and not thread safe. The C runtime must also be - * modified in order to work with the other allocators. - *
- *
- * When designing a system it is recommended to proceed as follow: - * -# Use static objects and initializers whenever possible. - * -# Where dynamic allocation is required without having to free the allocated - * memory then use the Core Memory Manager allocation APIs. - * -# Where dynamic allocation is required evaluate if one or more memory - * pools can be used. - * -# If all the above points do not satisfy your requirements then use the - * heap allocator. - * -# Consider the C-runtime allocator only for legacy code. - * . - */ - -- cgit v1.2.3