Re: Byte to int32/big and little endian
Excerpts from Tim Hardisty's message of February 26, 2023 12:17 pm:
>
> On 25/02/2023, 11:47, "Karel Kočí" mailto:cyn...@email.cz>>
> wrote:
>
>>I would use union (that is host ordering) and to convert to specific ordering
>>you can use functions like htobe32 (big endian) and htole32 (little endian),
>> those are available.
>
>> Excerpts from Tim Hardisty's message of February 25, 2023 11:26 am:
>>> As is so often the case, I need to pack an array of 4x uint8_t into a
>>> uint32_t. Obviously there are many ways to do this and we all have our
>>> favourite. For NuttX:
>>>
>>> 1) have I missed a library function that does this already?
>>> 2) to cope with big and little end is there a NuttX CONFIG or other
>>> parameter that will give the endian-ness of the arch being built to ensure
>>> the byte packing is done correctly?
>
> When using a union is it fair to assume that it is the responsibility of an
> app rather than a driver to sort endian-ness? I can find no references in the
> NuttX code base to changing endian-ness?
>
> Perhaps I'm over-thinking!
>
The example might be helpful. Lets start with absolute basic just to be sure we
understand each other:
union {
uint32_t u32;
uint8_t u8[4];
} foo;
foo.u32 = 42; // This uses host's endianness and the compiler's responsibility
// The following prints most significant byte on the big endian and least
// significant byte on the little endian. Probably nothing new...
printf("%d\n", foo.u8[0]);
The point is that compiler always knows the correct endianness and uses it.
That
is also what you accept as argument in most functions (commonly expected when
order is not documented).
Now when you are implementing chip specific driver you know endianness and thus
there is no need to do swap when it matches.
On the other hand, when you are implementing generic driver, expected to be
running on any CPU, you need to ensure that swap happens when ever it is
required (endianness doesn't match). The common approach, not just in NuttX,
are
those functions I pointed previously. The manual page for them is endian
(https://man7.org/linux/man-pages/man3/endian.3.html).
I think that you are overthinking it and you missed the library call. 😉
pgpfoXYVOnpu_.pgp
Description: PGP signature
Re: W25Nx NAND flash support
On Sat, Feb 25, 2023 at 8:53 AM Gregory Nutt wrote: > > > Maybe LittleFS or SmartFS could be extended to handle NAND. > > I believe that LittleFS has been used with NAND with a NAND FLASH > translation layer. I am not sure of the state of that work, but I know > that people have tried it. Google "LittleFS on NAND flash" and see the > hits. > > If a NAND flash translation layer (NFTL) were ported to NuttX, then you > should be able to use almost any file system, although some would be > extremely inefficient with NAND. The NAND flash layer would need to do > sparing, wear-leveling, ECC calculations, etc. as needed by NAND. > > I have used NXFFS with NAND and it /almost /works. > > The basic filesystem issue is that all available filesystems need to do > read-modify-write operations on flash sections. And they assume that > you can always write a '1' bit to a '0' bit. SmartFS and NXFFS both > assume this behavior explicitly. It is a good assumption with NOR > flash. The problem is that NAND can only be written a whole sector at a > time. This is because the error correction coding (ECC): If you change > even one bit in the NAND sector, you have to re-write the whole sector > with new ECC (because you can't change the '0' bits in the ECC back into > '1''s without erasing the sector). > > Since SmartFS and NXFFS both do bit twiddling in the sectors they would > be very inefficient with an NFTL: Each bit twiddle would cause a whole > sector re-write. The same is probably true for LittleFS. Other file > systems like FAT could also be used if there were an NFTL, however, FAT > would also be inefficient (each directory update or FAT update and each > file data size change would cause another sector write). > > So the only real solution to support NAND efficiently is use a file > system that is designed specifically around the peculiarities of NAND. > That would require some research (Alan has suggested a couple of places > to start). I seem to recall reading that in NAND flash, one of the challenges is that modifying a bit causes a disturbance that can corrupt other bits, even in unrelated sectors, and that even reading can have this effect. The disturbance only affects bits a little at a time, but after some number of accesses, the affected sectors need to be written to new sectors, keeping track of bad sectors formed in the process, to avoid data loss. This may lead to a cascade effect in which reading a sector may cause numerous sectors to be re-written. This phenomenon is called write amplification. The takeaway from a usage perspective is that you want to over-provision the amount of NAND flash you install, to leave plenty of room for all this swapping, and plenty of extra sectors to increase the amount of accesses before failure. The greater the over-provisioning, the longer until failure. I haven't tried yet, but I would like at some point to support a micro-SD and/or micro-MMC card as the backing store and use one that has built in hardware wear leveling, with some appropriate file system of course. This may add $50 or more to the bill of materials depending on the card capacity, but makes it possible for users to replace the card if it fails, in contrast to soldered-on flash chips, which can be replaced too, but only with the appropriate tools and skills. Cheers Nathan
Re: Byte to int32/big and little endian
On 26/02/2023, 12:37, "spudaneco" mailto:spudan...@gmail.com>> wrote: > I can find no references in the NuttX code base to changing > endian-ness?Search for CONFIG_ENDIAN_BIG Could have sworn I searched for that as had come across that CONFIG option. Search fail...sorry. I will look at what the drivers that check that do and follow suit. Thanks!
Re: Byte to int32/big and little endian
> I can find no references in the NuttX code base to changing endian-ness?Search for CONFIG_ENDIAN_BIG
Re: Byte to int32/big and little endian
On 25/02/2023, 11:47, "Karel Kočí" mailto:cyn...@email.cz>> wrote: >I would use union (that is host ordering) and to convert to specific ordering >you can use functions like htobe32 (big endian) and htole32 (little endian), > those are available. > Excerpts from Tim Hardisty's message of February 25, 2023 11:26 am: >> As is so often the case, I need to pack an array of 4x uint8_t into a >> uint32_t. Obviously there are many ways to do this and we all have our >> favourite. For NuttX: >> >> 1) have I missed a library function that does this already? >> 2) to cope with big and little end is there a NuttX CONFIG or other >> parameter that will give the endian-ness of the arch being built to ensure >> the byte packing is done correctly? When using a union is it fair to assume that it is the responsibility of an app rather than a driver to sort endian-ness? I can find no references in the NuttX code base to changing endian-ness? Perhaps I'm over-thinking!
