A while back someone was lamenting the fact that there was no easy way to check which config options applied to any particular PIC device. In the past I would either trawl the chipdata files or the datasheet. Over the Easter break I decided to brush up on my rusty (over a decade old) Delphi skills and create a program which runs under both Windows and macOS (a recent Delphi feature).
Now the program is currently usable for my purposes, but far from finished or what might be described as polished. There's no help file, and the File>Open menu does nothing :-) If nooone else is interested, then I'll simply use it "as is" for my own purposes. However, if anyone else is interested (see the screenshots which follow) I will upgrade it to finished.
You can either select a device from the scrollable list by clicking on it with the mouse or you can start typing the device number in the box at the bottom and press ENTER when the correct device is highlighted.
Last edit: Trev 2019-05-22
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The Next release of GCBASIC lets you Open the Datasheet (if you are on the internet) but that is often too much info and notoriously difficult way to determine Flag options.
I look forward to using this tool when the two of you have polished it.
Cheers
Chris
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I would encourage anyone who has any ideas for further functionality to speak up.
For example, it might or not be useful to paste GCB formatted config options generated by the program on the system clipboard into a GCB editor or IDE.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
We have this capability in the existing GCGB. We should lift the code and the logic for handling the dat file from that code. I would recommend that is integrated into the existing Programmer Tool or PPSTOOL. Both have different benefits some being same code base and common UI.
There are a number of challenges we need to resolve. One critical item is the default config is not always what the compiler uses to create the ASM. We have any a few other alignment things that would need to be addressed. We could adapt the compiler to use an external configuration file to address these challenges.... a thought.
We should discuss in the developer forum to agree the plan of activities.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
To kick off the discussion and help steer us on a constructive path I just wanted to say a few words about Great Cow BASIC and the Config Words that may not be common knowledge or at least taken for granted.
One of the major advantages of GCBASIC is that, as part of the wrapper code that it generates for all user programs, it handles the configuration and initialisation for the user. All that the user has to do to set up the Oscillator configuration, Ports and Reset Options is to tell the Compiler which chip it is to compile for and at what clock speed the chip should run.
This is done by using the #Chip Device,MHz construct.
What many people do not realise, especially those moving from the Arduino with its fixed 16MHz Xtal oscillator, is that PIC’s have sophisticated internal Oscillators capable of a range of frequencies that may be used to trade CPU performance for Power consumption. Resolving that construct for the PIC, therefor, involves selecting the correct Internal Oscillator Frequency, PLL input divider and PLL Multiplier and several associated Configuration Bits. In addition, the compiler sets the most commonly needed configuration for the Watchdog timer, Brownout Voltage Detector, MCLR, Debug and Communications Flags. For that reason it is essential that the compiler have control over the Primary settings.
That said there are many other features that are optional such as CLKOUTEN, ZCDDIS, BORV and BOREN which may well be useful but they are, as is evident, somewhat confusing. So finding an easy and intuitive way for the user to know what options are available for the chosen device, and if it will conflict with essential system Flags set by the Compiler, will be a great addition to GCBASIC.
So at least three pieces of information are needed when using the tool:
1. What optional config bits are supported by the device and what do they do.
2. Will a chosen bit conflict with the Compiler defaults, if so is it a critical conflict.
3. If it is safe to use, what is the GCB string needed to set/clear it.
The Tool should not replace having GCBASIC determine the default configuration but it could allow the User to more easily add configuration options over and above the default. That said It would be nice if the tool had the option to override the compiler if unique hardware with external oscillators and obscure timings were required for a design. In such a situation the User should have sufficient understanding of the device and its Datasheet to manually configure the Device and override the compiler defaults.
Configuration Bit Disclaimer -
"DO NOT TRY TO CHANGE OSC CONFIG OR ANY ADVANCED SETTINGS AT RISK OF BREAKING THE COMPILER, BRICKING YOUR CHIP OR SETTING FIRE TO YOUR PC"
Ok the last is a bit about the fire is an exaggeration but I did grow up with Motorola MC6800 Chips that had a HCF (Halt and Catch Fire) instruction - overclocking should be avoided.
As for packaging, I personally think it should be a stand alone tool as Configuration is not a Function of PPS, which is only available on a limited set of devices, nor is it Programmer related. That said the PPS tool is a great style guide.
Cheers
Chris
p.s. this was going to be my opening post for the developers forum thread if it gets created but is posted here for context.
Last edit: Chris Roper 2019-04-22
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Very interesting Chris. The Help has this to say about PIC config words:
This can all be rather confusing - hence, Great Cow BASIC will automatically set some config settings, unless told otherwise:
Low Voltage Programming (LVP) is turned off. This enables the PGM pin (usually B3 or B4) to be used as a normal I/O pin.
Watchdog Timer (WDT) is turned off. The WDT resets the chip if it runs the same piece of code over and over - this can cause trouble with some of the longer delay routines in Great Cow BASIC.
Master Clear (MCLR) is disabled where possible. On many newer chips this allows the MCLR pin (often PORTA.5) to be used as a standard input port. It also removes the need for a pull-up resistor on the MCLR pin.
An oscillator mode will be selected, based on the following rules:
If the microcontroller has an internal oscillator, and the internal oscillator is capable of generating the speed specified in the #chip line, then the internal oscillator will be used.
If the clock speed is over 4 Mhz, the external HS oscillator is selected
If the clock speed is 4 MHz or less, then the external XT oscillator mode is selected.
Note that these settings can easily be individually overridden whenever needed.
All of which suggests that the PIC config word settings are not critical things that must not conflict with the compiler's default settings which can be overriden.
Is the Help out of date?
As for packaging, I agree that this tool should remain standalone.
Last edit: Chris Roper 2019-04-23
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, in fact it is hopelessly out of date.
It was probably written when PIC’S with internal Oscillators were only just starting to appear and the majority of Users were still trying early PIC development boards with external Oscillators. The only recent update being a nod to LVP.
Since then the number of supported devices, and family groups has exploded to cover PIC10, PIC12, PIC16, PIC16 Enhanced Core and PIC18 along with several of the ever expanding AVR line.
That is hundreds of devices spanning several architectures and as you can imagine selecting the correct configuration is no longer as simple as choosing HS osc if the speed is greater than 4Mhz.
As it will definitely need to be researched in detail as part of the design process for the configuration Tool perhaps that same research could generate a more current HELP description for configuration and how the Configuration Tool can be used to make changes.
Cheers
Chris
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It is more complex. We set-up in the compiler, we correct errors in the source Microchip inc files and more.
A way forward.
This is not about the Help. This is about how two tools stay in-sync. We have resolved with PPSTool.
So, to resolve. We will produce an external file that the new ConfigTool will import. The external file will have the latest Great Cow BASIC defaults. Assume these parameters for now (this IS AN INCOMPLETE LIST) as this will prove the point (the code must handle this will no case sensitivity.
This is a list that the compiler development team will maintain and provide. This way as the changes to the compiler happen the ConfigTool is updated.
If a Great Cow BASIC default therefore is select for a specific MCU the default in the tool matches. The goal here is no conflict. If there is match with the Great Cow BASIC default then the tool does not need to output this specific config item into the #config line
I disagree on the standalone tool. Why? How will this integrate into the IDE? (or, do we replace the IDE?) Which tool do we remove as we are out of user extensions?
How is tool supported going forward? With PPSTool we can have procedures to recreate the tool chain and therefore the PPSTool.exe. What is the plan of this tool?
Re the Help. When I get a moment. I will update the Help, but, I will create the external file for this project and automatically import into the Help. That way they will be in sync in the future.
Re the oscillator mode selected. That is not correct in the current Help (v0.98.05)
An start-up oscillator mode will be automatically selected, based on the following rules.
'Start-up oscillator mode for PICs - relating #config '
If the microcontroller has an internal oscillator, and the internal oscillator is capable of generating the speed specified in the #chip line, then the internal oscillator will be used. See 'operating oscillator mode' below.
If the clock speed is over 4 Mhz, the external HS oscillator is selected as the start-up oscillator.
If the clock speed is 4 MHz or less, then the external XT oscillator mode is selected as the start-up oscillator.
Note that these settings can easily be individually overridden whenever needed.
'Operating oscillator mode for PICs - relating to set-up within a program'
The operating oscillator mode will be automatically select, based on the following rules.
If the microcontroller frequency matches the internal oscillator the intialisation will set the appropiate registers and register bits to correctly set the Operating oscillator mode.
If there are known 'erratas' with specific MCUs the compiler will set the appropiate registers and register bits,
For specific microcontroller the compiler will set call the calibration routine.
For each microcontroller family type and microcontroller sub family type the compiler will then set the appropiate registers and register bits to correctly set the operating oscillator mode.
'Start-up oscillator mode for AVR'
[to be written]
'Operating oscillator mode for AVR'
[to be written]
Last edit: Anobium 2019-04-23
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Back in the day I used DDE on Windows to transfer data between applications, but in the present I aim for as cross-platform as possible. To that end, I was envisaging copying to the system clipboard and allowing pasting into whatever editor/IDE you were using (after removing any conflict with compiler required options).
Delphi now has a fully-working, basically non-commercial use, "community edition" (after I paid $2.5 grand for it :-() so anyone with a clue could take it over should I be run over by the proverbial bus or simply expire. Maintenance shouldn't be too much of an issue if the data that changes is kept externally and imported at runtime.
Updated help - always a good thing!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Windows (32 bit) can be found at: [superseded]
macOS (32 bit - tested on Sierra, High Sierra and Mojave) at: [superseded]
Notes:
o Help is not currently available for either platform
o Copy to clipboard is not yet implemented for either platform
o Default Delphi application icon
o The default options depend on the order of the chipdata file
o Application is not signed (macOS version and its installer will be when released, possibly Windows too, no installer needed)
Any comments welcome.
Last edit: Trev 2019-05-22
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
o Renamed from PIC Config to PIC Info. You may want to delete
-Windows: C:\Users[name]\AppData\Roaming\picconfig\picconfig.ini
- macOS: /Home/Users/[name]/Library/Application Support/picconfig/picconfig.ini
o Prevent Windows running a second instance
(macOS does this by default :)
o Added PIC Info > Check for update macOS/ Help > Check for update (Windows)
o Added Datasheet button to Select tab
o Tracked down some pesky memory leaks when no chipdata directory chosen
o If no new chipdata directory chosen, revert to old one if it exists
o Speed up the loading of Bits and Registers tabs; added hourglass cursor during loading
o Search highlighting; beeps as soon as no character match and removes non-matching character from search field
o No phantom highlighting of first line when no search matches
o Added platform-dependent line breaks to clipboard data
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Bug fixes
o Fixed range check error when copying to clipboard for devices with more than 32 configuration options
New features
o Added Windows Help file (work in progress)
o Apple Help Book - PIC Info Help enabled (work in progress
o Application position now saved on exit and restored on restart
o Focus now defaults to Select tab device search box
o Added keyboard access (cursor keys, ENTER key) to navigate device list on Select tab.
To do
o The Help on both platforms needs finishing and polishing;
o GCB compiler defaults need to be highlighted (waiting on file from GCB developers).
Thanks for updtae.
I found something wrong on update schedule in the "Check for update" dialog: maybe character encoding mismatch.
However, no problem to use nice tool.
Wow! For the last 17 years there has been an un-initialised string variable lurking in that routine which has been used in at least three programs with worldwide distribution (Australia, Brazil, UK and US mainly) without a single report. Thanks! I'll fix it for the next version.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
No, you were not confusing me. Because the variable is un-initialised, whether or not the test to see if the ETA is null or not succeeds (in which case it shows the ETA sentence) or fails (in which case it does not show the ETA sentence) depends on whether that un-initialised variable's random memory location contains any data or not.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
A while back someone was lamenting the fact that there was no easy way to check which config options applied to any particular PIC device. In the past I would either trawl the chipdata files or the datasheet. Over the Easter break I decided to brush up on my rusty (over a decade old) Delphi skills and create a program which runs under both Windows and macOS (a recent Delphi feature).
Now the program is currently usable for my purposes, but far from finished or what might be described as polished. There's no help file, and the File>Open menu does nothing :-) If nooone else is interested, then I'll simply use it "as is" for my own purposes. However, if anyone else is interested (see the screenshots which follow) I will upgrade it to finished.
(Updated 1 June 2019)
Windows 10 screenshots
macos Mojave screenshots
Last edit: Trev 2019-06-01
Nice.
Ping me and I will share what we have to share with you.
You can either select a device from the scrollable list by clicking on it with the mouse or you can start typing the device number in the box at the bottom and press ENTER when the correct device is highlighted.
Last edit: Trev 2019-05-22
Very nice and very useful tool.
The Next release of GCBASIC lets you Open the Datasheet (if you are on the internet) but that is often too much info and notoriously difficult way to determine Flag options.
I look forward to using this tool when the two of you have polished it.
Cheers
Chris
This would be very useful. Nice!
Looks like I'm committed :-)
I would encourage anyone who has any ideas for further functionality to speak up.
For example, it might or not be useful to paste GCB formatted config options generated by the program on the system clipboard into a GCB editor or IDE.
100 % a good idea.
We have this capability in the existing GCGB. We should lift the code and the logic for handling the dat file from that code. I would recommend that is integrated into the existing Programmer Tool or PPSTOOL. Both have different benefits some being same code base and common UI.
There are a number of challenges we need to resolve. One critical item is the default config is not always what the compiler uses to create the ASM. We have any a few other alignment things that would need to be addressed. We could adapt the compiler to use an external configuration file to address these challenges.... a thought.
We should discuss in the developer forum to agree the plan of activities.
Oh yes!
That looks really, really useful.
To kick off the discussion and help steer us on a constructive path I just wanted to say a few words about Great Cow BASIC and the Config Words that may not be common knowledge or at least taken for granted.
One of the major advantages of GCBASIC is that, as part of the wrapper code that it generates for all user programs, it handles the configuration and initialisation for the user. All that the user has to do to set up the Oscillator configuration, Ports and Reset Options is to tell the Compiler which chip it is to compile for and at what clock speed the chip should run.
This is done by using the #Chip Device,MHz construct.
What many people do not realise, especially those moving from the Arduino with its fixed 16MHz Xtal oscillator, is that PIC’s have sophisticated internal Oscillators capable of a range of frequencies that may be used to trade CPU performance for Power consumption. Resolving that construct for the PIC, therefor, involves selecting the correct Internal Oscillator Frequency, PLL input divider and PLL Multiplier and several associated Configuration Bits. In addition, the compiler sets the most commonly needed configuration for the Watchdog timer, Brownout Voltage Detector, MCLR, Debug and Communications Flags. For that reason it is essential that the compiler have control over the Primary settings.
That said there are many other features that are optional such as CLKOUTEN, ZCDDIS, BORV and BOREN which may well be useful but they are, as is evident, somewhat confusing. So finding an easy and intuitive way for the user to know what options are available for the chosen device, and if it will conflict with essential system Flags set by the Compiler, will be a great addition to GCBASIC.
So at least three pieces of information are needed when using the tool:
1. What optional config bits are supported by the device and what do they do.
2. Will a chosen bit conflict with the Compiler defaults, if so is it a critical conflict.
3. If it is safe to use, what is the GCB string needed to set/clear it.
The Tool should not replace having GCBASIC determine the default configuration but it could allow the User to more easily add configuration options over and above the default. That said It would be nice if the tool had the option to override the compiler if unique hardware with external oscillators and obscure timings were required for a design. In such a situation the User should have sufficient understanding of the device and its Datasheet to manually configure the Device and override the compiler defaults.
Configuration Bit Disclaimer -
"DO NOT TRY TO CHANGE OSC CONFIG OR ANY ADVANCED SETTINGS AT RISK OF BREAKING THE COMPILER, BRICKING YOUR CHIP OR SETTING FIRE TO YOUR PC"
Ok the last is a bit about the fire is an exaggeration but I did grow up with Motorola MC6800 Chips that had a HCF (Halt and Catch Fire) instruction - overclocking should be avoided.
As for packaging, I personally think it should be a stand alone tool as Configuration is not a Function of PPS, which is only available on a limited set of devices, nor is it Programmer related. That said the PPS tool is a great style guide.
Cheers
Chris
p.s. this was going to be my opening post for the developers forum thread if it gets created but is posted here for context.
Last edit: Chris Roper 2019-04-22
Very interesting Chris. The Help has this to say about PIC config words:
This can all be rather confusing - hence, Great Cow BASIC will automatically set some config settings, unless told otherwise:
Low Voltage Programming (LVP) is turned off. This enables the PGM pin (usually B3 or B4) to be used as a normal I/O pin. Watchdog Timer (WDT) is turned off. The WDT resets the chip if it runs the same piece of code over and over - this can cause trouble with some of the longer delay routines in Great Cow BASIC. Master Clear (MCLR) is disabled where possible. On many newer chips this allows the MCLR pin (often PORTA.5) to be used as a standard input port. It also removes the need for a pull-up resistor on the MCLR pin. An oscillator mode will be selected, based on the following rules: If the microcontroller has an internal oscillator, and the internal oscillator is capable of generating the speed specified in the #chip line, then the internal oscillator will be used. If the clock speed is over 4 Mhz, the external HS oscillator is selected If the clock speed is 4 MHz or less, then the external XT oscillator mode is selected.Note that these settings can easily be individually overridden whenever needed.
All of which suggests that the PIC config word settings are not critical things that must not conflict with the compiler's default settings which can be overriden.
Is the Help out of date?
As for packaging, I agree that this tool should remain standalone.
Last edit: Chris Roper 2019-04-23
Yes, in fact it is hopelessly out of date.
It was probably written when PIC’S with internal Oscillators were only just starting to appear and the majority of Users were still trying early PIC development boards with external Oscillators. The only recent update being a nod to LVP.
Since then the number of supported devices, and family groups has exploded to cover PIC10, PIC12, PIC16, PIC16 Enhanced Core and PIC18 along with several of the ever expanding AVR line.
That is hundreds of devices spanning several architectures and as you can imagine selecting the correct configuration is no longer as simple as choosing HS osc if the speed is greater than 4Mhz.
As it will definitely need to be researched in detail as part of the design process for the configuration Tool perhaps that same research could generate a more current HELP description for configuration and how the Configuration Tool can be used to make changes.
Cheers
Chris
It is more complex. We set-up in the compiler, we correct errors in the source Microchip inc files and more.
A way forward.
So, to resolve. We will produce an external file that the new ConfigTool will import. The external file will have the latest Great Cow BASIC defaults. Assume these parameters for now (this IS AN INCOMPLETE LIST) as this will prove the point (the code must handle this will no case sensitivity.
This is a list that the compiler development team will maintain and provide. This way as the changes to the compiler happen the ConfigTool is updated.
If a Great Cow BASIC default therefore is select for a specific MCU the default in the tool matches. The goal here is no conflict. If there is match with the Great Cow BASIC default then the tool does not need to output this specific config item into the #config line
I disagree on the standalone tool. Why? How will this integrate into the IDE? (or, do we replace the IDE?) Which tool do we remove as we are out of user extensions?
How is tool supported going forward? With PPSTool we can have procedures to recreate the tool chain and therefore the PPSTool.exe. What is the plan of this tool?
Re the Help. When I get a moment. I will update the Help, but, I will create the external file for this project and automatically import into the Help. That way they will be in sync in the future.
Re the oscillator mode selected. That is not correct in the current Help (v0.98.05)
An start-up oscillator mode will be automatically selected, based on the following rules. 'Start-up oscillator mode for PICs - relating #config ' If the microcontroller has an internal oscillator, and the internal oscillator is capable of generating the speed specified in the #chip line, then the internal oscillator will be used. See 'operating oscillator mode' below. If the clock speed is over 4 Mhz, the external HS oscillator is selected as the start-up oscillator. If the clock speed is 4 MHz or less, then the external XT oscillator mode is selected as the start-up oscillator. Note that these settings can easily be individually overridden whenever needed. 'Operating oscillator mode for PICs - relating to set-up within a program' The operating oscillator mode will be automatically select, based on the following rules. If the microcontroller frequency matches the internal oscillator the intialisation will set the appropiate registers and register bits to correctly set the Operating oscillator mode. If there are known 'erratas' with specific MCUs the compiler will set the appropiate registers and register bits, For specific microcontroller the compiler will set call the calibration routine. For each microcontroller family type and microcontroller sub family type the compiler will then set the appropiate registers and register bits to correctly set the operating oscillator mode. 'Start-up oscillator mode for AVR' [to be written] 'Operating oscillator mode for AVR' [to be written]Last edit: Anobium 2019-04-23
I understand.
Back in the day I used DDE on Windows to transfer data between applications, but in the present I aim for as cross-platform as possible. To that end, I was envisaging copying to the system clipboard and allowing pasting into whatever editor/IDE you were using (after removing any conflict with compiler required options).
Delphi now has a fully-working, basically non-commercial use, "community edition" (after I paid $2.5 grand for it :-() so anyone with a clue could take it over should I be run over by the proverbial bus or simply expire. Maintenance shouldn't be too much of an issue if the data that changes is kept externally and imported at runtime.
Updated help - always a good thing!
There is a test version available as below:
Windows (32 bit) can be found at:
[superseded]
macOS (32 bit - tested on Sierra, High Sierra and Mojave) at:
[superseded]
Notes:
o Help is not currently available for either platform
o Copy to clipboard is not yet implemented for either platform
o Default Delphi application icon
o The default options depend on the order of the chipdata file
o Application is not signed (macOS version and its installer will be when released, possibly Windows too, no installer needed)
Any comments welcome.
Last edit: Trev 2019-05-22
Working very well for me.
Thanks for the macOS version ;-)
Very nice, I was just looking for a little setup program.
Thank you very much
ps. in WIN10 from an error when I close
If you are getting an error in Windows 10 (where it was actually developed) can you describe the error message in detail? Thanks!
Now he no longer makes the mistake, I noticed that when I set up the GCB directories correctly everything is fine.
Thank you
New version now available
https://www.sentry.org/~trev/files/gcb/PICinfo_app.zip (macOS)
https://www.sentry.org/~trev/files/gcb/PICinfo_exe.zip (Windows)
Changes:
o Renamed from PIC Config to PIC Info. You may want to delete
-Windows: C:\Users[name]\AppData\Roaming\picconfig\picconfig.ini
- macOS: /Home/Users/[name]/Library/Application Support/picconfig/picconfig.ini
o Prevent Windows running a second instance
(macOS does this by default :)
o Added PIC Info > Check for update macOS/ Help > Check for update (Windows)
o Added Datasheet button to Select tab
o Tracked down some pesky memory leaks when no chipdata directory chosen
o If no new chipdata directory chosen, revert to old one if it exists
o Speed up the loading of Bits and Registers tabs; added hourglass cursor during loading
o Search highlighting; beeps as soon as no character match and removes non-matching character from search field
o No phantom highlighting of first line when no search matches
o Added platform-dependent line breaks to clipboard data
Yes - a new version.
Bug fixes
o Fixed range check error when copying to clipboard for devices with more than 32 configuration options
New features
o Added Windows Help file (work in progress)
o Apple Help Book - PIC Info Help enabled (work in progress
o Application position now saved on exit and restored on restart
o Focus now defaults to Select tab device search box
o Added keyboard access (cursor keys, ENTER key) to navigate device list on Select tab.
To do
o The Help on both platforms needs finishing and polishing;
o GCB compiler defaults need to be highlighted (waiting on file from GCB developers).
Full details, downloads and installation instructions at: https://www.sentry.org/picinfo/
Thanks for updtae.
I found something wrong on update schedule in the "Check for update" dialog: maybe character encoding mismatch.
However, no problem to use nice tool.
Wow! For the last 17 years there has been an un-initialised string variable lurking in that routine which has been used in at least three programs with worldwide distribution (Australia, Brazil, UK and US mainly) without a single report. Thanks! I'll fix it for the next version.
When I launched PICInfo for the second time and more, the above strange dialog did not appeared any more.
I think it was old version's cache.
I'm sorry for confusing you.
No, you were not confusing me. Because the variable is un-initialised, whether or not the test to see if the ETA is null or not succeeds (in which case it shows the ETA sentence) or fails (in which case it does not show the ETA sentence) depends on whether that un-initialised variable's random memory location contains any data or not.
Hi, nice programme. Any chance you could make the letters in device names upper case? It just looks "right" that way to my eye.
Is it possibel to add a command line argument specifing the device name?