register_chrdev(unsigned int major,const char *name,const struct file_oprations *fops)
and
alloc_chedev(dev_t devid,unsigned int fmi,unsigned int nod,const char *name)
The small difference which i knew was that register_chrdev will allocate 256 minor no. associated with a device whereas alloc_chrdev asks for no. of devices and first minor no. and will allocate accordingly.
register_chrdev used to register a major number for character devices. User has to give the major number to the API for respective device.
alloc_chrdev used to allocates a range of char device numbers. The major number will be chosen dynamically and returned along with the first minor number.
Related
I'm using a STM32F401VCT6U "discovery" board, and I need to provide a way for the user to write addresses in memory at runtime.
I wrote what can be simplified to the following function:
uint8_t Write(uint32_t address, uint8_t* values, uint8_t count)
{
uint8_t index;
for (index = 0; index < count; ++index) {
if (IS_FLASH_ADDRESS(address+index)) {
/* flash write */
FLASH_Unlock();
if (FLASH_ProgramByte(address+index, values[index]) != FLASH_COMPLETE) {
return FLASH_ERROR;
}
FLASH_Lock();
} else {
/* ram write */
((uint8_t*)address)[index] = values[index]
}
}
return NO_ERROR;
}
In the above, address is the base address, values is a buffer of size at least count which contains the bytes to write to memory and count the number of bytes to write.
Now, my problem is the following: when the above function is called with a base address in flash and count=100, it works normally the first few times, writing the passed values buffer to flash. After those first few calls however, I cannot write just any value anymore: I can only reset bits in the values in flash, eg an attempt to write 0xFF to 0x7F will leave 0x7F in the flash, while writing 0xFE to 0x7F will leave 0x7E, and 0x00 to any value will be successful (but no other value will be writable to the address afterwards).
I can still write normally to other addresses in the flash by changing the base address, but again only a few times (two or three calls with count=100).
This behaviour suggests that the maximum write count of the flash has been reached, but I cannot imagine it can be so fast. I'd expect at the very least 10,000 writes before exhaustion.
So what am I doing wrong?
You have missunderstood how flash works - it is not for example as straight forward as writing EEPROM. The behaviour you are discribing is normal for flash.
To repeatidly write the same address of flash the whole sector must be first erased using FLASH_EraseSector. Generally any data that needs to preserved during this erase needs to be either buffered in RAM or in another flash sector.
If you are repeatidly writing a small block of data and are worried about flash burnout do to many erase write cycles you would want to write an interface to the flash where each write you move your data along the flash sector to unwriten flash, keeping track of its current offset from the start of sector. Only then when you run out of bytes in the sector would you need to erase and start again at start of sector.
ST's "right way" is detailed in AN3969: EEPROM emulation in STM32F40x/STM32F41x microcontrollers
This is more or less the process:
Reserve two Flash pages
Write the latest data to the next available location along with its 'EEPROM address'
When you run out of room on the first page, write all of the latest values to the second page and erase the first
Begin writing values where you left off on page 2
When you run out of room on page 2, repeat on page 1
This is insane, but I didn't come up with it.
I have a working and tested solution, but it is rather different from #Ricibob's answer, so I decided to make this an answer.
Since my user can write anywhere in select flash sector, my application cannot handle the responsability of erasing the sector when needed while buffering to RAM only the data that need to be preserved.
As a result, I transferred to my user the responsability of erasing the sector when a write to it doesn't work (this way, the user remains free to use another address in the sector to avoid too many write-erase cycles).
Solution
Basically, I expose a write(uint32_t startAddress, uint8_t count, uint8_t* values) function that has a WRITE_SUCCESSFUL return code and a CANNOT_WRITE_FLASH in case of failure.
I also provide my user with a getSector(uint32_t address) function that returns the id, start address and end address of the sector corresponding to the address passed as a parameter. This way, the user knows what range of address is affected by the erase operation.
Lastly, I expose an eraseSector(uint8_t sectorID) function that erase the flash sector whose id has been passed as a parameter.
Erase Policy
The policy for a failed write is different from #Ricibob's suggestion of "erase if the value in flash is different of FF", as it is documented in the Flash programming manual that a write will succeed as long as it is only bitreset (which matches the behavior I observed in the question):
Note: Successive write operations are possible without the need of an erase operation when
changing bits from ‘1’ to ‘0’.
Writing ‘1’ requires a Flash memory erase operation.
If an erase and a program operation are requested simultaneously, the erase operation is
performed first.
So I use the macro CAN_WRITE(a,b), where a is the original value in flash and b the desired value. The macro is defined as:
!(~a & b)
which works because:
the logical not (!) will transform 0 to true and everything else to false, so ~a & b must equal 0 for the macro to be true;
any bit at 1 in a is at 0 in ~a, so it will be 0 whatever its value in b is (you can transform a 1 in 1 or 0);
if a bit is 0 in a, then it is 1 in ~a, if b equals 1 then ~a & b != 0 and we cannot write, if bequals 0 it's OK (you can transform a 0 to 0 only, not to 1).
List of flash sector in STM32F4
Lastly and for future reference (as it is not that easy to find), the list of sectors of flash in STM32 can be found on page 7 of the Flash programming manual.
Assumed I have a JTAG-chain with several devices from different manufactures:
How does my software, which shall communicate with a specific system within that chain, known the length of the IR for all the others devices within the chain? I do have to know them to send a certain instruction to my device, right?
It is possible to detect the total length of all IR registers in your JTAG daisy-chain. It is also possible to detect the number of devices (or TAPs) in your chain. But you can't detect the individual IR length of a single TAP.
What you can do: You can read out the JTAG ID code register of all of you TAPs. The ID code register (in DR path) is always 32 bit and gets selected by test-logic-reset.
With the ID code you can identify the existing TAPs and look up in the datasheet the length of the individual IR registers.
And yes: In general you do have to know the individual IR length of all the TAPs in your chain to communicate with one of them.
try here: http://www.fpga4fun.com/JTAG3.html
When IR = '1...1', the BYPASS is selected.
The idea is to send a lot of '1' so regardless of IR length all devices will select BYPASS.
I have a register map which has 16 bit wide registers. I have a field with is greater than 16 bits wide, so it must span two addresses. How do I define the backdoor access to this field?
This is what I tried for my field test_pattern[23:0]:
register_a.add_hdl_path_slice("path.to.regmap.test_pattern[15:0]", 0, 16);
register_b.add_hdl_path_slice("path.to.regmap.test_pattern[23:16]", 0, 8);
This fails with this error:
ERROR: VPI TYPERR
vpi_handle_by_name() cannot get a handle to a part select.
It is not clear if this is a constraint of my tool, or of how the UVM code uses the VPI. After poking around inside the UVM code I see the code that should handle part-selects, but it is inside #ifdef QUESTA directives so I think this is a tool constraint.
Is there a good work around for this?
According to the UVM Class Reference:
function void add_hdl_path_slice(string name,
int offset,
int size,
bit first = 0,
string kind = "RTL")
I'm guessing the solution should use the offset to select the starting index.
register_a.add_hdl_path_slice("path.to.regmap.test_pattern", 0, 16);
register_b.add_hdl_path_slice("path.to.regmap.test_pattern", 16, 8);
Possible alternative, bit select in a for-loop:
for (int i=0; i<16; i++) begin
string tmp_path_s;
tmp_path_s = $sformatf("path.to.regmap.test_pattern[%0d]", i);
register_a.add_hdl_path_slice(tmp_path_s, i, 1);
end
for (int i=0; i<8; i++) begin
string tmp_path_s;
tmp_path_s = $sformatf("path.to.regmap.test_pattern[%0d]", i+16);
register_a.add_hdl_path_slice(tmp_path_s, i, 1);
end
It's a great pity that whoever contributed this code (presumably Mentor?) felt it necessary to add a useful feature to a Universal library wrapped in ifdefs. In fact it's even worse on the UVM_1_2 branch where the whole DPI/PLI interface file is split into simulator specific implementations!
Looking at distrib/src/dpi/uvm_hdl.c on master branch of git://git.code.sf.net/p/uvm/code it looks like the only QUESTA specific code is this function:
static int uvm_hdl_set_vlog_partsel(char *path, p_vpi_vecval value, PLI_INT32 flag);
static int uvm_hdl_get_vlog_partsel(char *path, p_vpi_vecval value, PLI_INT32 flag);
Which uses the following DPI defined values:
svLogic logic_bit;
svGetBitselLogic(&bit_value,0);
svLogicVecVal bit_value;
svGetPartselLogic(&bit_value,value,i,1);
svPutPartselLogic(value,bit_value,i,1);
In theory if both your simulator and the Mentor code are compliant to the standard you could remove the ifdefs and it should still work.
You could also do this by detecting the part select in the path and use vpi_handle_by_index to read the individual bits, which should also be supported in any simulator.
NB my original answer was wrong about the code being Mentor specific - thanks to #dave_59 for setting me straight and apologies to Mentor.
Is there some reason why you aren't splitting this into 2 registers. Since your register size is 16 bits it doesn't make sense to declare a register that is larger than this.
The way I've seen large fields like this defined is to declare 2 registers with a separate field in each. For example, if you needed a 32-bit pointer you'd have:
addr_high with a 16 bit field
addr_low with a 16 bit field
For convenience, you could add a task that would access both in sequence.
I am trying to write code for generating globally unique name for images that are to be uploaded by users from iOS app to server. The names should be randomly generated and should be unique so that the images are not overwritten/replaced.
Here's my code for generating random and unique strings:
+ (NSString *)generateRandNameWithLength:(int)len
{
NSString *letters = [NSString stringWithFormat:#"abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ%#0123456789", [HJUtilities generateUniqueApId]];
NSMutableString *randomString = [NSMutableString stringWithCapacity: len];
for (int i=0; i<len; i++) {
[randomString appendFormat: #"%C", [letters characterAtIndex: arc4random() % [letters length]]];
}
return randomString;
}
Where:
+ (NSString *)generateUniqueApId
{
NSString *appId = (__bridge NSString *) CFUUIDCreateString (NULL, CFUUIDCreate(NULL));
return appId;
}
returns a UUID.
Now I'm not sure whether this is the correct code for generating globally unique strings. I don't know how to verify this to be certain that no user will overwrite another user's image.
Note: I'm using Amazon Web services for storage. And one common bucket will be used for all the images of all users. So, its required that images names should be unique.
There is no need for the code you have. All you need is the CFUUIDCreateString function. This will be unique across all users on all devices.
From the docs for CFUUID:
UUIDs (Universally Unique Identifiers), also known as GUIDs (Globally Unique Identifiers) or IIDs (Interface Identifiers), are 128-bit values guaranteed to be unique. A UUID is made unique over both space and time by combining a value unique to the computer on which it was generated—usually the Ethernet hardware address—and a value representing the number of 100-nanosecond intervals since October 15, 1582 at 00:00:00.
The code you have now is definitely not guaranteed to be unique.
There is a new class added in iOS 6.0
#interface NSUUID : NSObject <NSCopying, NSSecureCoding>
To simplify the memory management you for sure can use it
You're overcomplicating it. Just get a UUID using CFUUIDCreateString and use that string. Adding extra layers of randomness isn't going to help. In fact, it's probably going to make things worse by increasing the chance of a name collision.
The only argument against using a UUID directly is that it may be possible to identify the source of the upload, since the UUID is (or can be) generated using device's MAC address, which is specific to the hardware. You won't be able to identify a user with nothing but a UUID, but you would be able to say "this collection of UUIDs came from the same device" or "this UUID came from this device". (See RFC 4122 for the various UUID formats and a discussion of this issue in section 4.5.)
If anonymity is a concern, running the UUID through a hash function, like SHA1 or MD5, would be good enough to make it unidentifiable.
Using a loop where you "add randomness" by mixing in random numbers is like shaking a dice for a few seconds versus an hour: the only difference is that you're rubbing sweat onto the dice.
As far as a locally unique string — which you could use as part of the file name — this is handy:
[[NSProcessInfo processInfo] globallyUniqueString]
I got this error on a CJ1W-CT021 card. It happen all of a sudden after its been running the program for some time. How i found it was by going to the IO Table and Unit Set up. Clicked on parameters for that card and found two settings in red.
Output Control Mode and And/Or Counter Output Patterns. This was there reading
Output Control Mode = 0x40 No Applicable Set Data
And/Or Counter Output Patterns = 0x64 No Applicable Set Data
no idea on how or why these would change they should of been
Output Control Mode = Range Mode
And/Or Counter Output Patterns = Logically Or
I have added some new code, but nothing big or really even used as i had the outputs of the new rungs jumped out. One thing i thought might cause this is every cycle of the program it was checking the value of an encoder connected to this card. Maybe checking it too offten? Anyhow if anyone has any idea what these do or how they would change please post.
Thanks
Glen
EDIT.. I wanted to add the bits i used, dont think any are part of this cards internal io but i may be wrong?
Work bits 66.01 - 66.06 , 60.02 - 60.07 , 160.12, 160.01 - 160.04, 161.02, 161.03
and
Data Bits (D)20720, 20500, 20600, 20000, 20590, 20040
I would check section 4-1 through 4-2-4 of the CT021 manual - make sure you aren't writing to reserved memory locations used for configuration data of the CT021 unit.
EDIT:
1) Check Page 26 of the above manual to see the location of the machine switch settings. The bottom dial sets the '1's digit and the top dial sets the '10's digit (ie machine number can be 0-99);
2) Per page 94, D-Memory is allocated from D20000 + (N X 100) (400 Words) where N is equal to the machine number.
I would guess that your machine number is set to 0 (ie: both dials at '0'), 5, or 6. In the case of machine number '0', this would make the reserved DM range D20000 -> D20399. In this case (see pages 97, 105) D20000 would contain configuration data for Output Control Mode (bits 00-07) and Counter Output Patterns (bits 08-15). It looks like you are writing 0x6440 to D20000 (or D20500, D20600 for machine number 5 or 6, respectively) and are corrupting the configuration data.
If your machine number is 0 then stay away from D20000-D20399 unless you are directly trying to modify the counter's configuration state (ie: don't use them in your program!).
If the machine number is 1 then likewise for D20100-D20499, etc. If you have multiple counters they can overlap ranges so they should always be set with machine numbers which are 4 apart from each other.