I declared these global variables:
volatile unsigned char BUFFER[7]={0,0,0,0,0,0,0};//to get all data
volatile unsigned char *PTR=&BUFFER[0];//points to start address
Inside the Microchip PIC interrupt function, the pointer reads the UART register and deference it to BUFFER[] array according to my code:
*PTR=rcreg;
PTR++;
I then check the data in function main():
for(i=0;i<3;i++){
if(BUFFER[i]==DATA[i]){
k++;
if(k==2){LED_On();}
}
}
and set ptr to point at the start address of BUFFER[]
ptr=BUFFER;
Question: Is this the best way and correct way to read data in the register? How can I use pointer in interrupt function?
Thank you for your kind attention and help in advance!
You may want to consider implementing a lock-free circular buffer to transfer data between the ISR and main():
Circular lock-free buffer
Non-blocking algorithm
Related
How do you declare a pointer on a 16 bit Renesas RL78 microcontroller using IAR's EWB RL78 compiler to a register which has a 20 bit address?
Ex:
static int *ptr = (int *)0xF1000;
The above does not work because pointers are 16 bit addresses.
If the register in question is an on-chip peripheral, then it is likely that your toolchain already includes a processor header with all registers declared, in which case you should use that. If for some reason you cannot or do not wish to do that, then you could at least look at that to see how it declares such registers.
In any event you should at least declare the address volatile since it is not a regular memory location and may change beyond the control and knowledge of your code as part of the normal peripheral behaviour. Moreover you should use explicit sized data types and it is unlikely that this register is signed.
#include <stdint.h>
...
static volatile uint16_t* ptr = (uint16_t*)0xF1000u ;
Added following clarification of target architecture:
The IAR RL78 compiler supports two data models - near and far. From the IAR compiler manual:
● The Near data model can access data in the highest 64 Kbytes of data
memory
● The Far data model can address data in the entire 1 Mbytes of
data memory.
The near model is the default. The far model may be set using the compiler option: --data_model=far; this will globally change the pointer type to allow 20 bit addressing (pointers are 3 bytes long in this case).
Even without specifying the data model globally it is possible to override the default pointer type by explicitly specifying the pointer type using the keywords __near and __far. So in the example in the question the correct declaration would be:
static volatile uint16_t __far* ptr = (uint16_t*)0xF1000u ;
Note the position of the __far keyword is critical. Its position can be used to declare a pointer to far memory, or a pointer in far memory (or you can even declare both to and in far memory).
On an RL78, 0xF1000 in fact refers to the start of data flash rather then a register as stated in the question. Typically a pointer to a register would not be subject to alteration (which would mean it referred to a different register), so might reasonably be declared const:
static volatile uint16_t __far* const ptr = (uint16_t*)0xF1000u ;
Similarly to __far the position of const is critical to the semantics. The above prevents ptr from being modified but allows what ptr refers to to be modified. Being flash memory, this may not always be desirable or possible, so it is possible that it could reasonably be declared a const pointer to a const value.
Note that for RL78 Special Function Registers (SFR) the IAR compiler has a keyword __sfr specifically for addressing registers in the area 0xFFF00-0xFFFFF:
Example:
#pragma location=0xFFF20
__no_init volatile uint8_t __sfr PORT1; // PORT1 is located at address 0xFFF20
Alternative syntax using IAR specfic compiler extension:
__no_init volatile uint8_t __sfr PORT1 # 0xFFF20 ;
If I want to share something like a char **keys array between fork()'d processes using shm_open and mmap can I just stick a pointer to keys into a shared memory segment or do I have to copy all the data in keys into the shared memory segment?
All data you want to share has to be in the shared segment. This means that both the pointers and the strings have to be in the shared memory.
Sharing something which includes pointers can be cumbersome. This is because mmap doesn't guarantee that a given mapping will end up in the required address.
You can still do this, by two methods. First, you can try your luck with mmap and hope that the dynamic linker doesn't load something at your preferred address.
Second method is to use relative pointers. Inside a pointer, instead of storing a pointer to a string, you store the difference between the address of the pointer and the address of the string. Like so:
char **keys= mmap(NULL, ...);
char *keydata= (char*) keys + npointers * sizeof(char*);
strcpy(keydata, firstring);
keys[0]= (char*) (keydata - (char*) &keys[0]);
keydata+= strlen(firststring)+1;
When you want to access the string from the other process, you do the reverse:
char **keys= mmap(NULL, ...);
char *str= (char*) (&keys[0]) + (ptrdiff_t) keys[0];
It's a little cumbersome but it works regardless of what mmap returns.
This question is in my mind for many days but i got cleared till now
if i try to send a signal of a structure say
struct radarStruct
{
unsigned char *Data;
unsigned int rate;
unsigned int timeStamp;
float timeSec;
};
shall i emit the signal like
signals:
void radarGeneratorData(const radarStruct &);
or
signals:
void radarGeneratorData(radarStruct *);
More: what about the unsigned char *Data , whether the signal will make a deep copy of it ??
similar for a unsigned char *data how i can send the signal .
Friends please help me clear this , the best way to send a structure through signals & slot mechanism ..
Thnks in advance
This mainly depends on your requirement.
If you want to send the structure over to another object and "share" the structure, you would need to send the structure as a pointer so that changes are reflected at source. If not then you would want to send it as a const ref.
For either methods remember you need to Q_DECLARE_METATYPE(YourStructType) before you can use the structure in signal / slot arguments.
As for when a deep copy occurs / when a routine call back equivalent process happens, you can have a read through
Signaling failure in qt slots
Single Thread communication and Cross-Threaded communication differ within themselves and the output would again depend on your usage.
I have a program I want to make which will ask to see whether a variable already exists. If it does, it displays it, if it does not, it creates it and stores it in the Arduino using the PROGMEM command. Can someone explain more about PROGMEM and how to make the program I'm talking about?
Generally speaking if you are creating any variables in functions they are existing only there when function is closed all variables are deleted. If you want to keep them alive try to create global variables or use static before it;
like here
static int myvariable;
And here is answer for your question
if (myvariable!=NULL)
{
printfucntion(myvariable);
}
solution for eeprom
EEPROM Read
Reads the value of each byte of the EEPROM and prints it to the computer.
#include <EEPROM.h>
// start reading from the first byte (address 0) of the EEPROM
int address = 0;
byte value;
void setup()
{
Serial.begin(9600);
}
void loop()
{
// read a byte from the current address of the EEPROM
value = EEPROM.read(address);
Serial.print(address);
Serial.print("\t");
Serial.print(value, DEC);
Serial.println();
//move to next address of the EEPROM
address = address + 1;
// there are only 512 bytes of EEPROM, from 0 to 511, so if you are
// on address 512, wrap around to address 0
// if you have arduinoMega probably there is more eeprom space
if (address == 512)
address = 0;
delay(500);
}
I hope I helped.
This is a pretty stale question, and one that's not so popular. BUT is a valid question. In php, I am all the time using isset() to test for variables' existences. So, perhaps the OP is coming to embedded / C programming from the make-love-not-war world of php, where anything goes and isn't accustomed to the extremely literal and formal country of C.
As pointed out here, C language has #ifdef and #ifndef conditional defines that are often used for the exact purpose of testing if something is defined. To better understand the nuance of this usage, one should probably visit Programmers.SE and inquire about professional philosophy about conditional defines.
Me? I'm researching permanent variable storage on an Arduino via the EEPROM. Here are two different excellent articles. And about #ifdef's? I am just a lowly software engineer and save that for software architects. ;-) I have never intentionally implemented them, just see those a lot.
And a literal answer to the OP's question is: query the variable and try to use it. The Arduino's IDE compiler will scream if it is not defined.
Its simple , Just you need to Declare a variable.just compare with array of elements,you wanna compare with. If array element and enter element are present display using Serial.print() statement else you store it in array of buffer accumulating it. Display it.
As you are doing single link list
I have found these few lines of assembly in ollydbg:
MOV ECX,DWORD PTR DS:[xxxxxxxx] ; xxxxxxxx is an address
MOV EDX,DWORD PTR DS:[ECX]
MOV EAX,DWORD PTR DS:[EDX+116]
CALL EAX
Could someone step through and tell me what's happening here?
This is an invocation of a function pointer stored in a struct.
This first line obtains a pointer stored at address DS:xxxxxxxx. The square brackets indicate dereferencing of the address, much like * in C. The value from memory is about to be used as a pointer; it is placed into ecx register.
MOV ECX,DWORD PTR DS:[xxxxxxxx] ; xxxxxxxx is an address
The second line dereferences the pointer obtained above. That value from ecx is now used as the address, which is dereferenced. The value found in memory is another pointer. This second pointer is placed into the edx register.
MOV EDX,DWORD PTR DS:[ECX]
The third line again dereferences memory; this time, the access occurs to an address offset from the pointer obtained above by 0x116 bytes. This is not evenly divisible by four, so this function pointer does not appear to come from a C++ vtable. The value obtained from the memory is this time stored in register eax.
MOV EAX,DWORD PTR DS:[EDX+116]
Finally, the function pointed to by eax is executed. This simply invokes the function via a function pointer. The function appears to take zero arguments, but I have a question on revision of my answer: are there PUSH instruction which precede this snippet? Those would be the function arguments. The question marks indicate this function might return a value, we can't tell from our vantage.
CALL EAX
Overall, the code snippet looks like an invocation of an extension function from a plug-in library to OllyDbg. The OllyDbg ABI specifies various structs which contain some function pointers. There are also arrays of function pointers, but the double-indirection to get to the edx-held pointer (also the not-aligned-by-even-multiple offset) makes me think this is a struct and not an array of function pointers or a C++ class's vtable.
In other words, xxxxxxxx is a pointer to a pointer to a struct containing a function pointer.
In the OllyDbg source file PlugIn.h are some candidate struct definitions. Here's an example:
typedef struct t_sorted { // Descriptor of sorted table
char name[MAX_PATH]; // Name of table, as appears in error
int n; // Actual number of entries
int nmax; // Maximal number of entries
int selected; // Index of selected entry or -1
ulong seladdr; // Base address of selected entry
int itemsize; // Size of single entry
ulong version; // Unique version of table
void *data; // Entries, sorted by address
SORTFUNC *sortfunc; // Function which sorts data or NULL
DESTFUNC *destfunc; // Destructor function or NULL
int sort; // Sorting criterium (column)
int sorted; // Whether indexes are sorted
int *index; // Indexes, sorted by criterium
int suppresserr; // Suppress multiple overflow errors
} t_sorted;
Those examples are allowed to be NULL, and your asm snippet does not check for NULL pointer in the function pointer. Therefore, it would have to be DRAWFUNC from t_table or SPECFUNC of t_dump.
You could create a small project which includes the header file and uses printf() and offsetof() to determine whether either of those is at an offset of 0x116.
Otherwise, I imagine that the insides of OllyDbg are written in this same style. So there are likely to be private struct definitions (not published in the Plugin.h file) used for various purposes within OllyDbg.
I would like to add, I think it's a shame that OllyDbg sources are not available. I was under the impression that the statically-linked disassembler it contains was under some kind of ?GPL license, but I haven't had any luck getting the sources to OllyDbg.
Take the 32 bit number from the address xxxxxxx and put it in ECX register, then use this value as an address and read the value and put it in EDX register, finally add 116 to this number and read the value of that address into EAX. Then it starts executing the code at the address now held in EAX. When that code encounters a return opcode, execution will continue after the call instruction.
This is pretty basic assembly. It makes me wonder wtf you are doing with a debugger and when your assignment is due ;-)
It's been awhile since I did ASM (1997) and even then I was only doing i386 ASM so forgive me if my answer isn't all that helpful...
Unfortunately, these 4 lines of code don't tell me much. It's mostly just loading stuff into CPU registers and calling a function.
Specifically, It looks like data or perhaps a pointer is being loaded from that address into your CX register. Then that value is being copied from CX to DX. So you have the value of the pointer of CX located in DX. Then that value in DX plus an offset of 116 is being copied into the AX register (your accumulator?)
Then whatever function located at that address copied into AX is being executed.
I'm 99% sure it's a virtual method call, considering comments about compiler being MSVC.
MOV ECX,DWORD PTR DS:[xxxxxxxx]
Pointer to a class instance is loaded into ECX from a global variable. (NB: default __thiscall calling convention uses ECX to pass the instance pointer, aka the this pointer).
MOV EDX,DWORD PTR DS:[ECX]
vftable (virtual function table) pointer is usually the first item in the class layout. Here the pointer is loaded into EDX.
MOV EAX,DWORD PTR DS:[EDX+116]
A method pointer at offset 116 (0x74) in the table is loaded into EAX. Since each pointer is 4 bytes, this is the 30th virtual method of the class (116/4 + 1).
CALL EAX
The method is called.
In original C++ it would look something like this:
g_pObject1->method30();
To know more about MSVC's implementation of C++ classes, including virtual methods, see my article here.