Re: SD and eMMC performance in Nuttx
Hi, I've been busy on other tasks therefore haven't obtained a oscilloscope trace yet, but one of my peers have performed some profiling on a different micro and non-secure core, with the mxrt1064-evk:nsh configuration + tickless and 100us tick rate: nsh> dd if=/dev/zero of=/dev/null bs=4096 count=100 409600 bytes copied, 2200 usec, 181818 KB/s nsh> mkrd -m 1 -s 512 1024 nsh> mkfatfs /dev/ram1 nsh> mount -t vfat /dev/ram1 /mnt nsh> dd if=/dev/zero of=/dev/null bs=4096 count=100 409600 bytes copied, 2200 usec, 181818 KB/s nsh> dd if=/dev/zero of=/mnt/t bs=4096 count=100 409600 bytes copied, 4700 usec, 85106 KB/s nsh> umount /mnt nsh> mkfatfs /dev/mmcsd0 nsh> mount -t vfat /dev/mmcsd0 /mnt nsh> dd if=/dev/zero of=/mnt/t bs=4096 count=100 409600 bytes copied, 959000 usec, 417 KB/s nsh> dd if=/dev/zero of=/dev/sd0 bs=4096 count=100 409600 bytes copied, 361400 usec, 1106 KB/s As observed, the raw speed for the RAM based block device is 181 M/S, through vfat on a ramdisk is 85 M/S and 0.5M/S with SD (Class 4). The raw speed using the BCH device (sd0) is 1M/s. On Fri, 2 Jun 2023 at 05:18, Gregory Nutt wrote: > > > That would help when tickless mode is used. But what about tickful mode? > I > > guess the intent of 7312a553b was to avoid wasting processor cycles on > busy > > waiting, but if tickless isn't being used, perhaps busy waiting is > > necessary here? It could choose between the two wait types at compile > time > > based on tickless mode. > In "tickful" mode, you could increase the timer frequency to improve > resolution. At 1000 Hz things run pretty well too. But at some point, > however, the interrupt processing overhead becomes prohibitive. > > Or a bigger question: if tickless mode is "better" (longer battery life, > > fewer unnecessary interrupts, more processor cycles for real work) why > > aren't we always using tickless mode? Are there limitations/bugs that > make > > it unsuitable in some situations? Not universally supported on all > > microprocessors? Other reasons? > > It does rely on an available high resolution timer and, so, uses > resources that not all MCUs may have. It would also take a substantial > effort to convert all existing architectures to support tickless. > > But the real reason is that tickless mode was experimental and not > supported on all platforms on initial release and also not well > trusted. But I think it is well trusted these days and could be the > standard. > > I am not opposed to the idea at all. I do like the "tickful" mode for > MCU bringup because it is a lot simpler. Tickless support can be added > later when the port is stable. > > >
Mailing List
Hello, I am a developer using NuttX and would like to be added to the mailing list for NuttX development. Thanks! Sharwin Patil GreenSight
qencoder / long / float / double / maximum values
Hello world :-) I am working on ESP32 (no FPU) and using Quadrature Encoder for motor control and range positioning. Current qencoder implementation stores counted values on int32_t so the maximum and minimum value is only around +/- 32k. I need far bigger numbers to be counted and available for readout quickly. Long Story Short: 1. I would like to change representing counted values on a big floating number type with a sign, or just a bigger integer type. 2. I would like to ask what type would be best to represent floating numbers in NuttX in terms of portability and efficiency. Short Story Long: I am thinking of extending (configuration time option) Quadrature Encoder implementation so it would hold count number on a signed floating point like R.I where R would indicate full Round and I in the decimal part would indicate counted Impulses. That would enable counting large numbers independently of the used sensor in a single variable. Full round is usually indicated with additional signal line, or it could be counted using modulo of the decimal part with a given sensor resolution (i.e. 100 impulses per round, 1024 impulses per round, etc). This way integer part would indicate full rounds, while the decimal part would indicate actual counted impulses. For instance: 1. We have qencoder sensor with 100 impulses per Round, so initial value would be 0.0 and moving CW (clockwise) 0.0 -> .. -> 0.99 -> 1.0 -> .. 1.99 -> 2.0 -> etc. 2. We have qencoder sensor with 1024 impulses per Round, so initial value would be 0.0 and moving CCW (counterclockwise) 0.0 -> -0.1023 -> -1.0 -> .. -> -1.1023 -> -2.0 -> .. -> -2.1023 -> -3.0 -> etc. This way no matter what sensor is used the integer part of the readout will always indicate full round move of a wheel (both are in a single variable). And the number should be large enough to provide actual position. Does that make sense? Is this a good idea to extend qencoder module for this.. or that functionality should be implemented on the application level? Application level could be too slow to calculate this and it only task is to wait for a specific value and start / stop the motor, then perform other tasks. If this makes sense, then what variable type should be selected for storing counter value? What would be most portable and efficient? float (32bits)? double (64bits)? long double (80bits)? If this does not make sense and integer operations would be always simpler and faster, then what biggest integer type with a sign should I choose? :-) Any hints welcome :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
Re: qencoder / long / float / double / maximum values
On Fri, Jun 9, 2023 at 1:53 AM Tomek CEDRO wrote: > I am working on ESP32 (no FPU) and using Quadrature Encoder for motor > control and range positioning. Current qencoder implementation stores > counted values on int32_t so the maximum and minimum value is only > around +/- 32k. I need far bigger numbers to be counted and available > for readout quickly. Sorry its 2AM here and I sit too much in front of the computer with no fresh air :-P int is 32 bit with range unsigned 4.294E9 aka 4,294,967,295 and -2,147,483,648 to 2,147,483,647 signed. long is 64 bit with range 1.833E19 unsigned and -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807 signed. I need to get familiar with the qencoder code more and know why there is a 32k modulo. I know that float and double are discouraged in embedded. Maybe its a silly idea to use floating numbers where speed is important. Will changing INT to LONG impact performance a lot? :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
Re: qencoder / long / float / double / maximum values
On 6/8/2023 6:11 PM, Tomek CEDRO wrote: On Fri, Jun 9, 2023 at 1:53 AM Tomek CEDRO wrote: I am working on ESP32 (no FPU) and using Quadrature Encoder for motor control and range positioning. Current qencoder implementation stores counted values on int32_t so the maximum and minimum value is only around +/- 32k. I need far bigger numbers to be counted and available for readout quickly. Sorry its 2AM here and I sit too much in front of the computer with no fresh air :-P int is 32 bit with range unsigned 4.294E9 aka 4,294,967,295 and -2,147,483,648 to 2,147,483,647 signed. long is 64 bit with range 1.833E19 unsigned and -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807 signed. I need to get familiar with the qencoder code more and know why there is a 32k modulo. I know that float and double are discouraged in embedded. Maybe its a silly idea to use floating numbers where speed is important. Will changing INT to LONG impact performance a lot? :-) We don't normally use int or long types explicitly since these types are different with different tools or hardware. int32_t is always 32 bits wide, int64_t is always 64 bits wide and will be typedef'ed in include/stdint.h to the correct underlying type. If you have no FPU, have you considered using fixed precision real numbers. See include/fixedmath.h. They work well as long as the range of values is restrained.
Re: qencoder / long / float / double / maximum values
On Fri, Jun 9, 2023 at 2:22 AM Gregory Nutt wrote: > We don't normally use int or long types explicitly since these types are > different with different tools or hardware. int32_t is always 32 bits > wide, int64_t is always 64 bits wide and will be typedef'ed in > include/stdint.h to the correct underlying type. > > If you have no FPU, have you considered using fixed precision real > numbers. See include/fixedmath.h. They work well as long as the range > of values is restrained. TANK U SIR! :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
Re: qencoder / long / float / double / maximum values
On Thu, Jun 8, 2023 at 8:12 PM Tomek CEDRO wrote: > On Fri, Jun 9, 2023 at 1:53 AM Tomek CEDRO wrote: > > I am working on ESP32 (no FPU) and using Quadrature Encoder for motor > > control and range positioning. Current qencoder implementation stores > > counted values on int32_t so the maximum and minimum value is only > > around +/- 32k. I need far bigger numbers to be counted and available > > for readout quickly. > > Sorry its 2AM here and I sit too much in front of the computer with no > fresh air :-P > > int is 32 bit with range unsigned 4.294E9 aka 4,294,967,295 and > -2,147,483,648 to 2,147,483,647 signed. > > long is 64 bit with range 1.833E19 unsigned and > -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807 signed. > > I need to get familiar with the qencoder code more and know why there > is a 32k modulo. > > I know that float and double are discouraged in embedded. Maybe its a > silly idea to use floating numbers where speed is important. Will > changing INT to LONG impact performance a lot? I know it is sometimes unpopular to suggest adding more Kconfigs but maybe this is something that should be configurable, allowing developers to choose if they need a 64-bit count for range or a 32- (or even 16-) bit count for efficiency. The needed speed and counter size really depends on how the application is going to use the qencoder. Nathan
Re: Mailing List
On Thu, Jun 8, 2023 at 7:01 PM Sharwin Patil wrote: > Hello, > > I am a developer using NuttX and would like to be added to the mailing list > for NuttX development. > > Thanks! > Sharwin Patil > GreenSight > Great to have you! To subscribe, send an email to: dev-subscr...@nuttx.apache.org. Youll get a confirmation email; once you confirm by replying to that, you'll be on the mailing list. Similarly, if you ever wish to unsubscribe, just send an email to: dev-unsubscr...@nuttx.apache.org. We should probably update the NuttX website to document this process more clearly. :-) Hope this helps, Nathan
Re: qencoder / long / float / double / maximum values
On Fri, Jun 9, 2023 at 3:24 AM Nathan Hartman wrote: > I know it is sometimes unpopular to suggest adding more Kconfigs but maybe > this is something that should be configurable, allowing developers to > choose if they need a 64-bit count for range or a 32- (or even 16-) bit > count for efficiency. The needed speed and counter size really depends on > how the application is going to use the qencoder. Allright, mystery solved, the value returned is just a ESP32 specific register value (16-bit), according to the documentation this is mostly used for direction and speed decoding.. I will have to adapt it to a position value stored on a 32-bit or even 64-bit variable.. using floating numbers seems overkill.. thank you everyone for the hints! :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
Re: Mailing List
Email aggressively remove the sender from the reply list when sent to a list so they likely did not get this email. I was doing the same thing a couple weeks ago Added them to this one. Sharwin Patil hopefully you get this response from Nathan. --Brennan On Thu, Jun 8, 2023, 6:28 PM Nathan Hartman wrote: > On Thu, Jun 8, 2023 at 7:01 PM Sharwin Patil > wrote: > > > Hello, > > > > I am a developer using NuttX and would like to be added to the mailing > list > > for NuttX development. > > > > Thanks! > > Sharwin Patil > > GreenSight > > > > Great to have you! To subscribe, send an email to: > dev-subscr...@nuttx.apache.org. > > Youll get a confirmation email; once you confirm by replying to that, > you'll be on the mailing list. > > Similarly, if you ever wish to unsubscribe, just send an email to: > dev-unsubscr...@nuttx.apache.org. > > We should probably update the NuttX website to document this process more > clearly. :-) > > Hope this helps, > Nathan >
Re: qencoder / long / float / double / maximum values
The index signal (Z index) should be used to reset the encoder position. You can miss an encoder step for various reasons, and without periodically checking the absolute position (index pin), you will accumulate errors. Then, if you set the maximum count of an encoder timer to encoder resolution, the values [0, encoder_resolution] map to the position of the motor rotor. Your app should be responsible for handling zero position crossing and any calculation regarding the distance traveled by the rotor. There are ioctls to handle this (QEIOC_SETPOSMAX, QEIOC_SETINDEX) but ESP32 doesn't support them. pt., 9 cze 2023 o 05:22 Tomek CEDRO napisał(a): > On Fri, Jun 9, 2023 at 3:24 AM Nathan Hartman wrote: > > I know it is sometimes unpopular to suggest adding more Kconfigs but > maybe > > this is something that should be configurable, allowing developers to > > choose if they need a 64-bit count for range or a 32- (or even 16-) bit > > count for efficiency. The needed speed and counter size really depends on > > how the application is going to use the qencoder. > > Allright, mystery solved, the value returned is just a ESP32 specific > register value (16-bit), according to the documentation this is mostly > used for direction and speed decoding.. I will have to adapt it to a > position value stored on a 32-bit or even 64-bit variable.. using > floating numbers seems overkill.. thank you everyone for the hints! > :-) > > -- > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info >
