@stoffera said in What editor do you use?:

@malaire does Geany use anything similar to Sublime Text config files?

I am thinking about adding support for these files in monomake. In Sublime Text the project json config seems to be pretty generic.

Geany uses ini-file syntax for project files, with .geany extension, which isn't quite as easy to understand as json, especially for build-related options.

Geany manual has some documentation about syntax at Configuration Files

I havn't tried build-settings of Geany much as I usually prefer to compile in separate console with custom makefile. I did a quick test with C and generated project-file looks like this:

[editor]
line_wrapping=false
line_break_column=80
auto_continue_multiline=true

[file_prefs]
final_new_line=true
ensure_convert_new_lines=false
strip_trailing_spaces=false
replace_tabs=true

[indentation]
indent_width=2
indent_type=0
indent_hard_tab_width=8
detect_indent=false
detect_indent_width=false
indent_mode=2

[project]
name=Test
base_path=/home/malaire/
description=
file_patterns=

[long line marker]
long_line_behaviour=1
long_line_column=80

[files]
current_page=0
FILE_NAME_0=23;C;0;EUTF-8;0;1;0;%2Fhome%2Fmalaire%2Ftest.c;0;2

[build-menu]
CFT_01_LB=_Build
CFT_01_CM=gcc -Wall -Wextra -o "%e" "%f"
CFT_01_WD=
filetypes=C;
CFT_00_LB=_Compile
CFT_00_CM=gcc -Wall -Wextra -c "%f"
CFT_00_WD=

I've been using Geany for few years, mainly on Linux although it does claim to be cross-platform. (About Geany)

(And Vim when I have to work on command-line.)

Thanks, it's working now on Debian Stretch.

ps. sudo apt-get purge modemmanager is still needed as that keeps resetting Mono.

Still same error. Running dpkg-deb -c openmono_1.7.0.deb | grep monoCyLib shows nothing, i.e. the required file is not included anywhere in the package.

The package openmono_1.7.0.deb of this release seems to be missing many files which are supposed to be installed to directory /usr/lib/openmono/mono.

Because of this, building an app does not work, and even the example hello_world exits with error:

make: *** No rule to make target /usr/lib/openmono/mono/monoCyLib.a', needed by 'hello_world.elf'. Stop.

(The file monoCyLib.a is missing from filesystem, along with whole directory /usr/lib/openmono/mono).

I just added initial framework-version to GitHub (commit).

I decided to reverse the lookup-table for percentage calculation and always use 1% resolution to make code simpler. If user wants less resolution it's easy to just calculate e.g. ReadPercentage() / 10 * 10 or even supply a custom lookup-table.

Also I think it would be better to not use special return values in CalculatePercentage and just return value from 0 to 100.

@stoffera said in Reading battery voltage?:

@malaire, this is great :-) ! We should put this into the framework!

May I suggest a class that lives in the namespace mono::power and that can return the remaining percentage of battery charge.

Maybe just extend the BatteryPower class I sent you some days ago. Tell me what you think.

Sounds good. I'll test this few days to see if there are any problems, and I'll also add few changes:

• return <0 when percentage can't be calculated (e.g. -1 when charging, -2 when mV is zero)
• include internal battery_percent_mV table, but allow overriding it with custom table
• manually "fix" the graph between 16% to 23% so that it's a straight line there

With three logs so far, discharge graph is nearly equal between logs, except at around 16% to 23% percent remaining, where there are significant variations.

The 'Combined' line here is what my script calculates, and battery percentage is then determined based on that.

I just added initial version of battery percentage calculation to my battery-logger app.

I decided to make Mono-side of code really simple, so I created a script log-analyzer.pl (source) which calculates mV limits from given logs, which can then be used to easily determine battery percentage.

For now the app is showing battery percentage at 1% resolution while testing this, but actual accuracy is lower. The script can also generate data with other resolutions, and I think something like 5% might work better generally.