im producing 100 remote controls using pic16f1823 and i need unique id for each remote but it should be constant over time so i think its better to generate a random before programming in mplab compiler and then compile these 100 remotes
i want not to change the remote_id manually
#include "mcc_generated_files/mcc.h"
#define remote_id 33800
char col;
uint24_t data_out;
void Reset_state(void);
int Key(void);
int Key_prime(void);
void main(void)
{...
please help me in this problem
It should be possible to use SQTP mode with the IPE as described here.
http://microchipdeveloper.com/ipe:serial-quick-turn-programming-sqtp-settings
Can you have a script in production that alters the ihex file so
that your serial number would appear different in EEPROM (EE) as most pics have 1k of internal EE for data storage ?
Then the remote would read its unique serial number from EE locations.
This would be a simple job for `gawk' say...
Use the SQTP functionality in the MPLAB IPE. You need to enter 'advanced mode' and sign into the IPE first.
In the SQTP tab, set it to save the values in EEPROM, as 'Raw Data', at memory address 0x00. Press 'Generate' and it will write an sqtp file for you.
Select the SQTP file in the 'operate' tab, under the field where you select your .hex file.
Every time you flash a new mcu, the IPE will increment to the next value in the SQTP file, and will even keep track between sessions.
you can use this in your code to retrieve the data:
unsigned char EEPROM_ReadByte(unsigned char eepromAddress)
{
while(RD || WR); // check the WR&RD bit to see if a RD/WR is in progress
EEADR=eepromAddress; // Write the address to EEADR.
RD = 1; // Set the RD bit to trigger the eeprom read operation.
return(EEDATA); // Return the data read form eeprom.
}
Call EEPROM_ReadByte, passing in 0x00, and it will return one char from your data. Increment eepromAddress and it will return the second char, etc.
Note that your data will be in reverse order, I am not sure why, it is perhaps due to the way SQTP files are encoded.
Related
I'm writing a firmware for an ATMega328 and facing some issues. After searching in my logic for hours I could boil the code down to the most basic example and still have the problem.
I'm setting a pin to the value of a variable. Because I don't want to store to copies of a big array I'm setting the pin to the same value over and over again and if the variable changes, the pin gets set to a different state.
int main() {
DDRB |= _BV(PB2);
while (1) {
PINB |= _BV(PB2);
_delay_ms(50);
}
return 0;
}
The problem is that with this code the pin toggles on and off every 50ms.
I could think of restructuring my code so I can detect change of the mentioned variable without the need of a copy.
But in the end I don't understand the problem, because I'm setting a bit of the output port to the same value over and over again.
PINB is input register (output register is PORTB).
And yes, writing 1 to input register PINx toggle bit in corresponding output register PORTx and pin value in modern (almost all for now) AVRs.
I'm writing a kernel space component for a research project which requires me to intercept and checkpoint a user space process at different points in its execution (specific instructions.) For various reasons I cannot modify the user-space program or ptrace that process.
To accomplish this goal I'm attempting to insert an breakpoint (INT 3 instruction) in the user-space process at the point I need to checkpoint it, and then intercept the SIGTRAP in kernel space. Unfortunately, I can't seem to figure out how to properly modify the read-only text section of the user-space code from the kernel space of that process. I'm currently attempting to use the get_user_pages API to force the pages writable, and modify them, but the text data doesn't seem to change. The relevant portions of the code I'm attempting to use are below. user_addr is the user-space address to insert a breakpoint at (unsigned long); page is a struct page *.
char *addr;
unsigned long aligned_user_addr = user_addr & ~((unsigned long)PAGE_SIZE - 1);
down_read(¤t->mm->mmap_sem);
rc = get_user_pages(current, current->mm, aligned_user_addr,
1, 1, 1, &page, &vma);
up_read(¤t->mm->mmap_sem);
BUG_ON(rc != 1);
addr = kmap(page);
BUG_ON(!addr);
offs = user_addr % PAGE_SIZE;
/* NOTE: INT3_INSTR is defined to be 0xCC */
addr[offs] = INT3_INSTR;
BUG_ON(addr[offs] != INT3_INSTR); // Assertion fails
set_page_dirty(page);
kunmap(page);
page_cache_release(page);
I'm hoping someone with more kernel knowledge and experience will be able to tell me what I'm doing wrong, or the proper way to go about accomplishing my task.
Thank you for your help.
It turns out that my issue was actually with C sign extension. INT3_INSTR was defined as:
#define INT3_INSTR 0xCC
Which makes it an integer, and the line:
BUG_ON(addr[offs] != INT3_INSTR);
evaluated addr[offs] to be a signed char. In c when a signed char is compared to an int its type is elevated to that of int, and since its signed it will be signed extended if its MSB is 1. As 0xCC's MSB is always 1 the comparison always evaluated to:
BUG_ON(0xFFFFFFCC != 0xCC);
Which evaluated as false. Changing addr to a unsigned char * resolves the issue. and then the above code works.
I hope this does not turn out to be a totally braindead question.
I am editing a template WDF Windows USB device driver to send formatted data to one of the device's bulk out pipes; the data has to be set up in a certain way to tell the device to read an internal register.
The problem is that I cannot get the data to go across the bus in the exact format necessary. I wrote a small test app to enumerate the device and call DeviceIoControl with the input buffer set to a struct I set up according to spec.
I have a copy of a USB bus trace for a working case (performed by a driver whose source I have no access to), and I captured a bus trace for what happens when I call the custom IOCTL in my driver. What I see go across the bus is the data structure I set up prefixed with twelve bytes of data; the data structure is correct, but I want to know what the initial twelve bytes of data are, and stop the driver from sending them.
The driver, I believe, has been written properly; I put some debug traces in the driver and it looks like the buffer retrieved by WdfRequestRetrieveInputMemory already has the 12 bytes prepended, so this seems like this is happening pre-driver.
If it is useful information, the IOCTL is set up as METHOD_BUFFERED with FILE_ANY_ACCESS.
The relevant portion of the test code that sets this up is very simple:
const ULONG ulBufferSize = sizeof( CONTROL_READ_DATA );
unsigned char pBuffer[sizeof(CONTROL_READ_DATA)];
DWORD dwBytesReturned;
CONTROL_READ_DATA* readData = (CONTROL_READ_DATA*)pBuffer;
readData->field1 = data;
readData->field2 = moreData;
// ... all fields filled in...
// Send IOCTLs into camera
if( !::DeviceIoControl( hDevice,
IOCTL_CUSTOM_000,
&readData,
ulBufferSize,
&readData,
ulBufferSize,
&dwBytesReturned,
NULL ) )
{
dwError = ::GetLastError();
// Clean up here
return dwError;
}
The data I see go across the bus is: 80FD1200 CCCCCCCC CCCCCCCC + (My data).
Does anyone have any insights?
Wow, really ridiculous error. Notice I'm passing the address of readData to DeviceIoControl, which itself is already a pointer. I can't believe I wasted so much time on this.
Thanks all!
Alignment of the data is the culprit. Check out http://msdn.microsoft.com/en-us/library/2e70t5y1(v=vs.80).aspx to set it to one.
Well, the question says it all.
What I would like to do is that, every time I power up the micro-controller, it should take some data from the saved data and use it. It should not use any external flash chip.
If possible, please give some code-snippet so that I can use them in AVR studio 4. for example if I save 8 uint16_t data it should load those data into an array of uint16_t.
You have to burn the data to the program memory of the chip if you don't need to update them programmatically, or if you want read-write support, you should use the built-in EPROM.
Pgmem example:
#include <avr/pgmspace.h>
PROGMEM uint16_t data[] = { 0, 1, 2, 3 };
int main()
{
uint16_t x = pgm_read_word_near(data + 1); // access 2nd element
}
You need to get the datasheet for the part you are using. Microcontrollers like these typically contain at least a flash and sometimes multiple banks of flash to allow for different bootloaders while making it easy to erase one whole flash without affecting another. Likewise some have eeprom. This is all internal, not external. Esp since you say you need to save programatically this should work (remember how easy it is to wear out a flash do dont save unless you need to). Either eeprom or flash will meet the requirement of having that information there when you power up, non-volatile. As well as being able to save it programmatically. Googling will find a number of examples on how to do this, in addition to the datasheet you apparently have not read, as well as the app notes that also contain this information (that you should have read). If you are looking for some sort of one time programmable fuse blowing thing, there may be OTP versions of the avr, and you will have to read the datasheets, programmers references and app notes on how to program that memory, and should tell you if OTP parts can be written programmatically or if they are treated differently.
The reading of the data is in the memory map in the datasheet, write code to read those adresses. Writing is described in the datasheet (programmers reference manual, users guide, whatever atmel calls it) as well and there are many examples on the net.
Using Microchip C18 compiler with a pic18f, I want to create a "big" buffer of 3000 bytes in the program data space.
If i put this in the main() (on stack):
char tab[127];
I have this error:
Error [1300] stack frame too large
If I put it in global, I have this error:
Error - section '.udata_main.o' can not fit the section. Section '.udata_main.o' length=0x0000007f
How to create a big buffer? Do you have tutorial on how to manage big buffer on pic18f with c18?
Here's a tutorial on exactly this: http://www.dwengo.org/tips-tricks/large-variables
Basically, you declare your variable in a special section, and a pointer to it in the default section:
#pragma udata DATA // section DATA
int large_table[768];
#pragma udata // return to default section
int *table_ptr = &large_table[0];
Next, you update the linker script to define the large section by adding something like this:
DATABANK NAME=data START=0x200 END=0x7FF PROTECTED
SECTION NAME=DATA RAM=data
Note that there usually isn't any unmapped memory in which you can just put your DATA section, but the USB buffers are usually my first choice to canibalize (unless you need USB in the same project of course...)