207 Misc: Potpourri (207.html)
Keywords
ICH180RR Misc. Miscellaneous Qi "wireless chargers" "iPhone 11" X.509 HTTPS Certificates "Ad Hoc"
cuno Cunobelin Cymbeline "Old King Cole" mole daughter Imogen left breast cinque-spotted crimson
drops bottom cow-slip Vic Shakespeare "Universal Tap" IX_anyTapWto() IX_menu_i.py bootIP_i.py
"active menu" python-3.12.0 @asyncio.coroutine "python 3.12.0" active_state pull_up, pull_down
"N.O. Button" "Normally-Open Button" trigger Test_DownUp.py PUD "CD2 dongle"
"pull_up resistor" "active state" bounce_time timeout Button LED trigger push-button
isTrig vTrig iTrig pTrig nTrig prntTrig uTap() bootParms.txt iFolder myEmail SABRENT01
"apps in a" "Universal Tap" prepIX requires() "IX software" Test_show_A_i.py Test_show_B_i.py
BT BlueTooth ONN Slim mouse :101 "RPi 5 Serial Port"
GPT-4 XPS Copilot ChatGPT "Bing Chat" AI BARD OPENAI ChatBots "Generative AI" "Zero GPT"
Jasper Potpourri Ferret Coral.ai IP IP4 IP6
/Keywords
(To enlarge .....Click it)
IX or DC (IX by DC) or "|><"
This IX software is a part of the IX family of software that I use.
Introduction
This article is a collection of many varied small articles that probably don't belong in any other article.
Table of Contents
Article 207 Pot Pourri
Keywords
Introduction
Table of Contents
My Various Short Ad Hoc Articles
01. HTTPS and X.509 Certificates
02. Qi Wireless Chargers (for cell phones etc)
03. My Favorite Huawei Watch Faces
04. Old King Cole
"Old King COLE" aka Cunobelin aka Cymbeline
05. Some COLE/GOATCHER Family Anecdotes
Family Nicknames
Philip GOATCHER's Will
06 Booting, Universal Tap and IX_anyTapWto() [aka uTap()]
IP (IP4 & IP6) address of this Raspberry Pi
bootParms.txt
Algorithm to read an electronic RPi switch
gpiozero instead of RPi.GPIO
Virtual Environments in Python
Functions to Detect Triggers
Test_DownUp.py program
Tell Raspberry Pi OS to boot a specific program at BootTime
Using init.d to start up a program
07 IX Repositories
List of deprecated code and files upgraded for 2023AJan01
08 Regular IX Backups and Their External Storage
Changes to the IX folder structure
BEWARE: functions with default parameters
09 "dir", "ls" and "n" Terminal Commands
10 Automatic Creation of "Requires" Statements
11 python-3.12.0 @asyncio.coroutine not installed
12 BlueTooth Mouse Pairing Steps
13 Artificial Intelligence News
7 Steps Towards ChatGPT
14 The RPi 5 Serial Port
15 Thonny vs Python Issues
Thonny vs Python buffered print() difference
Thonny vs Python cannot send CLI parameters to Thonny
Sources
/End of Table of Contents
My Various Short Ad Hoc Articles
01. HTTPS and X.509 Certificates
Raspberry Pi menu has a submenu item "Help - File view" that can be used to view certificates. But where can I
find an example of a certificate to vew?
02. Qi Wireless Chargers (for cell phones etc)
Corded chargers will usually charge more rapidly. Qi is pronounced "Chee". The iPhone 11 can
be charged wirelessly or with a USB cord.
03. My Favorite Huawei Watch Faces
(To enlarge .....Click it)
Huawei watch face "sw06_en"
This Huawei watch can hold about 25 different "watch faces". The selected watch face is
what you see when you glance at it. The others are only a "tap" away. There are 9 ways
to see additional information. So much different information! The 9 ways are:
1 single click on the top right button
2 double click on the top right button
3 click on the bottom right button
4 scroll across the face left-to-right
5 scroll across the face right-to-left
6 scroll across the face top-to-bottom
7 scroll across the face bottom-to-top
8 tap the center of the face
9 tap on a "sensitive area" on the face
Most of these ways will provide a different sub-menu full of features.
Favorite Huawei Faces as of 2023JOct15
Name --Weather---- Health ----Exercise----- ---Times---- ------Other-------
BlackTie Date&Day&Sec (Steps, ) Lon
BS004 hPa Temp&HL Date&Day bpm (Steps,Sleep ) Mph/I Stress
CasioB5
Clear Temp Date&Day bpm (Steps, )
* FullDizaynTR hPa Temp Alti Date A/D bpm (Steps, ) Stopwatch Mph touchscreen
GoldTimes Temp Date&Day City Times
Jungle Temp Date&Day (Steps, ) M/S rise/set Zod
K65MX347 ? pulse
LightBulb ?
LightGold Temp Date&Day (Steps, ) Lon
MD252
* NightWish Temp Date&Day&Sec Sset Mph Stars
Red and Black Temp Date&Day bpm (Steps )
TriRing hPa Temp Alt Date kCal bpm (Steps,Activ,Hrs)
* IzzyAnalog002 FAV
* Simple module
* AU399g
* jwD112
I found a watch face that has almost ALL the functions available. They are:
FAVORITE FACE: IzzyAnalog002
-Pulse
- -Pulsing Heart
- -Graph
- -High & Low
- -Resting Rate
-Weather
- -Temperature
- - - Current
- - - Fut. High & Low
- -Location eg Piperville
- -Moon Phase & Illumination
- -Moon Rise & Set
- - Today & next 5 days
- - Moon Daily Cycle #
- Sun Rise & Set
- - Today & next 5 days
- Tide (if by the sea)
-Battery %
-Sleep (Hrs)
-Background Color Choice
-Km & steps
-Kcal burnt
-SWE (3 Exercise Measures)
-Analog Time AM/PM
-Month # and Date
-Notifications
-10 Fav. Phone #s
-WorkOut
- -Records
- -Status
-Heart Rate
- - Pulse & Graph
- - Zones
- - When Off Wrist
-SpO2 (Blood % Oxygen)
-Activity Records
-Stress Graph Measure
- -Current
- -High & Low
- -Latest Relaxed #
-Breathing Exercises
-Call Log
-Phone Contacts
-Music
-Barometer
- -Current
-Compass
-Stop Watch
-Timer
-Alarm
-Flashlight
-Find Phone
-Settings
- -Earphones (n/a)
- -Display
- -Volume
- -Vibrator
- -Do Not Disturb
- -Down Button Selection
- -Pin Code
- -WorkOut settings
- -System
- -About
-Drain (after swimming)
-Screen/Display- On
- - Brief / 5 min / Permanent
-Day of Week
-Name of WatchFace
-Phone
- -List of Previous calls
- -List of Missed calls
- -Can Make calls
- -Rings & Vibrates
- -Talk & Listen
- -Missed Calls
- -Record msgs on Answering Machine
04. Old King Cole
Coins (as shown above with the Latin label "cvno" on one side and "tasc" on the other side) are the only known images of "Old King Cole" (aka Cunobelis) and/or his father Tasciobanus. They lived and ruled in pre-Roman Briton (near today's Wheathampstead, St Albans and Colchester) around 30 BC to 40 AD. Shakespeare's play "Cymbeline" also reveres "Old King Cole". The coat of arms for Cole is a black bull (shown above right). Is it a coincidence that Tasciobanus used a bull as the emblem on his coin?
"Old King COLE" aka Cunobelin aka Cymbeline
Ancient grave may be that of Old King Cole by UPI 1992 B Feb 24 LONDON --
Archaeologists who found a 2,000-year-old grave of a Celtic ruler near ancient Roman ruins hope to learn whether the remains may be those of Cunobelin, also known as Cymbeline or Old King Cole. The grave was found at historic St. Albans, 20 miles north of London [ Ed Note and only 5 miles southwest of WaterEnd Farm. In Roman times, St Albans was called Verulamium. The "5 mile long very straight" connecting roads from today's Verulamium Park to WaterEnd Farm are called Sandridge Road, St. Albans Road, Coleman Green and finally WaterEnd Lane. For more info see Source 02.] The site, which was covered over shortly after the Roman conquest in 43 A.D., lies near the ruins of the Roman city Verulamium, which was burned by Boadicea, the Celtic woman warrior, about 60 A.D. Tests were under way to determine whether the remains are those of Cunobelin, believed to be the nursery rhymes merry old soul who is also believed to be the ruler known as Cymbeline in Shakespeare's play of the same name, a Verulamium Museum spokeswoman said. The grave, which overlooked the vanquished Celtic town of Verlamio, dates to between 20 A.D. and 40 A.D., about the time Cunobelin died. The burial site may have been dedicated to Cunobelin's father, ruler of the Catuvellauni tribe, or another chieftan, dig director Roslind Niblett said. The candidates include Androcus, an early first-century ruler of the Catuvellauni, and his co-ruler, Tasciobanus, who was the father of Cunobelin, Shakespeare's Cymbeline and the Old King Cole of nursery-rhyme fame, Niblett told The Times. But archaeologists suspect the grave may actually be that of Cunobelin, who made his capital farther north at Colchester on the Colne River, about 50 miles north of London. It seems more likely to be a contemporary of Cunobelin, whom one would expect to find buried at Colchester, but it is possible that Old King Cole himself was brought back to St. Albans for burial, Niblett said. The cremated remains of the king were clad in a chain-mail shirt and surrounded by treasures, some made of silver and ivory, and placed in the largest Iron Age tomb found in Britain, The Daily Telegraph said Saturday. The royal tomb, which was found this month on a hospital's grounds a week before the site was to be turned over to a housing development, was at the center of a wooden funerary complex that covered almost 4 acres. The remains of the king were found on a wooden bier within a deep pit enclosed by a wooden building piled with ritually smashed plates, cups and wine containers. Appropriately for Old King Cole, who, so children recite, called for his pipes, wives and fiddlers three, the grave was reached by an entryway strewn with what appear to be sacrificial burials -- including three human skeletons. Source
Also see Articles 68 and 69 about Princess Helena COLE, the daughter of Old King Cole, by the author, David COLE.
05. Some COLE/GOATCHER Family Anecdotes
My father, Vic COLE, in a parody of scholarship, would sometimes cite this short passage from Act II Scene ii of Shakespeare's Cymbeline:
On "Imogen's" left breast, a mole cinque-spotted, like the crimson drops I' th' bottom of a cowslip.
(Imogen was the daughter of King Cymbeline of Colchester, England. Many say that Cymbeline portrayed "Old King Cole"
and his daughter Imogen portrayed Helena. The 1000 year old church still in use in Wheathampstead is named St. Helen's)
Vic COLE's mother, Florence nee KINGSLAND COLE (and her grandson David COLE), have the "Kingsland mole". This mole is situated between the left eye and the nose, approximtely 1/2 inch from both.
Another of Vic's favorite sayings was "This is the day that the Lord has made, let us rejoice and be glad in it. (Psalm 118:24)".
Family Nicknames
Occasionally, we would hear Vic say "My Goozeberry" or "Medianne", which were his nicknames for our mother, Marion nee GOATCHER COLE. Vic would say "Gooseberry" with a Cockney accent. His father Charley Cole was raised near London, Charley's grandfather most certainly spoke Cockney English. In Cockney rhyming slang, "Gooseberry Pudding" rhymed with (and therefore meant) "woman" (Source 03) . In her absence, our maternal grandmother, Daisy nee SULLIVAN GOATCHER, was "Granny Groucher" and our mother's aunt, Annie E. GOATCHER, was "Aunt Banana" (but I don't know why). Chuck's friends sometimes called him "Pedro" and Christine was "Biscuit", short for "Christie Biscuit" while David was "Nip", "Nipper" or "The Little Nipper" even before he was born. Once David became a teenager, Vic made every effort to call Nip by the name of David. Today, in 2023, the only person using my nickname of Nip is my sister, Christine. Vic's nick-name for his "foster" older brother, Arthur (Art) Noel WOOLGAR, was "Doc". Why "Doc"? Well as a child, Vic had such bad asthma that he often needed an injection of adrenaline. He always preferred that Art give him the needle, so he called him "Doc". The name that our cousin, Keith PAUL had for his brother, Donald (Don) PAUL, was "Louie". Our aunt, Doris nee GOATCHER REDMOND NORTH, was "Aunt Dot". Our cousin, Hazel nee REDMOND HOPWOOD, was "Little Hazel" to distinguish her from our "Aunt Hazel" who was Hazel nee GOATCHER HIBBARD. The wife of uncle Jim GOATCHER was Margaret nee GILBERT GOATCHER, known to us as "Aunt Peg". Vic's two aunts in England were "Doll" and "Ethyl". "Doll" was Gladys Elizabeth nee KINGSLAND YEO. They were sisters of my grandma Florence nee KINGSLAND JOHNSON COLE. I never ever heard her mention anyone named JOHNSON, even though her first husband was named Herbert Edward JOHNSON. Her second husband, Charles Percy COLE was known to his friends as Charley. He called his wife "Flo". Ethyl's full name was Ethyl Louisa nee KINGSLAND BROWNING with no nickname. Our mother had an uncle William Noel GOATCHER (born a few days before Christmas). who was called "Willie". He changed his name to Christopher GAUTHER when he moved to California to evade the Canadian Police. He had a total of 3 wives without bothering to ever divorce the first two wives. The real name of aunt Jess was Jessie nee GOATCHER GODWIN LILOF, but her nom-de-plume for her autobiography was Jessica GODWIN. She once showed me a photo of Willie's three wives. When I asked who took the photo, she replied "It must have been Willie". Willie had a son named David GAUTHIER who lived in California, so there wasn't only one David in the family. Before David's born, his mother had decided to call him Casey, but after he was born, she thought that he didn't look like Casey. So she named him David Kenneth Charles COLE, the KC remaining as middle initials but David never had the nickname Casey. Vic's full name was Victor Charles COLE because he was born shortly after the Allies' victory in WWI which older people called "The Great War". He was born at home (not in the hospital) because it was during the Spanish flu epidemic of 1918. David's family dog was named "Rover" which was less appropriate after it lost a leg. After the loss of one of its hind legs, Rover often tried to (unsuccessfully) "lift" the remaining leg in order to pee. Then he would turn around to pee facing the other way. Vic's black pet dog was named "Nig" which would be totally inappropriate today.
David calls his group of software programs "The IX Family" whose "IX" can be seen as "DC" if written cursively. Furthermore "David Cole" has 9 letters in it (which is "IX" in Roman Numerals). David's on-line alias is "KoldAdvice" (an anagram of DavidKCole) or "D@CC" (which abbreviates his email address: "David @ ColeCanada.com"). David's facebook persona is Arthur (Art) GOATCHER (1920-1922) who, in real life ,was his mother's slightly older brother who died in infancy. By accident, the address of our Florida condo (in 2023) is 180 which Electronic Engineers recognize as Pi ( π ). David's favorite small computer is the inexpensive Raspberry Pi, developed and built by a Britain named Eben Upton circa 2010-2013. David's first Pi-centered process control device (that measures the environment of an area in a home) is called PiR2 because that is the formula for the area of a circle. Also, by accident, David's Ontario automobile licence plate is "CDPR413" which (he tells people) means "CarD PlayeR 4 x 13), which is reminiscent of Duplicate Contract Bridge that his wife, Yvette, and Dave play whenever they can. David has created his own format for the date (e.g. 2023JOct21) which computers have no difficulty sorting correctly (and humans can easily read without error). David still hangs onto the username, "DavidCole3", which was (and still is) his original AOL email name. David's personal web page "www.ColeDavid.com" was created during the infancy of the Internet when "ColeDavid.com" was still available. David created the webpage "www.VicCole.com" for his father to use, which remains alive in memorium to his father.
David's paternal grandfather, Charles "Charley" Percy COLE [FSID: L69G-P3X at the free genealogy site: www.FamilySearch.org ], was born and raised in an ancient farmhouse called "WaterEnd Farm" (or "Water End Farm") still extant in 2023, located a mile East of Wheathampstead, England on WaterEnd Lane which is a few miles North-east of St Albans. Perhaps fittingly, his "Grandad COLE", died of cancer of the bladder (bladder being the beginning or end of water meaning urine). Among Charles' papers, the postcard (shown below left) was discovered. An old friend had written on it "I should like our house on a postcard. You know this one." before mailing it to Charley. David wistfully thinks that the man in the doorway was his great-grandfather James William COLE (1851-1923) who rented, but alas didn't own this house. This farm was constructed hundreds of years ago on the North bank of the "River Lee" where a very ancient Roman road could ford the river. Historians say that Old King Cole may have lived in this area thousands of year ago (as mentioned earlier).
Up until about 100 or 200 years ago, the River Lee was not very deep, ever since Roman times, 2000 years ago. The Lee was so shallow that it was very easy to ford the river at WaterEnd. That is probably why this particular part of the River Lee was called "WaterEnd" and the lane crossing it was called "WaterEnd Lane". Well, about 150 years ago, the Earl of Cowper (pronounced "Cooper") rebuilt his manor house near WaterEnd. He decided to construct a small scenic lake in front of his manor, so he built a small dam to contain the water from the River Lee, which raised the level of River Lee considerably. As a result, today, a small bridge is now needed to cross the River Lee at WaterEnd.
It was Vic COLE's cousin, Les COLE, who first took the author, David, to see WaterEnd house in 1964. This was the author's introduction to genealogy. Les COLE had only one daughter, Ann COLE. She provided David with a huge COLE family tree on paper. It measured about 5 feet by 5 feet and was a treasure trove of genealogy information for the COLE family.
David's maternal grandfather, Philip Richard GOATCHER, wrote his will in the form of a poem (shown below):
Philip GOATCHER's Will
If I should die before my wife,
she gets the savings of my life;
No matter what these assets be,
cash, bonds, war savings, property-
If latter is a nuisance sore,
Sell it and of cash have more..
This includes my farm and shack,
and stamp collection, but alack!
They are in such a poor state
they'll scarcely lure her a new mate..
I hope she'll get the best price ever,
I guess she will as she's quite clever..
If she is gone, just children left
and they are of their Ma bereft,
They each and all get equal share
of anything there is to spare..
If any die before I do,
Then same thing goes though only two..
If only one survives her Dad,
she's welcome to just all he had...
Transcribed: Wed Nov 22 1989
I sometimes wonder if it was providence (not coincidence) that my grandfather's middle name was "Richard" and my wife's maiden name was also "Richard".
06 Booting, Universal Tap and IX_anyTapWto() [aka uTap() ]
Every Raspberry Pi computer or microcomputer (except a bare compute module 4) has a means of communicating to the user. This is often a simple
on-board LED. (It should be noted that every bare Raspberry Pi computer has no means for the user to tell the RPi what to do,
no push-buttons exist. (Even a simple CD photo-cell would be nice to have.) The uTap(. . .) function is used to wait for a time-out period
while watching for a tap before each task is initiated. In the future, more actions (the last four listed below) will be possible in addition to the other taps:
This IX_anyTapWto function (or its short name: uTap) waits for any input from the user. Within the time-out period (timeOut), the user can
respond in any one of many ways. The time-out period: "timeOut" which is defined in the input parameters, is normally 3.14 to 10 seconds. The methods of response are any of the following:
- tap or press any push-button switch connected to a GPIO pin
- tap or cover any CD2 dongle (one or more CD photocells in series)
normally connected between physical pins 38 and 40
which are GPIO20 and GPIO21.
(To enlarge .....Click it)
CD2 Dongle©
- tap or cover any CD photocell connected to a GPIO pin
- tap a penny, coin or metal object (any tool?) to physical pins 38 and 40
- tap the male end of a dupont wire to physical pin 40, while
the female end is connected to physical pin 38
- tap or depress the "joystick" on the Wio Terminal (future)
- tap the Left mouse button [left mouse-click: Source 04](future)
- tap any key on a keyboard (future)
- tap a microphone or whistle, or say "No" into it (future)
The author calls any of these above responses a "Universal Tap". Such a tap allows a user to optionally respond or communicate in
any one of a multitude of ways (listed above) with a Raspberry Pi using any one of many possible input mechanisms. The only universal
tap not requiring the handling of a physical object is when a microphone is available and is used. (A keyboard, mouse or any input device connected
via Bluetooth would also be wireless of course.) Touching a CD2 dongle plugged into physical pins 38 and 40 is the recommended
way to respond. Touching a non-live metal tool, a penny or any other coin between these 2 physical pins is also often possible.
IP (IP4 & IP6) addresses of this Raspberry Pi
There is one especially welcome action when a bare Raspberry Pi is powering up. If it is running headless (without mouse, keyboard or monitor),
the user will often want to control the RPi using a remote desktop (eg RDP on a nearby Windows laptop) presuming that it is connected
to a common router. But to do so, the user needs to know the IP address of the Raspberry Pi. To learn the IP address, the author
has written a "boot program" called boot_activeMenu_v00_i.py (Source 16) that "tells" the user the IP address. Upon start-up, this program blinks
a (usually on-board) LED to inform the user of the IP address. (This is also done every time the active menu begins a new loop.) The user usually
knows the left-most digits of the full IP address (eg 192.168.1.148) of another device that is using the same router. Source 22 describes
many ways to "read" the IP address of a Raspberry Pi. As of 2024, the IP4 address is still being used, but use of the IP6 address if becoming
more and more useful. The IP6 address is too complex to blink. For this reason, both the IP4 and IP6 addresses are sent as data in the "boot-up"
email that is sent at boot time.
Upon booting, the boot_activeMenu_v00_i.py program identifies itself by first blinking "3.14" . This is done by blinking 3 short blinks,
one long blink (for the decimal point) then 1 short blink then 4 short blinks. This is known as "blinking a pi". Any Raspberry Pi
user will soon learn to recognize this. Then the program blinks the 2 right-hand numbers of the IP. For the IP address mentioned
previously, this would be a long blink, 1 short blink followed by a long blink, 1 short blink, four short blinks, then finally 8 short blinks.
It's as easy as that. All subsequent times through the loop, the full IP address will be communicated instead.
Whether or not the user will run the Raspberry Pi in a headless manner, the boot_activeMenu_v00_i.py program will next display (and/or attempt
to beep) the remaining tasks of the following simple active menu on the screen (visible or not):
boot_activeMenu_v00_i (within a few
secs, tap to skip any submenu task.)
------------------------------
1 blink_IP_tail_i:
2 tap_Quad_Demo_i:
3 send_boot-alert_info_i:
4 boot_msg_i:
This_is_the_text_Msg
5 boot_i:
6 help_Loop_i:
It is to be noted that, after any boot (or reboot, such as after a power outage), an unattended Raspberry Pi will eventually start
running all the listed tasks (including the boot application numbered 5 above). No more is needed for the Raspberry Pi to boot using the boot program named "boot_activeMenu_v00_i.py".
The boot program (named boot_activeMenu_v00_i) then gives the user an opportunity to run or NOT run each of the subprograms (called tasks) on this tiny menu. A detailled explanation of this whole boot process follows:
Before this menu is displayed, the boot program will "blink a pi" asking the (human)
user (aptly named pi) to get ready to respond. Then the first submenu task will be highlighted showing that it
will be run next. It will be accompanied by a single blink indicating the first task. If the user doesn't respond within 3.14 seconds,
the first submenu task will be run. The first submenu task will
soon blink the last two numbers of the IP address (as described above). If the user responds with any one of the universal taps,
the current highlighted submenu task will be skipped; then the next (second) submenu task will be highlighted awaiting a user response.
As each task is highlighted, its task number will be blinked (and will also be sounded audibly if possible). For example, task #3 will be
announced by three blinks (and/or 3 beeps). If a buzzer or audio output is available, it will be used to sound the beeps. If not, at
least the number of "blinks" will be seen on the blinking LED (often it is the on-board LED). In this manner, the user can select to run a
submenu task by NOT doing a single universal tap for each submenu item. A single universal tap will skip the highlighted upcoming submenu
task. While each task is highlighted for a few seconds, a universal tap will speed up the active menu by immediately highlighting the next
task without running the current highlighted task. Task two is a request for an optional demo of the universal tap. If the user is present
and chooses to demo his desired universal tap, he/she is invited to do so as follows:
The user should understand that this demo tap (if done) will influence the program in a major way. The influence is that, after the demo
tap, the program will stop watching for ALL universal taps and will ONLY watch for this particular demo tap in the future. This task is
named "tapQuadDemo_i" because the user is expected to tap exactly four times. If this tapQuadDemo_i is recognized by the active menu,
four slow blinks (and 4 slow beeps) will occur. The slow blinks and beeps are done at long (1 second) intervals.
Tasks 3,4 and 5 will be described below, but first, the last task will be described.
The last task listed (in the absence of a tap) will normally loop back to the top of the menu. When this menu item appears,
a tap will NOT skip this menu item (will NOT skip this task). For this last task only, a tap does NOT mean to skip this task entirely.
When this menu task runs, before looping back to the top of the menu, as its name (helpLoopNotExit) implies, the following actions will
occur:
-a help menu will be displayed
-it will loop back to the top of the menu
At this point, the timing of a tap is very important:
-while the task name is first highlighted: a tap will skip this task and the top menu task will be run next
-then while the help information is displayed: a tap will give the user a special opportunity to exit from the menu
-no tap at all: will cause the top menu task to be run next (called looping up to the top of the menu).
The "special opportunity to exit" from this active menu is very easy to notice. If this opportunity is taken, the active menu will
stop and will shut down (power off) the computer. If the user does tap during the "helpLoopNotExit_i" submenu task, the menu will
stop displaying the help information shown below, and then will display a triple blink (and a triple beep) which signals the special
opportunity to exit.
If the user replies to the triple blink/beep with a triple tap, the active menu will stop functioning and the computer will power off.
Any other tap or no reply to the triple blink/beep will be ignored and the active menu will continue looping. Other than providing
an opportunity to quit looping, this last task will simply display the standard help message and then loop around to the top task
invoking each submenu task again, repeating the whole menu.
Note that this menu is truly an ACTIVE menu. By "ACTIVE" it means that this menu will invoke each of the sub-menu tasks in turn,
unless the user responds with a tap (a tap will ignore each current highlighted submenu task). The net result is usually that the
second last submenu task will invoke an application. This application will usually run continuously, but can, of course, terminate
or be terminated. For this application to run, each of the previous submenu tasks on the active menu should always return control
to the active menu, when it has completed its function.
The help information shown below is always displayed during the last task of the active menu.
ACTIVE MENU HELP
Read, then patiently wait to allow this help message to disappear.
A universal tap is any one of the following:
CD2 Dongle tap, photo-cell tap, push-button tap, "short" physical
pins 38 and 40, (any future enter key, mouse click, loud "No").
An active menu is the opposite of a normal passive menu. A normal
passive menu displays a list of submenu options from which the user
can choose one to be run. No task runs until the user selects a
subtask to be run. This active menu is the opposite. It runs all
of the subtasks in the absence of input from a user. An active
menu usually continuously runs each of the submenu options, one
after the other. An active menu is often used to invoke a major
application task located near the end of the menu. If the user
furnishes a "demo tap", this particular tap will become the only
tap accepted. In the above example, two application tasks exist.
The "send_boot_alert_info_i" task will be invoked to send a boot
alert email and to transmit any accumulated PiR2 logs to their
website. The boot alert email will be sent to myEmail as specified
in the bootParms.txt file. Task # 5 is the main application for
this Raspberry Pi computer. Task #2, allows the user to select
his/her favorite tap by demonstrating it. This single tap will
replace all universal taps for all future functioning of this
active menu, until the next boot.
This help routine will return to the active menu in 15 seconds.
/END OF ACTIVE MENU HELP
This active menu may seem to be somewhat convoluted or difficult to navigate. This is because it is designed to be controlled by the timing
of a single response, usually a tap of an object. This is the style of simple default menu used on most of the author's Raspberry
Pi computers.
As shown below, the uTap(pyBoot,timeOut,gpioLED,iSwitch,iAudio,iMsg,boot_i,outputCLI,myEmail,storedIn) function accepts 9 parameters. Each of them can be null. The first parameter, named pyBoot is the name of the first Python program that will be run. If null, it defaults to "/home/pi/Desktop/IX_activeMenu_i.py". This is the program that should be specified in the /etc/init.d/ folder as described as the "example" in Source 11 below. The next parameter is the tap time-out period which, if null, defaults to 3.14 seconds, the next parameter is the GPIO pin to which the blinking LED is connected, that defaults to the on-board LED, the next parameter is a number or a list or null. If a number, it is the only GPIO number to be examined for the universal tap device, if a list, it is the list of the various GPIO numbers of the available tap switches, if this parameter is null, it is the fullest possible list of devices that can be used for a response. In the latter two cases, the user can select his/her preferred universal tap device by responding to the tapQuadDemo_i task. The next parameter is the GPIO number of the audible buzzer to be used for beeps, if one exists or null. The next parameter (boot_i) is the shell command (.sh) or Python program (.py [future]) used to start up the first application. If it is invalid, does not exist or is null, no application will be started. The next parameter (outputCLI) is the file where the displayed results of the boot_i should be temporarily stored. If null, the results are displayed directly to the screen. The next parameter is the email address (of the person) to be notified that the RPi is booting up. A valid email address must not contain any spaces. An invalid email address will result in no additional emails being sent. If null, or on subsequent loops, no email is sent. The last parameter indicates where the bootParms.txt file should be stored. Note that uTap() uses the actual GPIO numbers, not the physical GPIO pin numbers. These parameters should be stored in a file named bootParms.txt in the /home/pi/Desktop/a/boot/ folder. Any invalid parameter will default to null. If the bootParms.txt file is not found, every parameter will default to null. This file is designed to permit it to be grepped. Of course, it can be modified by the user. If the pyBoot parameter is changed, the /etc/init.d/ folder must also be changed etc. The special system command to register the init.d boot program with the Raspberry Pi OS is:
sudo update-rc.d example default
Note that TWO DIFFERENT text files are needed for the example in Source 11 to work. They are: the first file "/etc/init.d/example" and the second file "/home/pi/example.py". The instructions in Source 11 work if these two files have the same first name. Beware if these first names differ. In the IX case described here [in article 207], these two names should be "boot_activeMenu_v00_i" and "boot_activeMenu_v00_i.py" The second name is stored as the first parameter of bootParms.txt simply to document that this name has been registered appropriately with the Raspberry Pi OS system. To stop the example boot program from being used at all future boot times, run the following command:
sudo update-rc.d example remove
or, to stop the boot_activeMenu_v00_i program from being used at all future boot times:
sudo update-rc.d boot_activeMenu_v00_i remove
bootParms.txt
The suggested contents of bootParms.txt are shown below:
boot_py /home/pi/Desktop/a/boot/boot_activeMenu_v00_i.py
timeOut 3
gpioLED ""
iSwitch 21
iAudio 26
iMsg This_is_the_text_Msg.
boot_i /home/pi/Desktop/IX_assets/CPU_temp.sh
outputCLI ""
myEmail userName @ gmail.com
storedIn /home/pi/Desktop/a/boot/
/bootParms.txt !
As can be seen above, the main application that will be started is a simple default routine that displays the temperature of the processor in the Raspberry Pi computer. This can be easily changed by the user. The coding of this boot system named "boot_activeMenu_v00_i.py" is
currently in progress as of 2023LDec24. Phase 1, when complete, will include all the universal taps (except those shown as "future" in the list
after the heading "Booting. . . " in this article. The application invoked upon booting will be CPU_temp.sh (not pir2.sh). This boot
system is designed to run under phython3, not python2.
On 2023LDec15, the boot_activeMenu_v00_i.py program was run in a Raspberry Pi Terminal window with the bootParms.txt file shown above. This
active menu Boot program ran a single subtask without incident. Note that the CPU_temp.sh task did not return control to its
calling program. Only 1 subtask (number 5) appears on this early menu. The output from an actual run (without any universal taps) is
shown below. Note that the 1 statement /home/pi/Desktop/IX_assets/CPU_temp.sh bash script (containing merely "/usr/bin/vcgencmd measure_temp") succeeded in displaying the CPU temperature in the Terminal window, upon booting, as shown below.
boot_activeMenu_v00_i.py within a few
seconds, tap to skip any submenu task
-------------------------------------
5 boot_i:
running
>$sh /home/pi/Desktop/IX_assets/CPU_temp.sh
end of boot_activeMenu_v00_i.py
temp=53.0'C
This demonstrates that the main job of the boot_activeMenu_v00_i.py boot system is operational. Any bash script could have been invoked.
Coding is on-going. The source code of some of these modules has been made available to the public as of 2024AJan06.
Algorithm to read an electronic RPi switch
This verbose read algorithm named "CSEQ" is given 6 parameters:
parm1: the GPIO number (not phys #) of the switch to read, but
0 means the on-board LED
parm2: a number which is the sensitivity of the algorithm
eg 3 which for CSEQ is the limit (higher:very sens)
eg -3 resets the switch by setting N=3 ie the limit.
It does multiple immediate reads until N consecutive
readings agree, sets ctr to +/-3 and latches
(NB this prevents a spike from a noisy switch)
Over 50 different readings raises an error.
parm3: a name assigned to the algorithm used.
eg "CSEQ" means limit of 3 consecutive unchanged alt.
readings latches (changes) the result, any latched
reading resets the countdown counter
(any latch to High or repeat High sets cnt to +3, any
Low counts ctr down to +2 etc, when 0 it latches Low)
parm4: the counter (so the calling program can monitor performance)
+2 means that the switch was high three times then low once
0 means that the switch value is unknown (or error raised)
-2 means that the switch was low three times then high once
parm5: True if the switch state was latched (changed) by this call
parm6: the unix time if the latch changed during this invocation
Returns: the result of the latch isHighA which is either True or False
sample call for switch A ("V" suffix means verbose)
A=21 #GPIO # of sw to read
isHighA,swCtrA,isLatchedA,tChgA=inSwV(A,3,"CSEQ",swCtrA,isLatchedA,tChgA)
Note 1: when a good algorithmn has been established, a simpler call will suffice:
isHighA,swCtrA,isLatchedA=inSw(A,3,isShow) # if isShow is True displays verbose info
Note 2: To immediately read the current state of the switch
isHighA,swCtrA,isLatchedA,tChgA=inSwV(A,-3,"CSEQ",swCtrA,isLatchedA,tChgA)
or
isHighA,swCtrA,isLatchedA=inSw(A,-3,isShow)
The following code statements initialize switch A, then report its value changes:
A=21;isShow=False
isHighA,swCtrA,isLatchedA=inSw(A,-3,isShow) #initialize A
isLatchedA=False
while not isLatchedA :
isHighA,swCtrA,isLatchedA=inSw(A,3,isShow) #read A
# ignore swCtrA and no error checking
if isLatchedA :
if isHighA :
print("switch:",A," is now High.")
else:
print("switch:",A," is now Low.")
#if end
else:
pass
#if end
#while end
gpiozero instead of RPi.GPIO
Since around 2023KNov01, I have been using the 32 bit "bookworm" OS on an RPi 4B, but "import RPi.GPIO" will not work on the Raspberry Pi 5
(RPi 5B). It is recommended that we use a relatively new "import python3-gpiod" on the RPi 5B. Also physical pin numbers cannot be used on
the Compute Module 4, which I have begun to experiment with. Considering this, I will begin to use the "import gpiozero" routines (See Source 06 and Source
07), which work well on "old" RPi computers, the RPi 5 and the Compute Module 4 with GPIO pin numbers. Two sample Python programs using "import
gpiozero" follow:
#Test_gpiozero.py
#Status: tested, working
#Repository: /home/pi/Desktop/a/sandBox
#By: D@CC on 2023LDec16
#Environ: RPI 4B 32 bit bookworm OS
#Aux Device: Cytron MAKER pHAT
# where Buzzer is LED(26)
#Using: GPIO pin #s
# toggle phys. pin / GPIO pin numbers using GPIO_PIN_FACTORY
#From Article Source S207:06
from gpiozero import LED, Button
from signal import pause
#help: man -k signal
ledB = LED(19)
ledB.on() #LED at 19 is always on
#ButtonB=Button(6,pull_up=False)
# pull_up=False means pull_down=True
led = LED(12)
button = Button(16)
button.when_pressed = led.on
button.when_released = led.off
pause()
or
#program 2
# untested by D@CC
from gpiozero import OutputDevice, MotionSensor, LightSensor
from gpiozero.tools import booleanized, all_values
from signal import pause
garden = OutputDevice(17)
motion = MotionSensor(4)
light = LightSensor(5)
garden.source = all_values(booleanized(light, 0, 0.1), motion)
pause()
# end of Python code
More information about gpiozero can be seen at Source 06 and Source 07.
. . . . Virtual Environments in Python
In Source 10, Patrick at "Raspberry Tips" provides an introduction to Virtual Environments which
are required instead of "import RPi_GPIO" on the Raspberry Pi 5.
Functions to Detect Triggers
See Section § 13.1.1 Button [Class]
of Source 06 for information about detection of pulse rising or falling (aka triggers) and special timing considerations.
Topics like pull_up resistor, active state, bounce_time, timeout etc are described. [Ed. Note: pull_up=False
causes an internal pull_down resister to be used.] A few Python event functions can be triggered. They (and some
other useful functions) are:
EVENT FUNCTION: DESCRIPTION
.when_pressed negative trigger (downwards; voltage falling)
.when_released positive trigger (upwards; voltage rising)
.when_held button active for longer than the "hold_time"
IX Trigger Controls
IX Global Variables Description
isTrig trigger boolean switch True=On (recording)
vTrig[] trigger vector (first element is unix 0time,
subsequent elements are the time intervals
between voltage swings)
IX Functions Description
iTrig() reset Trigger Controls (initialize function)
nTrig() negative trigger event interrupt function*
pTrig() positive trigger event interrupt function*
prntTrig(vTrig) ^C will print out the current trigger vector
* Note event handlers do not need to "return"
DESCRIPTION:
Normal Default Situation: Connect one side of a normally-open push-button
to a Ground pin, the other side to a GPIO pin (often GPIO21). This is called:
active_state=FALSE.
The related code automatically connects an internal pull-up resistor from the
GPIO pin to the HIGH voltage. (Until the button is pressed, the GPIO pin is
held HIGH by this internal pull-up resistor.) When the button is depressed,
the button is said to be in its "active_state". When the GPIO pin goes LOW
(in its "active state"), this causes the software value to go HIGH (True).
[Ed. Note: All RPi GPIO Pins (except GPIO 2 and GPIO 3 have internal
pull-up-down (PUD) resistors. Beware: GP3 (physical pin 5 is mistakenly
labelled GND in the "Full Colour LED" wiring diagram in Source 06. This
is probably a sloppy re-use of the LED and BUTTON images above and below
(where GND is a label with a dotted line to physical pin 6, not to phys
pin 5.) All of the GP pins should be labelled GPIO eg GPIO3 instead of
GP3. GPnn number labels should only be used for the Raspberry Pico.]
Test_DownUp.py program
See Source 08 for the short Test_DownUp.py program (only 27 Python statements) that
successfully uses the above routines.
It can produce the following output (capturing rise/fall times in msec):
progName: Test_DownUp
watching GPIO: 21
udud
^C: cntTrig: 5
vTrig: [1702871616.7199683, 4.637, -4.659, 5.146, -5.162]
This output means that the switch on GPIO 21 was monitored. Monitoring began at the date/time corresponding
to unix time 1702871616 which is 2023L Dec 18 at 3:53 am GMT. After 4.637 seconds, the switch voltage rose,
because the normally closed switch was pressed allowing the voltage to rise.
The negative value of -4.659 means that .022 seconds later it fell. The 5.146 means that it rose again
within 1/2 second and fell only .016 seconds later. The letters "udud" mean that the program interpreted this
as the sequence: up, down, up, down. Cntrl-C was then hit to stop monitoring and to print out these results.
The cntTrig of 5 indicates that there were 5 elements recorded in the Trigger vector which is a global Python
list named vTrig. The code for this full Python program, its functions and the names of the gpiozero imports
can be seen in Source 08.
Tell Raspberry Pi OS to boot a specific program at BootTime.
Source 09 describes 5 ways to tell the Raspberry Pi to start a specific Python program at boot-time. The five
ways are:
-
rc.local
-
bashrc
-
init.d directory (used by the IX Software)
-
SYSTEMD
-
crontab
The init.d method is preferred for 2 reasons: the desired boot program can be the "last" program to be
run during boot-up and it only needs minor edits of special system files.
Using init.d to start up a program
The following code from Source 12 might work:
#! /bin/sh
#
### BEGIN INIT INFO
# Provides: pitracker
# Required-Start: $all
# Required-Stop:
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Track pi.
# Description: This service is used to track a pi.
### END INIT INFO
HOME=/home/pi
USER=pi
case "$1" in
start)
echo "starting pitracker"
su 'root' -c 'python3 /home/pi/python/main/myprogram.py&
;;
stop)
echo "stopping"
;;
esac
exit 0
As of 2023LDec20, the above code has NOT yet been tested.
A second (very simple but very detailled) init.d example (probably c++ code that invokes a Python program? ) by Pi Hut can be found in Source 11. I believe that it worked well when it was created in 2018.
07 IX Repositories
The webmaster (D@CC) has endeavored to limit the number of folders that are used by the IX modules on a Raspberry Pi computer. It is preferred that this list of folders be longer instead of the depth of folders being longer. The number of folders in Desktop is kept to a minimum to avoid a "cluttered" Desktop. Implemented applications should be on the Desktop. Furthermore, the various programs and files are stored in a specific folder according to the following criteria:
Folder Use/Content/Criteria
---------------- --------------------
etc/init.d/ Various files and/or programs that could be implemented at boot time
are stored here.
These filenames should ALL begin with the letters "boot_" to make
them easy to identify. !!!!!!
At any time, only one is active.
This folder does NOT need regular backups.
pi/Desktop/ Programs, files, modules etc that are used often by Terminal commands.
This is to reduce the number of keystrokes when invoking them.
These objects are almost never changed.
The intent is that the number of objects in this folder is minimal.
Packages (housing multiple objects) must not be stored here.
Everything in Desktop should be regularly backed up.
pi/Downloads/ Files that are downloaded by Chrome or Raspberry are stored here.
Users should NOT download files into this folder.
This folder does NOT need regular backups.
pi/Music/ Audio files and music (.mp3, .wav, .mp4, etc) should be stored here
These objects should all be "playable" by the VLC media player
and by "aplay"
This folder does NOT need regular backups.
pi/Pictures/ Displayable pictures (eg .jpg, .png) are stored here.
All .png files should be displayable by nsxiv (deprecating sxiv).
This folder does NOT need regular backups.
Desktop/_volName/ This empty folder that begins with the letter "_" is the name of
the OS (boot) volume. Examples are "_SABRENT01" and "_Fla99S032G".
This is the main identifier used to identify the volume from
which the OS has been booted. Two such folders should not exist.
Desktop/__pycache__/ This folder is a system folder probably used by Python (packages?).
Users should not alter it.
Desktop/a/AppName Major applications that have been created and/or installed by/for the
user are stored in the Desktop/a/ folder. Examples are:
boot, GEDs, Hashing, IXp, OnBoard, PiR2, prepX, sandBox etc.
Raspberry docs mention a Projects/ folder but the author ignores it.
All major applications do NOT need regular backups other than data.
Until very recently, all apps were in the Desktop/ folder. Putting
them in the Desktop/a/ folder will be aggrevating for a while. !!!!
Desktop/a/boot/ All boot-related objects are here (as if boot were an application).
Even those that must be stored elsewhere should have a copy here.
Examples: boot_activeMenu_v00_i.py, bootParms.txt, CPU_temp.sh,
example.py, example, pir2.sh
Each object should have a comment saying where it MUST be stored.
Desktop/a/sandBox/ Programs, files, modules etc that are being developed
This folder is initially empty and should become empty again whenever
nothing is being developed or tested.
A good time to empty this folder is before/after a backup.
When moved out of the sandBox, objects should be either moved to
their final folder or to the garbage.
The sandBox is a folder at the same hierarchy as any application.
This minimizes the number of code adjustments required to move
a new application into "its final application" status.
When a small application is pulled from the package of applications,
it is placed into the sandBox temporarily to be run once or for
a short while. Each such applications should begin with the
characters "t_" indicating that it is temporarily in the
sandBox and can be deleted (because a full copy exists in the
package of smaller applications).
Desktop/garbage/ Anything that is no longer needed
Objects should be moved to this folder before they are put in Trash
This gives the user one more level of "changing your mind" before
actually discarding something forever.
Desktop/IX_assets/ Programs, files, modules etc that are the basis of the IX system
These objects might be initially placed here and moved elsewhere.
This is where temporary files can be written by the IX system.
Packages (housing multiple objects) must not be stored here.
All bash shell scripts (.sh) and their related text files are here.
bash shell scripts can store temporary files here.
IX_assets/help/ Run-time programs and Text files that explain or describe an object
in the IX system (most are .txt, .doc, .odt etc.)
Files about Linux or Raspberry concepts can also be stored here.
PDF files containing explanations or advice can also be stored here.
Large help files (eg a big PDF) should be stored here.
Some major help files are stored in articles by the author in
https://www.ePhotoCaption.com . Use "free find" to locate them.
This folder does NOT need regular backups.
IX_assets/ix/ Programs, files, modules etc that are loaded or used by other modules
Packages (housing multiple objects) should be stored here.
A list of libraries of packages stored here follows:
ix_pimain_pkg.py main Python programs
ix_pimain_pkg.txt main Python programs text files
ix_pkg.py Python functions / subroutines
n.sh shell n to list package contents
Text files that are seldom changed and are read_only are stored here.
This folder does NOT need regular backups.
Python code uses the following statement to direct function-searches to a
specific folder where it will search for a specified package of modules:
sys.path.append("/home/pi/Desktop/IX_assets/ix")
Python searches this path to find the function in the specified package:
from ix_pkg import show
Python will presume the extension ".py" for package "ix_pkg.py"
and will look for "def show(" within the ix_pkg.py .
IX_assets/Issues/ Files that describe special issues (problems) that the user has
encountered on this volume or with this version of the OS.
One file, "issues.txt", should be maintained and kept up-to-date
by the user.
It is always displayed when the Environment is displayed by
the IX_log.sh command (usually after it boots up).
When the "issues.txt" file becomes too long, it should be renamed
to "issues_to_2023LDec05" and kept in this same folder "forever".
Some sources recommend that users should have a "pi" folder named /home/pi/python/ but this
author does not have or use such a folder.
List of deprecated code and files upgraded for 2023AJan01
-
_SABRENT01 volume
-
boot_activeMenu_v00_i.py
-
bootParms.txt
-
ix_pkg.py
-
ix_pymain_pkg.py
-
08 Regular IX Backups and Their External Storage
The ONLY files needing regular backups are those in the Desktop folder. The only
folders needing regular backups are the Desktop/IX_assets/ folder, the Desktop/garbage/
folder and the Desktop/a/sandBox/ folder.
As of 2023LDec23, the size of such a backup on
Disk is only 3.5 MiB (megaBytes). Contrast this with the size of the whole Desktop: 113
MiB. The regular backups should be made to a Flash drive or be zipped (compressed) and
sent by email. These days, storing them as email on the cloud is perfectly safe. Currently,
zipping the regular backup will reduce the size by about 40% which is not significant.
But directory clutter can be avoided by permitting 7zip to zip them into a single file
located in and named like /home/pi/BU_IX_2023LDec22.7z . Unzipping the zipped files might be
simplified because they will be unzipped directly into the folder names that they came
from.
Beware: the actual destinations of unzipped files should be verified if an
unfamiliar zip program is used.
By saving the zipped file to the default folder /home/pi/ which is higher than the Desktop/,
each zipped file will be excluded from future zipped backups. The whole Desktop/ should be
backed up at least monthly to an external backup drive. Backups of the whole Desktop/
folder (onto external storage) should NOT be zipped. "NOT being zipped" will permit their
contents to be more easily searched by filename.
Note that boot-related programs and files wil be stored in the Desktop/a/boot/ folder as
if they were a separate application. This reduces directory clutter in the /etc/ folder and
elsewhere. Multiple boot "mechanisms" can be stored in Desktop/a/boot/ even though only
one of them can be effective (in use) at any one time.
Changes to the IX Folder Structure
As of 2024AJan01, the IX folder structure will have changed. All of the (major) application
folders (including the sandBox folder) will have been moved from the Desktop/ folder to the
Desktop/a/ folder. This is primarily to declutter the Desktop directory list. The contents
of the Desktop/ folder will have been carefully examined and "cleaned up".
Another change to the IX system will be implemented as of 2024AJan01. It is the checking of
versions of functions in the IX software system. This version checking will be done by a
combination of IXp.py (or prepIX.py) and the "requires()" function. The nature of this
change is that a function [eg show() ] will become a call within a call. The second call
will be when show() calls show_v00() [where "v00" is the current version of show().]
The show() function will need to contain the following statements:
sys.path.append("/home/pi/Desktop/IX_assets/ix")
from ix_pkg import show_v00
return show_v00( etc )
In fact, the show function that calls the real show function needs very little additional
code. It does need some code to be able to "tell" the requires() function exactly what
version of show it will call. This will be handled in Phase II of requires().
A novel future idea is that this "requires()" concept could force a "required function"
which in this case is "show()" to actually invoke a specific version of show(). Imagine
being able to evaluate the implementation of the next version of a function with very
few (or zero) coding changes to the code using the function. If the new version of a
new version of a function is found to be problematic, it could even be retracted with
very few coding changes. The author has not considered exactly how to do this, but
it certainly is possible.
BEWARE: IX functions with default parameters
Occasionally, functions have default parameters. Such functions cannot be generated automatically if the
default parameters are NOT specified correctly. An example of such a function which is defined somewhere as:
def fexampleWithDefaultParameters(s1,s2,s3,a=4,b=5):
The prepIX_I program has difficulty generating the unversioned routine (shown above) if the default
parameters are not coded correctly. The user MUST code this function correctly in the requires
statement. It MUST be coded as shown below:
requires("fexampleWithDefaultParameters(s1,s2,s3,a=4,b=5)","v=0",prepIXreq,vsnList)#CORRECT
which will generate the correct unversionned function shown below:
def fexampleWithDefaultParameters(s1,s2,s3,a=4,b=5):
return fexampleWithDefaultParameters_v01(s1,s2,s3,a,b) #CORRECT
The user MUST NOT provide variants of either of the 2 wrong default parameters to "requires" shown below:
requires("fexampleWithDefaultParameters(s1,s2,s3,a,b)","v=0",prepIXreq,vsnList) #WRONG
or
requires("fexampleWithDefaultParameters(s1,s2,s3)","v=0") #WRONG
The difference is minimal, but is very important. This above "requires" code (with the comment #CORRECT) code
will function correctly as an unversioned routine. But, in order to code it correctly, the user must know in
advance ALL of the default parameters AND their default values.
Any default values that are missing from the unversionned function will NOT be handled correctly. Coding the
wrong default values will cause errors also.
They will produce incorrect results. The resulting function will NOT be passed the default
parameters because the automatically generated unversionned function will be:
def fexampleWithDefaultParameters(s1,s2,s3,a,b):
return fexampleWithDefaultParameters_v01(s1,s2,s3,a,b) # BAD GENERATED CODE IF DEFAULTS OCCUR
The code shown below will run fine in normal Python (without the "requires" function). If this unversionned function shown below (with one or more missing default values) is invoked in the main program, the unversioned function will try to run (execute) the following statement but can encounter errors:
r=fexampleWithDefaultParameters("x","y","z",b=333) # DEFAULTS MAY CAUSE ERRORS
It will try to cause the following versionned statement to be invoked in the unversionned function:
def fexampleWithDefaultParameters(s1,s2,s3,a,b):
return fexampleWithDefaultParameters_v00(s1,s2,s3,a,b) # BAD GENERATED CODE IF DEFAULTS EXIST
NOTE THAT a IS UNDEFINED AND b=333 WILL NOT BE ACCEPTED AS A NON-DEFAULT PARAMETER, which WILL produce invalid results (usually Python syntax errors).
BEWARE, these functions might work if invoked using "import" or "requires", if the default parameters and their default arguments are not known in advance. Therefore, the best way to handle defaults is to do the research, discover the default parameters and their default values. Then provide the correct parameter list for the "requires" function. Merely looking at the existing code in an existing main program is insufficient. Fortunately, these errors will either not occur or will produce a syntax error.
BEWARE: OVER-RIDING A DEFAULT PARAMETER is the MOST SERIOUS DRAWBACK of the "requires()" function in the IX Software system.
Thankfully, when default parameters are absent, they are always treated correctly by the "requires()" function. But when any default parameter is overridden, a syntax error will result if the "requires()" is incorrectly coded. These errors might only show up when the function is used in a previously untested main program.
This is an example of problems that can occur when versions of functions are mis-handled. The IX software system
uses Hash Totals to detect changes to one of its functions.
09 "dir", "ls" and "n" Terminal Commands
Programmers with a background in Windows will favor using "dir" to list the contents of a
folder, even with Linux. Those with Linux experience know that "ls" will provide a
superior list that is color-coded. The IX system has a novel command called "n.sh" that
lists the contents of
any package of functions, applications or help files. The "n.sh" command also lists all
of the "def" statements in a package or main program. A list of the "def " statements
indicates which functions are already defined in the application. The "n.sh" command has
other variants that can be worthwhile exploring.
The list of folders under heading 07 (above) may seem to be very long, but these folders
have been groomed over time by the author. Further changes will be made very judiciously.
Of course, more major applications will be added. The intent is that a new volume can be
created with very few steps. This is done by first loading all IX objects into (unzipping
them into) the Desktop/IX_assets/ folder, then moving them to the other folders where they
belong. Folders holding unneeded applications can be immediately deleted. Then the job
is done.
The author will begin to implement this altered folder list as of 2024AJan01. This will
cause some aggrevation in the early part of 2024, but is a necessary change. This will
correspond roughly to the beginning of use of the _SABRENT01 Solid State Drive (SSD) or
the _KIOXIA_GTLL SSD as a Raspberry Pi development platform. _SABRENT01 has
the Raspberry Pi 32-bit OS named "bookworm" for Raspberry Pi Programming. _KIOXIA_GTLL
has a Raspberry Pi 64-bit OS named "bookworm". Both of these SSD drives can be used with
the Raspberry Pi 5B. This use of an SSD (replacing uSD cards) began in the fall of 2023.
This is being done in preparation for the implementation of a Raspberry Pi 5B with a
64-bit version of OS "bookworm". The Raspberry Pi 5B with 4 GB of RAM is currently on-order.
Eventually, the IX software system will have fully implemented the "requires()" function.
This function will do an "automatic import" of the correct version of required functions.
The "automatic import" loads the required functions from an IX package of functions and
checks the HASH total every time a function is used. Much more is said about the
"requires()" function elsewhere.
Eventually, the IX Software System will augment the main menu programs with the necessary
"improvised" program subtasks to populate the menu portion of many menu program.
These subtasks will be loaded from the package of applications. All such short
applications (subtasks) should either:
- return control to the calling program (like a subroutine)
- or keep looping until a ctrl-c (^C or the equivalent) is entered by a user.
Those subtasks that return control to the calling program will have a suffix of "_i".
Most on-line examples of Python programs today (as of 2023LDec22) have the main routine
defined as a subroutine in this manner. They begin with a Python "def " statement with
no calling parameters. A typical task named "task1_i" is defined by "def task1_i():"
and is invoked by the last two non-comment statements as shown below:
def task1_i():
# by D@CC on 2024AJan01
# the suffix of _i is the author's way of indicating that
# this sub routine begins with no incoming parameters and
# ends with (exits through) an "empty" return statement.
# This is known as a task "improvised" as a subroutine.
. . . .
return
#def end task1_i()
. . . . .
# check the "dunder name"
if __name__ == "__main__" :
task1_i()
#if end
#/task1_i.py
or something functionally similar. The "dunder name" really means "name of the imported module".
If nothing has been imported, the "dunder name" is "__main__". If more than one function has been
defined or imported, the last two uncommented statements will select which function to invoke.
But if there is a statement following the import, does the "dunder name" become "__main__" ?
Also, if more than one module is imported, is the "dunder name" the name of the last one?
Such minor applications (subtasks) should not be coded to stay in an infinite loop. Often
replacing input() statements with inputWto() or implementing "try, except and finally"
will be sufficient.
A first mock-up of how prep_IX_I will process the requires() function has been created on 2023LDec24.
The output of this first mock-up can be seen in Source 13 which is "Test_show_A_i.py" . It is a
test of the show() function.
When prep_IX_I.py is available, it will create and prepend the show.py module and suffix the
"LIST OF REQUIRED IX FUNCTION VERSIONS" at the end of the main module. When fully operational,
the "def show_v00" module will be "imported" by Python from the ix_pkg.py package. After a
little more coding, the "Test_Show_A_i.py module will be imported from the ix_pimain_pkg.py package.
They should run in the new sandBox folder. It is wonderful that coding a second function will NOT be
a requirement for the "requires" functionality in the revised IX software system. It will be
automatically generated by prepIX. Hopefully, the specs for prepIX will remain unchanged.
But before more coding is done, the definition of the prep_IX_I module should be revised to make it
correspond to the output in Source 13, which is my latest conception of how this will be done.
Sometimes a programmer wishes to see the code in a program from a slightly higher level. This can
be done by changing the "ixPrepreq" request parameter sent to the prep_IX module. Source 14 is almost
the same program (named "Test_show_A_i.py") as Source 13. It will produce very similar results.
But in Source 14, prepIX has been told (in the prepIXreq parameter) to "import" the
main function rather than prepending it to the module being sent to Python for execution. This
means that the code in the main imported function will not be visible but will still be run. This same
"import" request will be a signal to prepIX to NOT include all comments that begin with "##" (a
double # (number sign). Many comments in the smaller functions will be cropped (ignored). The
list of all versions of each "required" function that are found will also be suppressed by the
requires() function. The code in Source 14 compared to Source 13 is much shorter. The percentage
shorter will probably be even more if multiple functions are "required" by the main program.
Simply changing "prepIXreq" back to "" from "import" will list all the code again. Another thing
that will shrink the visible code is by moving the "requires_v00()" function itself into the
ix_pkg.py function library and importing it as well. Refering to code that has been shrunk
in this way, makes the debugging job much easier.
The author believes that he has finished "changing the specs" for prepIX_I.py at last. Remember
that prepIX_I is actually version I of prepIX. It does not perform all the actions of the final
prepIX program, but it does accept all of the parameters given to the requires() function.
Christmas 2023 will provide a welcome break. (A brand new Raspberry Pi 5B
was under the tree this year! Hooray!)
10 Automatic Creation of "Requires" Statements
Before the prepIX program runs, the IXp macro processor (Source 15) can automatically insert any "requires"
statements. It is a minor job to compare the undefined functions (in the main program) with
the available functions in the ix_pkg.py library. This comparison can be used to generate
the necessary "requires" statements in the main program. The author plans to modify the IXp
program to do this in his next round of software changes.
11 python-3.12.0 @asyncio.coroutine not installed
The author was attempting to learn and experiment with "asyncio" (Source 05), but . . .
as of 2023LDec16, to test the version of python in Terminal, he used the command:
>$python -V
Python 3.11.2
Conclusion: To use the @asyncio.coroutine, you need to be using Python 3.12.0 which is not the
case for me (yet). As a side note, before studying "asyncio", one should study the Python iterator
and generator functions.
12 BlueTooth Mouse Pairing Steps
The author has recently purchased his first BlueTooth mouse. It was manufactured by ONN and is sold by Walmart. Unfortunately,
the author was NOT successful in pairing it with his old HP pavilion laptop. But he was successful in pairing this mouse
with a Pi-400, Compute Module 4 and an RPi 5B. This mouse is designed to be switched between two BlueTooth devices. But the
author found that it was necessary to always repeat the pairing when moving from one computer to another. When a single Raspberry Pi
computer was powered off and then on again, the computer was able to retain the pairing connection. This mouse also works
wirelessly with a dongle that was supplied with the mouse. Source 17 describes the successful pairing process that the author used.
13 Artificial Intelligence News
Dell reveals New XPS 13,14 and 16 laptops with Microsoft's Copilot for Windows. GPT-4 CheatSheet is available. The technology
is called "generateve artificial intelligence. Copilot was developed on the ChatGPT (Source 19) platform. Global Powers Copilot for Microsoft 365
(aka Microsoft 365 Copilot) is different from Bing Chat. Copilot will be available from the taskbar or with the Windows "Key + C"
shortcut. In Word Copilot commands might be: "Make the third paragraph in the current document more concise and change the tone of
the document to be more casual. Another command might be: "Summarize the chats, emails and documents about the topic being discussed."
Copilot will appear in Word, PowerPoint and Outlook. Pricing might be $30 / month. Windows 11 PCs (including the Surface line) coming out in late February through Spring 2024 will include a Copilot key. AI keywords are: IoT, 5G,robotics etc. Intel spins off its "Enterprise Generative AI Deployemnt Firm" named Articul8. Linux 101: you might benefit from a "tiling window manager". FLIPBOARD (Source 18) is a new community for various interests. Seven beginner steps (Source 19) towards a new "acronym": Chat Generative Pre-trained Transformer (ChatGPT). Here they are:
7 STEPS TOWARDS ChatGPT
-
Get creative with your prompts
-
Ask follow-up questions
-
Tell ChatGPT more about yourself
-
Get ChatGPT to think again
-
Share links to your conversations
-
Give ChatGPT some text to work with
-
Speak to ChatGPT using your voice
In Source 20, Jeff Geerling describes controlling a Coral.ai TPU with an RPi 5. Apparently it can be done, but is not for the faint of heart.
On-Line Effects of AI by 2030
The author of this web page is predicting that the rapid introduction of AI on our society will lead to the following effects on the majority of our society by 2030:
-
Cars: electric & On-Line (driverless)
-
Cafes: Robot Waiters On-Line (except at Hooters)
-
Fast Food: On-Line with DriveThru (no tables)
-
Banking: On-Line with ATMs (no staff)
-
Voting: On-Line (no paper)
14 The RPi 5 Serial Port
Video Source 2 describes how to use the 3 pin Serial Port on the Raspberry Pi 5B. He mentions a source for the wire and connector for the 3 pin Serial Port on the RPi 5B. His related text is:
Raspberry Pi 5 documentation:
Use the Raspberry Pi 5 debug UART port (Serial0 -- ttyAMA10) or the traditional 40 pin GPIO UART port
(ttyAMA0) to send serial data. Data is sent to a phone through FTDI cable and USB OTG adapter. Data
is also sent to a Xiao SAMD21 chip in keyboard mode. This technique has also been demonstrated to
work on Raspberry Pi 4, Orange Pi 5, and Teensy 3.6. The Raspberry Pi 5 is running the bookworm 64
bit desktop operating system. All baud rates are 115200.
Correction: The diode used was 1N4004.
Raspberry Pi 5 documentation:
https://www.raspberrypi.com/documentation/computers/raspberry-pi-5.html
new uart port cable: digikey
etc
15 Thonny vs Python Issues
Thonny vs Python buffered print() difference
The author encountered different performance when using Thonny compared to Python3 on the Raspberry Pi. The difference
occurred with the following statements:
for i in range(5):
print("u",end='') #Python3 does NOT print immediately under bookworm OS
#for end
Under Thonny, the character "u" appeared on the display 5 times. Under Python3, it did not appear. Apparently, this is because
Thonny flushes the print buffer after each print statement, but Python3 does not. The solution is to flush the stdout
buffer after each print() as shown below:
import sys
for i in range(5):
print("u",end='') #Python3 does print immediately under bookworm OS
sys.stdout.flush() # when using both Thonny and Python3
#for end
Thonny vs Python cannot send CLI parms to Thonny
When wanting to run nShowDefs.py, the author could not send command line parameters (eg "-nd") to Thonny.
Sources
Video Sources
Video Source V207:01:
Optimising Raspberry Pi 5's software environment (25:14 min) 
By Raspberry Pi 2023JOct13
Video Source V207:02:
Use the Raspberry Pi 5 Serial Ports (13:13 min) By Sam Wechsler 2023LDec29
Web Sources
Web Source S207:01:www 
iGal3_parms.php (saved as .txt)
by D@CC on 2023GJul02
Web Source S207:02:www 
Waterend House and Area (35.html)
by D@CC in 2012
Web Source S207:03:www
Cockney Slang
by Polly Webster in 2023JOct 12
Web Source S207:04:www
on_click
by randomDjude on 2023ISep26
Web Source S207:05:www
Python Concurrency: Making sense of asyncio
by Amanda Fawcett on 2019LDec08
Web Source S207:06:www
Readthedocs.io Docs>> gpiozero
on GitHub asof 2019LDec16
Web Source S207:07:www 
GPIO ZERO CHEATSHEET
raspberrypi.org asof 2019LDec17
Web Source S207:08:www
Test_DownUp.py (saved as .txt)
by D@CC on 2023LDec18
Web Source S207:09:www
Five Ways . . Program On RPi At Startup
by DexterIndustries on 2023LDec20
Web Source S207:10:www
A Beginner's Guide to Virtual Environments in Python
by Patrick as of 2023LDec23
Web Source S207:11:www
How to run a Raspberry Pi Program at Boot
by The Pi Hut on 2018JOct25
Web Source S207:12:www
Using init.d script to start my python program on startup
by Essi Shams in 2004
Web Source S207:13:www
Test_show_A_i.py as txt
by D@CC on 2023LDec24
Web Source S207:14:www
Test_show_B_i.py as txt
by D@CC on 2023LDec25
Web Source S207:15:www
IXp - A Simple Macro Processor for Python
by D@CC on 2022FJun23
Web Source S207:16:www
boot_activeMenu_v00_i.py as txt
by D@CC on 2024AJan05
Web Source S207:17:www
BT ONN Mouse Pairing Steps
by D@CC on 2024AJan05
Web Source S207:18:www
FLIPBOARD Community
by TechRepublic on 2024AJan06
Web Source S207:19:www
How to use ChatGPT - 7 tips for beginners
by David Nield at TechRadar on 2023LDec26
Web Source S207:20:www
A PCIe Coral TPU FINALLY works on RPi 5
by Jeff Geerling on 2023KNov17
Web Source S207:21:www
boot_activeMenu_v00B_i.py as txt
by D@CC on 2024AJan07
Web Source S207:22:www
RPi & Remote Access
raspberrypi.org asof 2024AJan16
WebMaster: Ye Old King Cole
There is a way to "google" any of the part-numbers, words and phrases in all my articles. This "google" search limits itself ONLY to my articles. Just go to the top of "ePC Articles by Old King Cole" and look for the "search" input box named "freefind".
Date Written: 2023 J Oct 19
Last Updated: 2024 B Feb 19
All rights reserved 2024 by © ICH180RR
saved in E:\E\2022\DevE\MyPagesE\Globat\ePhotoCaption.com\a\207\207.html
backed up to ePhotoCaption.com\a\207\207_2024AJan05.html
Font: Courier New 10 (monospaced)
/207.html
