SHARED MEMORY ARCHITECTURE

• US 20110307669A1
• Filed: 06/09/2010
• Published: 12/15/2011
• Est. Priority Date: 06/09/2010
• Status: Active Grant

• Current Assignee: Lear Corporation
• Original Assignee: Lear Corporation
• Inventors: Lincer, Stanislav, Alari, David Gamez, Fàbregas, Antoni Ferré, Aymami, Jordi Moreno
• Granted Patent: US 8,495,601 B2
• Time in Patent Office: Days
• US Class Current: 711/147
• CPC Class Codes: B60L 2240/545 Temperature
• CPC Class Codes: B60L 2240/549 Current
• CPC Class Codes: B60L 3/12 Recording operating variables ; Monitoring of operating variables
• CPC Class Codes: G01R 31/382 Arrangements for monitoring battery or accumulator variables, e.g. SoC
• CPC Class Codes: G06F 12/00 Accessing, addressing or allocating within memory systems or architectures digital input from, or digital output to record carriers, e.g. to disk storage units, G06F3/06
• CPC Class Codes: H01M 10/48 Accumulators combined with arrangements for measuring, testing or indicating the condition of cells, e.g. the level or density of the electrolyte constructional details of current conducting connections for detecting conditions inside cells or batteries, e.g. details of voltage sensing terminals, H01M50/569
• CPC Class Codes: Y02E 60/10 Energy storage using batteries
• CPC Class Codes: Y02T 10/70 Energy storage systems for electromobility, e.g. batteries

Abstract

A shared memory architecture is disclosed to support operations associated with executing shared functions from a shared memory space in such a manner that separate pieces of software can execute the shared functions.

Claims

1. For use with a battery monitoring system (BMS) having an application operable to measure current flow to a vehicle battery and a launcher operable to enable drivers utilized by the application, the BMS having a non-volatile memory and a volatile memory for storing code, the method comprising:

storing application code for application functions capable of being called by the application to an application memory block of the non-volatile memory;

storing launcher code for launcher functions capable of being called by the launcher to a launcher memory block of the non-volatile memory;

storing shared code for an n number of shared functions capable of being called by the launcher and application to a shared memory block having an n number of locations of the non-volatile memory;

re-compiling the shared code where at least the same n number of shared functions are still available one or more times; and

storing one of an n number of shared function pointers within the shared memory block for each one of then number of shared functions, wherein each one of the n number of locations within the shared memory block remains dedicated to storing the same one of the n number of shared function pointers following each operation of re-compiling the shared code.

2. The method of claim 1 further comprising re-compiling the shared memory code such that (i) an amount of memory required to store the shared code for at least one of the shared functions increases in size and (ii) each of the n number of shared function pointers remain in the same one of the n number of locations after the re-compiling.

3. The method of claim 2 further comprising dedicating the same amount of memory within the shared memory block to store the n number of shared function pointers before and after the re-compiling.

4. The method of claim 1 further comprising:

storing launcher pointers to launcher callback functions in a shared callback function memory block of the volatile memory while the launcher is operational, the launcher pointers pointing to at least one of an n number of launcher callback functions to be executed for each one of the n number of shared functions; and

storing application pointers to application callback functions in the shared callback function memory block of the volatile memory while the application is operational, the application pointers pointing to at least one of an n number of application callback functions to be executed for each one of the n number of shared functions.

5. The method of claim 4 further comprising assigning each one of the n number of shared functions a unique reference label and assigning each of the shared function pointers, the launcher pointers, and the application pointers the unique reference label assigned to the shared function.

6. The method of claim 5 further comprising arranging the storing of the launcher pointers and the application pointers within the shared callback function memory block according to the unique label assigned thereto such that the launcher pointers and the application pointers that are assigned the same unique reference label are stored at the same location of the shared callback function memory block.

7. The method of claim 4 further comprising writing over each one of the launcher pointers when storing the application pointers to the shared callback memory block.

8. A memory architecture comprising:

a non-volatile, first application memory block having first application code for application functions capable of being called by a first application;

a non-volatile, second application memory block having second application code for application functions capable of being called by a second application;

a non-volatile, shared memory block having shared code for an n number of shared functions; and

n number of fixed memory locations dedicated within the shared memory block to store one of an n number of shared function pointers.

9. The memory architecture of claim 8 further comprising a volatile memory storing n number of callback pointers, each one of the n number of callback pointers being associated with each one of then number of shared functions.

10. The memory architecture of claim 9 wherein the n number of callback pointers point to (i) callback function code stored within the first application memory block when the first application is executing and (ii) callback function code stored within the second application memory block when the second application is executing.

11. The memory architecture of claim 10 wherein the volatile memory does not simultaneously store pointers to callback function code stored within the first application memory block and the second application memory block.

12. The memory architecture of claim 9 wherein the n number of callback pointers are stored in fixed locations of the volatile memory such that the callback pointers for each of the n number of shared functions are stored at the same location for each of the first and second applications.

13. The memory architecture of claim 12 wherein the code stored in the shared memory block for each of the n number of shared functions includes a pointer to the fixed location of the one of the n number of callback pointers associated with each shared function.

14. The memory architecture of claim 8 wherein the n number of fixed memory locations store the same one of then number of shared function pointers following each compiling of the shared code where at least the same n number of shared functions are still available.

15. The memory architecture of claim 8 wherein an amount of memory required to store the shared code for at least one of the shared functions increases in size following compiling and wherein each of the n number of shared function pointers remain in the same one of the n number of locations after the compiling.

16. A battery monitoring system (BMS) controller comprising:

a non-volatile, application memory block having application code for an application operable to execute battery monitoring related functions;

a non-volatile, launcher memory block having launcher code for a launcher operable for initializing the BMS;

a non-volatile, shared memory block having shared code for an n number of shared functions;

n number of fixed memory locations dedicated within the shared memory block to store one of an n number of shared function pointers; and

a volatile memory storing n number of callback pointers, wherein the n number of callback pointers point to code stored in the application memory block in the event the application is operating and to code stored in the launcher memory block in the event the launcher is operating.

17. The BMS controller of claim 16 wherein n number of callback pointers are stored in fixed locations of the volatile memory such that the callback pointers are stored at the same location while each of the launcher and applications are operating.

18. The BMS controller of claim 16 wherein the n number of fixed memory locations store the same one of then number of shared function pointers following each compiling of the shared code where at least the same n number of shared functions are still available.

19. The BMS controller of claim 18 wherein an amount of memory that is required to store the shared code for at least one of the shared functions increases in size following compiling and wherein each of the n number of shared function pointers remain in the same one of the n number of locations after the compiling.

20. The BMS controller of claim 16 wherein each of the launcher memory block and application memory block store n number of pointers, one associated with each one of the n number of fixed location of the shared memory block.