|
They don't share the same memory location. To do that the outer struct must be a union (see Union declaration - cppreference.com[^] ).
From my point of view you are right that it looks like a definition for shared access and that is an error in the documentation. To verify this have a look at the register specifications in the data sheet.
|
|
|
|
|
How about this struct:
typedef struct {
struct {
u32_T ASID:10,
rsvd1:22;
} asid;
} ASID_T;
it can implement the 32-bit access and bit access, right?
|
|
|
|
|
With that you have no access to the 32-bit value.
Use a union instead:
typedef union {
u32_T asid;
struct {
u32_T ASID:10,
rsvd1:22;
};
} ASID_T;
|
|
|
|
|
can't use union, MISRA-C rule 18.4, forbid to use union.
|
|
|
|
|
Then use what you need in your code (struct or u32_T).
As last resort you can also use casting:
ASID_T *asid = ASID_REG_ADDR;
u32_T *asidReg = (u32_T*)asid;
|
|
|
|
|
From memory that breaks several other MISRA-C rules under section 11 ... 11.1 through 11.6 restrict what you can do with C casts.
Hardware related implementations usually involve coding that MISRA rules see as "dangerous". I can tell you from experience the easiest way around them is drag it down to included assembler blocks. The assembler blocks fall outside the scope of MISRA.
You could define two different extern's in a .h file to the same register with assembler which would essentially restore the use of the union yet be MISRA compliant 
In vino veritas
modified 25-Apr-17 10:57am.
|
|
|
|
|
I suspected that casting may be limited too.
I don't know MISRA rules well but when macros - or better - inline functions are allowed those can be used to split the 32-bit value into bits fields or vice versa.
|
|
|
|
|
No those are still technically C and hence under MISRA rules.
It's a really weird standard adopted by some automobile manufacturers and a few telco's as some sort of we will get better code think-tank. The reality is all studies have shown it has almost zero improvement on software bug numbers or severity.
As I said, the few times I have run across it, I do what most do ... drop to assembler and go around the rubbish. That in itself tells you how good the standard is.
Other than that you can go thru the process to raise a deviation (section 5.3.2) but that means documenting and getting approval for the variation which is far more red tape than most can handle.
The standard libraries are also exempt from MISRA under a special rule 6.6 and so you can implement your own special standard library function to get around it. Think about it memcpy and memmove take void* and you have a specific register address target
In vino veritas
modified 25-Apr-17 12:34pm.
|
|
|
|
|
|
This doesn't seem to make sense: the inner struct is just a type definition without an actual typename, but it does not define a variable of that type:
struct {
u32_T ASID:10,
rsvd1:22;
};
You might just as well delete that inner struct declaration, since, being unnamed and unused, there is no way to use it later.
If you move the symbol asid to the end of that type declaration, asid would be a struct, not an int, although it would occupy exactly 4 bytes, which may or may not coincide with the size of an int in your system.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
Sure, should has a struct variable name.it's a typo.
|
|
|
|
|
Am trying to determine the performance evaluation between face recognition system and fingerprint recognition system. so am trying to write the code that will help me evaluate the performance. Am doing it for my Final year project in my first degree.
|
|
|
|
|
So?
What have you done by now? Do you have the performance metric, information of the algorithms, complexity (O(n) etc.), if they are not provided then there is very less that we can share or explain here.
Basically, for your FYP, you need to start with an intro (of both these frameworks), then you need to explain pros and cons of them both, the performance of both, benefits of either framework over the other one. It is your job to find those patterns, then you need to analyze that based on the factors (implementation cost, risk factors, etc. etc.) and then present all of that.
The sh*t I complain about
It's like there ain't a cloud in the sky and it's raining out - Eminem
~! Firewall !~
|
|
|
|
|
Thanks so much, I will work on that...
|
|
|
|
|
Hi,
Am using
CFileDialog fileDlg VC++2008 version. Button use to open
CFileDialog below code i used. My problem is more then 5 times i call this function. It shows 'debug assertion error'
File: f:\dd\vc7libs\ship\atlmfc\src\wincore.cpp
line:398
finally debug goes here
CWnd* pWnd = CWnd::FromHandlePermanent(hWnd);
Here My Code
TCHAR szFilters[]= _T("MyType Files (*.my)|*.my|All Files (*.*)|*.*||");
CFileDialog fileDlg(TRUE, _T("my"), _T("*.my"),
OFN_FILEMUSTEXIST | OFN_HIDEREADONLY, szFilters);
if(fileDlg.DoModal() == IDOK)
{
CString pathName = fileDlg.GetPathName();
CString fileName = fileDlg.GetFileTitle();
SetWindowText(fileName);
}
|
|
|
|
|
You did not show the line that asserts so I can only guess that it checks if pWnd is NULL (I have no VS2008 here but it seems that the code snippet is from the AfxWndProc function).
From that line debug backwards to identify the invalid window handle that finally leads to the assertion.
Because your code snippet using the CFileDialog is just a copy of the MSDN example code I guess that the assertion is not related to the file dialog but to some other window or you did not showed the used code.
In the latter case you might try to pass also the pParentWnd to the file dialog.
|
|
|
|
|
Hi,
Are you running this code on a Microsoft operating system older than Vista?
If so... this is most likely happening because the once you hit the OK button... the window closes.
The older MFC versions use the SendMessage function[^] and send a CDM_GETSPEC message[^] to the CFileDialog window and get the file name and the CDM_GETFILEPATH message[^] to get the path.
You can potentially avoid this by setting the CFileDialog::m_ofn.lpstrFile[^] member to a local buffer.
Best Wishes,
-David Delaune
|
|
|
|
|
We have a console application to represent a process plant model. This application has several functions for doing plant calculations. We have defined a structure and a global object for maintaining the data and doing calculations, which is initialized in one of the function. We assign and calculate values for the members of the object by using it in all the corresponding functions.
For Eg:
struct plantDB
{
short IMISC_I [300];
char LL1_I [300];
char LL2_I [300];
char MALF_I [300];
char REMP_I [300];
float REM_I [300];
float NXS [30][600];
float VAR_I [1500];
float VART_I [300];
float VRAMP_I [300];
.
.
.
};
plantDB *ETest = new PlantDB;
Sample of the function:
float EULER(int N,int K,int TYPE,float DER,float MAX,float MIN,float FLAG)
{
float FACTOR = 0.0 ;
float EULER;
if ( FLAG ) ETest->VAR_I = 51.0 ;
}
We have defined a number of functions as shown above which changes the value of each of the members of ETest. Now our requirement is to identify and separate the functions to create a library to abstract it from users of the application.
Now, when I create a static library application and add the files with all the functions, and add the lib in my original application to use the functions, the functions still need to use the same object ETest, which is used in the main application as well. Is there any way to share the structure between the main application and the static library. Can I use the createfilemapping for creating a shared memory to assign values in the main app as well as the static library?
|
|
|
|
|
You should just pass the structure by reference to all functions that need to access its content.
|
|
|
|
|
you don't need to do anything special for this. static libs (as opposed to DLLs) get linked directly into your app so they'll use the same memory your main app does.
|
|
|
|
|
A DLL gets mapped into the main application's address space, so it effectively has full access also.
|
|
|
|
|
yeah, you're right. i should've phrased that better; i was thinking more along the lines of dynamic CRT, which complicates new/delete.
|
|
|
|
|
I don't see how, it is just allocating space on the heap which is part of the data sections in the address space. If this were an issue then hardly any DLL code would work properly.
|
|
|
|
|
|
Chris Losinger wrote: if you try to delete/free memory in one place that was allocated in the other.
You should be punished severely. In fact you probably will be when your application starts misbehaving.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
