LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware - ARM (https://www.linuxquestions.org/questions/slackware-arm-108/)
-   -   ChronoDot (2.0) Project done! (https://www.linuxquestions.org/questions/slackware-arm-108/chronodot-2-0-project-done-4175705699/)

dodoLQ 01-02-2022 01:38 PM

ChronoDot (2.0) Project done!
 
3 Attachment(s)
Hi! That's started with a pb's form factor for the battery :scratch: The ChronoDot ordered (v2.0) needed an little small battery than the (v2.1)'s version, as in SARPi's mini-project page! Got an idea: (as i've a tons of CR2032 cells here :D), just ordered a socket for a battery cell and i'm happy with that choice!

Happy New Year guys! :party:

ps: you don't need to put an hwclock -s in rc.local, all is done in rc.S.

Exaga 01-02-2022 11:57 PM

Quote:

Originally Posted by dodoLQ (Post 6314223)
Hi! That's started with a pb's form factor for the battery :scratch: The ChronoDot ordered (v2.0) needed an little small battery than the (v2.1)'s version, as in SARPi's mini-project page! Got an idea: (as i've a tons of CR2032 cells here :D), just ordered a socket for a battery cell and i'm happy with that choice!

Happy New Year guys! :party:



Happy New Year. :D :party:

I changed the CR1632 battery in my ChronoDot v2.1 about 11 months ago, which had lasted approx. 8 years from new. I consider this to be very good battery lifespan.

From looking at your images, what you've got is a "ChronoDor" which is a Chinese clone of the ChronoDot. Although I've never used the ChronoDor, it looks very similar to the ChronoDot and features a DS3231SN controller. I believe the ChronoDor uses a CR1220 battery and ChronoDot uses a CR1632 battery, which leads me to assume that the battery life on the ChronoDor may be somewhat similar to that on the ChronoPi. I doubt for most users the quality and accuracy of the ChronoDor will be of any concern. The important thing is that it's a RTC and does the job. :)

A good idea for a battery holder is a CR2032 breakout board which is also available with an on/off switch.

Quote:

Originally Posted by dodoLQ (Post 6314223)
ps: you don't need to put an hwclock -s in rc.local, all is done in rc.S.

In '/etc/rc.d/rc.S' the hwclock if-then-else statements use 'hwclock --directisa' which is intended for ISA compatible machines such as x86, x86_64, and Alpha. For other machines it has no effect - see: 'man hwclock'. Users on the ARM platform may well find that they need to implement their own means and methods depending on their test-case parameters and hardware. Especially if (for example) a low quality or inaccurate RTC is being used that gains or loses several seconds per hour/day and the system has long uptimes and/or is not being (re)booted frequently. It's basically all down to each individual's requirements. Of course, '/etc/rc.d/rc.S' and '/etc/rc.d/rc.local' is only run at startup. The wonderful thing about Slackware is that it affords users the ability to do with it what they please and is ultimately configurable, and infinite in scope and possibilities. :thumbsup:

Code:

Manual page hwclock(8) line 224

--directisa
          This option is meaningful for ISA compatible machines in the x86
          and x86_64 family. For other machines, it has no effect. This
          option tells hwclock to use explicit I/O instructions to access the
          Hardware Clock. Without this option, hwclock will use the rtc
          device file, which it assumes to be driven by the Linux RTC device
          driver. As of v2.26 it will no longer automatically use directisa
          when the rtc driver is unavailable; this was causing an unsafe
          condition that could allow two processes to access the Hardware
          Clock at the same time. Direct hardware access from userspace
          should only be used for testing, troubleshooting, and as a last
          resort when all other methods fail. See the --rtc option.


dodoLQ 01-03-2022 01:14 PM

Thanks for replying Exaga :thumbsup: I'm surprised, didn't know about the existence of a chinese version.. And had a pb with a soldering point! Will check accuracy in time. Talking about hwclock, for you i should use hwclock -s in my rc.local? I forgot to say that i'm using the "dto" version's project. Good night ;)

Exaga 01-03-2022 11:53 PM

Quote:

Originally Posted by dodoLQ (Post 6314584)
Thanks for replying Exaga :thumbsup: I'm surprised, didn't know about the existence of a chinese version.. And had a pb with a soldering point! Will check accuracy in time. Talking about hwclock, for you i should use hwclock -s in my rc.local? I forgot to say that i'm using the "dto" version's project. Good night ;)

I very much doubt that the accuracy of the ChronoDor will be notably different from the ChronoDot, unless it's a bad one. I have quite a few RTCs using a cloned DS3231 controller and they've kept good time when I've tested them.

It's up to you what you do with rc.local or any other file(s), if anything. It's always prudent to do some testing and verify that the RTC is working as expected on (re)boot and then no further 'hwclock -s' commands are necessary. The ChronoDot RTC guide you mentioned to is 9 years old, was written for Slackware ARM 13.37/14.0, and still refers to a "disabling device-tree method", which I think is no longer used these days. So, the information in the guide is in need of a general overhaul.

Basically, with the ChronoDot (or any other DS3231 based I2C RTC) all that's required is to make sure it's wired up correctly and add or uncomment 'dtoverlay=i2c-rtc,ds3231' in the /boot/config.txt file, then reboot the system. Obviously users will need to consider their own setups and configurations in order to suit their requirements.

dodoLQ 01-04-2022 12:37 PM

Ok Doc Exaga ;)
hs: as you seen in my pics, i got the RBPi mouse but this one is not moving the cursor as expected under X.Org..
The move is not very reactive! I don't have this "pb" with a basic usb mouse (w/ my x86/x86_64 configs). Is the RBPi mouse a special device? Hope you understand :D

Exaga 01-04-2022 01:44 PM

Quote:

Originally Posted by dodoLQ (Post 6314949)
hs: as you seen in my pics, i got the RBPi mouse but this one is not moving the cursor as expected under X.Org..
The move is not very reactive! I don't have this "pb" with a basic usb mouse (w/ my x86/x86_64 configs). Is the RBPi mouse a special device?

The Raspberry Pi mouse is nothing out of the ordinary or requires special drivers, as far as I am aware. Then again, I am not a desktop user on Slackware ARM, but on the few occasions when I have used Xfce a generic USB mouse has always worked as expected.

mralk3 01-04-2022 03:27 PM

Quote:

Originally Posted by dodoLQ (Post 6314949)
Ok Doc Exaga ;)
hs: as you seen in my pics, i got the RBPi mouse but this one is not moving the cursor as expected under X.Org..
The move is not very reactive! I don't have this "pb" with a basic usb mouse (w/ my x86/x86_64 configs). Is the RBPi mouse a special device? Hope you understand :D

It could be that you just need to raise the mouse sensitivity or acceleration. You can do this from the system settings in KDE and in Xfce. The last step would be to create /edit the xserver configuration and tell the driver to increase those properties.

dodoLQ 01-06-2022 12:31 PM

Ok mralk3 :thumbsup:


All times are GMT -5. The time now is 04:06 AM.