IRC log of #maemo-ssu for Saturday, 2013-03-30

kerio	also, it's quite untrivial to do something like that	00:00
kerio	because the uboot menu is a single monolithic uboot script	00:00
DocScrutinizer05	shrug doesn't do update-bootmenu-foo exactly the same?	00:03
DocScrutinizer05	just that it parses files in alien directories	00:04
DocScrutinizer05	instead of using find and read to find out about actually installed bootimages and get input from user interactively	00:05
Estel^	kerio, could you give me ls of your /lib/modules/current ?	00:09
Estel^	in my case it contains only modules.alias modules.ccwmap and simillar things, which seems like source of my problems wikth bootmenu	00:09
kerio	/lib/modules/current points to the kp52 directory	00:10
Estel^	as vanilla /sbin/preinit have Modules_path=/lib/modules/current, and later, things load watchdogs things by modprobe $module_path/twl_blabla	00:10
Estel^	well, not here	00:10
Estel^	her eit points to omap1	00:11
Estel^	/lib/modules/current -> 2.6.28-omap1	00:11
Estel^	considering that 2.6.28-omap1 doesn't exist here, troubles are clear :P	00:11
kerio	hm, reinstall kernel-power-modules i guess	00:11
Estel^	funny, did it yesterday, due to Pali.s fiasco with changing things without boosting version number	00:12
Estel^	will try it again	00:12
kerio	one of the kernel-power packages adds the fix to preinit that makes it use `uname -a` instead of current	00:12
Estel^	ah	00:13
Estel^	love binary file replacements	00:13
kerio	it's not a binary file	00:13
Estel^	having kp installed, then removing multiboot, result in /sbin/preinit being reverted to vanilla	00:13
Estel^	result in kp fix going into /dev/null	00:13
Estel^	you know what i mean	00:14
Estel^	divert should be used,. or smth like that	00:14
kerio	and yeah, it should be a getbootstate fix	00:14
kerio	which it probably is	00:14
Estel^	if you remove multiboot, or smth like that, it just silently breaks	00:14
kerio	then clearly multiboot has to be purged from the repos	00:14
Estel^	i'm not sure if kp postinst sed things into /sbin/preinit is right thing to do	00:14
Estel^	shitload of circumstances may break it	00:15
Estel^	silently	00:15
Estel^	with suer scratching his head about wtf	00:15
Estel^	user, even	00:15
Estel^	Pali, ^	00:15
Estel^	and yes, kernel-power-modules does that sed into preinit	00:16
Estel^	and symlink of current to kp52	00:16
Estel^	while the latter souns like OK, the sed leaves bad taste	00:16
Estel^	we have fckin divert for a purpose, don't we?	00:16
Estel^	DocScrutinizer05, any comment here? I may be talking bullshit, but i think sed'ing into crucial boot scripts during postinst script is fubar	00:16
Estel^	too many ways to silently break it by other packages, or even worse, by removing other packages. Or shitload of other ways	00:17
Estel^	now i wonder if any other kernel-power package does simillar thing and I should be reinstalling them, too?	00:18
Estel^	or smth else may be silently broken and in 2-3 weeks i'll be scratching my head about why something is fubar	00:18
Estel^	from a different barrel - anyone ahve idea what sh: can't access tty: job control turned off	00:19
Estel^	may mean in practice"?	00:19
Estel^	(and/or how to fix it)	00:20
Estel^	it happens in recovery shell bundled manually into /sbin/preinit . doesn't seem to affect anything, but...	00:20
*** arcean has quit IRC		00:22
*** arcean has joined #maemo-ssu		00:22
*** Martix_ has joined #maemo-ssu		00:39
Estel^	you know what? I feel like writing CLI re-iplementing backupmenu's function into normal console, to make use of fbcon...	00:56
Estel^	without that pesky text2screen thingie	00:56
Estel^	and without bootmenu requiment	00:56
Estel^	just a recovery shell from /sbin/preinit, with whole backupmenu started by invoking simple script (that runs cli interface)	00:57
kerio	aka pali's recovery console	00:57
Estel^	MentalistTraceur's recovery console > Pali's recovery console (sorry, Pali)	00:58
kerio	rescueOS > MT's recovery console	00:58
Estel^	sure, everythingh can be done by manuyal commands, but reintroducing it as CLi make it a) faster for casual execution	00:58
Estel^	RescueOs is different beast	00:58
Estel^	...b) more friendly for noobs, and I do want noobs to make backups early and often	00:59
Estel^	after all, MT's recovery console can be run from preinit on-device itself, while for restoring borked device (without u-boot), you need external device with flasher for rescue os	01:00
Estel^	rescue os is super, but it's different use-case	01:00
kerio	why?	01:00
Estel^	ant MT's recovery shell > Pali's recovery shell, due to Pali's recovery shell being pesky about requiments and excluding some, see bootmenu, multiboot, etc. MT"s one doesn't care about that at all	01:01
Estel^	well, how woulds you run rescue-os on device without multiboot, that doesn't, well, boot?	01:01
Estel^	at all?	01:01
Estel^	due to borked root or whatever?	01:01
Estel^	no bootmenu, no anything?	01:01
Estel^	and without external device to run it from flasher?	01:01
kerio	i wouldn't touch multiboot with a 10-foot pole	01:01
*** NIN101 has quit IRC		01:02
Estel^	s/without multiboot/without u-boot/	01:02
kerio	why would i be without u-boot?	01:02
kerio	also, how will you run MT's recovery shell?	01:02
Estel^	rolleyes cause you wouldn't have it installed?	01:02
Estel^	from /sbin/preinit	01:02
kerio	no, the rootfs is borked, remember	01:02
Estel^	borked = files there messed	01:02
kerio	so rescueOS is fine	01:02
Estel^	not whoile filesystem, the latter is quite impossible to achieve on ubifs ;)	01:03
Estel^	well, for really borked rootfs, you would need rescueos	01:03
Estel^	or better	01:03
Estel^	reflash ;P	01:03
Estel^	or rescueOs and backup restore	01:03
Estel^	for real life cases, thought, when borked package or typo or whjatever user error makes your device unbootable, MT's /sbin/preinit is enough to restore device - it loads at earliest possible stage, and doesn't require 2nd device/u-boot/bootmenu/whatever	01:04
kerio	oh fucking hell no	01:04
Estel^	if one have u-boot, I would implement both MT's recovery shell (for quick access) and rescueOs on sd (for really fuckek up situations)	01:04
kerio	that's incredibly far from being the earliest possible stage	01:04
Estel^	well, you know what I mean- earliest as first thing sourced (preinit)	01:05
Estel^	I don't attack rescueOs, it's absolutely superb tool	01:05
*** RST38h has joined #maemo-ssu		01:06
kerio	this reminds me, i should put rescueOS on the uSD	01:06
Estel^	it's just that it's overkill to run it for 99% of simple fixes, that are achievable by 12 lines MT's recovery shell	01:06
Estel^	and trust me, as soon as I'll install u-boot, I'll customzie and put rescueOs on uSD	01:06
Estel^	;)	01:06
kerio	i'm not entirely sure why rescueOS is "excessive", considering that it's pretty much the same amount of effort to use it	01:06
Estel^	now, motivate Pali to make 0xFFFF run-able from device	01:06
kerio	boot with slider open, select rescueOS with arrows, push enter	01:07
Estel^	well, you're probably right, as soon as you have rescueOs setup ;)	01:07
Estel^	Mt's things is easier to install for noobs, properly, that's why I would bundle CLI backupmenu there	01:07
Estel^	I don't want to expect people to properly install u-boot before being able to do backups, and being independent of 2nd device at the same time	01:08
Estel^	just package diverting sbin/preinit to contain MT's recovery shell, and putting some scripts (backupmenu-cli) into proper places	01:08
Estel^	so people can get recovery shell and backupmenu cli by installing it, and hitting any key during device early boot stage	01:08
Estel^	then, if one use u-boot (everyone should), rescueOs is a must	01:09
Estel^	it's just that u-boot thing is for sure overhelming for noobs, so if I want to give them backupmenu-like experience from CLI, I would bundle it into Mt's console. Hell, it can be replicated inside rescueOs too, if anyone want it	01:10
Estel^	brb, changing irc device	01:10
*** sunny_s has joined #maemo-ssu		01:25
*** Martix_ has quit IRC		02:11
*** M4rtinK has quit IRC		02:16
Estel^	kerio, I have everything set-up for u-boot. What was that 2 teerminal trick to flash thing from on-device?	02:52
Estel^	(i got u-boot.bon file)	02:52
Estel^	s/.bon/.bin/	02:52
infobot	Estel^ meant: (i got u-boot.bin file)	02:52
Estel^	I know I could look at postinst script for any flasher package, I just don't get that 2 terminals thingie	02:53
*** kolp has quit IRC		03:36
*** nox- has quit IRC		03:40
Estel^	hm, no idea how to flash u-bootlbin from on-device. Will flash it from desktop flasher3.5 tomorrow.	03:41
Estel^	nvm, found out that you need to:	04:20
Estel^	softupd -vv -s --local	04:20
Estel^	in one terminal as root, and	04:20
Estel^	flasher -k u-boot.bin -f	04:20
Estel^	in another	04:20
Estel^	it seemed to flash ok, but after reboot, device wasn't able to boot. Did the same thing (flasher3.5 -k u-boot.bin -f) from desktop, and it worked like charm, u-boot greeted me after reboot	04:21
Estel^	shrug	04:21
*** arcean has quit IRC		04:21
Estel^	works like charm, although noticed werido - if, instad from entries or default, I enter u-boot console, doing - as advertised - run emmcboot result in shitload of errors and no booting	04:22
Estel^	same for run sdboot, even if proper .src and bootmenu.img.d/ are on sd card	04:22
Estel^	will need to investigate how to boot from sd, really	04:22
*** discopig has quit IRC		04:27
*** discopig has joined #maemo-ssu		04:28
*** discopig has quit IRC		04:29
*** discopig has joined #maemo-ssu		04:32
*** discopig has quit IRC		04:33
*** discopig has joined #maemo-ssu		04:34
*** discopig has joined #maemo-ssu		04:34
*** LauRoman has joined #maemo-ssu		04:39
*** wmarone_ has joined #maemo-ssu		04:46
*** wmarone__ has quit IRC		04:55
*** PaulFertser has quit IRC		04:55
*** PaulFertser has joined #maemo-ssu		05:00
*** Pali has quit IRC		05:01
*** amiconn_ has joined #maemo-ssu		05:36
*** amiconn has quit IRC		05:36
*** amiconn_ is now known as amiconn		05:36
*** LauRoman has quit IRC		05:43
*** DocScrutinizer05 has quit IRC		06:03
*** DocScrutinizer05 has joined #maemo-ssu		06:03
*** LaoLang_cool has joined #maemo-ssu		06:48
*** LaoLang_cool has quit IRC		06:50
*** M13 has joined #maemo-ssu		07:11
*** futpib has joined #maemo-ssu		08:07
*** jon_y has quit IRC		08:41
*** jon_y has joined #maemo-ssu		08:41
*** MohammadAG has quit IRC		08:58
*** MohammadAG has joined #maemo-ssu		08:58
*** LaoLang_cool has joined #maemo-ssu		09:08
*** LaoLang_cool has quit IRC		09:14
*** Vlad_on_the_road has joined #maemo-ssu		10:02
*** Martix has joined #maemo-ssu		10:44
*** futpib has quit IRC		10:53
*** futpib has joined #maemo-ssu		10:54
*** NIN101 has joined #maemo-ssu		11:10
*** M4rtinK has joined #maemo-ssu		12:17
*** unclouded has quit IRC		12:37
*** MohammadAG_ has joined #maemo-ssu		13:13
*** MohammadAG has quit IRC		13:13
*** MohammadAG_ is now known as MohammadAG		13:13
*** kolp has joined #maemo-ssu		13:15
*** nox- has joined #maemo-ssu		13:32
*** kolp has quit IRC		13:44
*** kolp has joined #maemo-ssu		13:45
*** sunny_s has quit IRC		13:53
*** arcean has joined #maemo-ssu		15:18
*** tg has quit IRC		15:35
*** LauRoman has joined #maemo-ssu		16:23
*** NIN101 has quit IRC		16:23
*** arcean_ has joined #maemo-ssu		16:39
*** arcean has quit IRC		16:39
*** arcean_ is now known as arcean		16:39
*** lartza_ has quit IRC		16:53
*** Estel^ has quit IRC		16:53
*** Estel_ has joined #maemo-ssu		16:54
*** Estel_ has quit IRC		16:54
*** Estel_ has joined #maemo-ssu		16:54
*** lartza_ has joined #maemo-ssu		16:54
Estel_	Pali, wtf is with u-boot rc3-1 in maaemo repos being unable to voot 3.* kernels, and u-boot rc3-1 (same version) from your page having no problem with it?	16:59
Estel_	again that freaking habit of changing shitte without bumping version number?	16:59
Estel_	don't take it as disrespectful, I really appreciate your work, but it is 3th time I run into things from you that have 5467654567 different variants with sameversion number, that also, cause me to enter bootloop	17:00
Estel_	it's getting on my nerves, and I really don't see any reasonable rationale for not bumping version number when changing things, so pretty please, cease and desist :P doing it this way	17:01
Estel_	+/3th time/3th time in 2 days/	17:01
*** NIN101 has joined #maemo-ssu		17:16
*** tg has joined #maemo-ssu		17:25
*** aap has quit IRC		18:03
*** aap has joined #maemo-ssu		18:18
*** futpib has quit IRC		19:06
*** futpib has joined #maemo-ssu		19:06
DocScrutinizer05	I guess Nokia's versioning scheme of <year>-<week-of-year>-<build-in-this-week> (*-2010-36-198) got invented for a reason, isn't unique to Nokia, and most probably got implemented by some automatism that always creates correct numbering/versioning and ovoids any two builds "sharing" same version	20:24
Estel_	agreed, and I just can't get why Pali repeatedly change things, releasing here and there same versions/name things, different internally	20:30
kerio	Estel_: hm, the .bin from the -bootimg in extras-devel and the -bootimg from his site have different md5s	20:31
kerio	but it could be because of the different build environments	20:31
Estel_	last time it was kp52 with crucial change to rx51 module (despite resulting in bootloop, when bme-replacement was installed over "older" kp52), now it's u-boot that can't boot 3.*kernel is ine version, and doesn't have problems in another, same version...	20:31
Estel_	kerio, I know it have different md5s, because there freaking different. -devel version breaks when booting any 3.*linux kernel	20:32
Estel_	silently breaks, too	20:32
Estel_	version from his site works flawlessly	20:32
Estel_	another thing that would confuse me like hell and make into spending hours debugging perfectly fine bootmenu.src, if not for a spark of intuition. Later, I discovered that arch linux guys spent hours doing exactly that - debugging perfectly fine things...	20:33
kerio	DocScrutinizer05: what's the bq27k GPIO connected to?	20:33
DocScrutinizer05	zilch	20:33
Estel_	just to notice, at the end, that u-boot with same version in Pali's site works OK ;)	20:34
kerio	well, it's enabled	20:34
Estel_	it was month ago, but, apparently, wasn't important enough to bump version number	20:34
Estel_	/rant over	20:34
*** Estel_ is now known as sdhyfdes		20:35
*** sdhyfdes is now known as Estel_		20:35
kerio	hm, i need a better name for convert_registers_units	20:38
kerio	alright, parse_registers	20:39
Estel_	what are you cooking?	20:46
*** M13 is now known as Guest77046		20:47
*** Guest77046 has quit IRC		20:59
*** M13 has joined #maemo-ssu		20:59
*** unclouded has joined #maemo-ssu		21:01
kerio	Estel_: some sort of python library to get data from bq27k	21:02
*** M13 has quit IRC		21:04
DocScrutinizer05	.ko	21:14
kerio	DocScrutinizer05: actually, the important part is parse_registers	21:15
kerio	and as long as you provide a registers dict, it'll work fine	21:15
*** BCMM has joined #maemo-ssu		21:15
kerio	regardless of where it comes from	21:15
kerio	"Parse a dict of raw bq27k registers (with registers that are split into high/low already merged)"	21:16
DocScrutinizer05	yeah, :-/ for the latter	21:18
DocScrutinizer05	relies on a priori knowledge not supposed to be found on that level	21:19
kerio	fwiw, it relies on a priori knowledge already	21:20
kerio	because the dict you're supposed to pass has the cute names that come from the datasheet	21:20
kerio	and meh, i could change it and require "ARL" and "ARH" to be passed instead of "AR", but what's the point?	21:21
DocScrutinizer05	the point is to at least _try_ and enable fixing this borked register dump that's not really a clean register dump to become one eventually - so nobody could argue "yeah, maybe it's not correct this way, but look, other apps already depend on it"	21:29
DocScrutinizer05	the knowledge about meaning and semantics and properties of registers are meant to be inside your code, not included in the dump	21:30
DocScrutinizer05	all properties, even such nonsense like "pairing" that's actually non-existent on a i2c register dump level	21:31
kerio	DocScrutinizer05: should i keep the names SEDVF and SEDV1 or change them to EDVFT and EDV1T (for Threshold)?	21:32
DocScrutinizer05	I'd suggest you stick to the names in datasheet as close as possible	21:33
kerio	but S is for Scaled, and i'm unscaling them	21:33
kerio	but i can't call them EDVF and EDV1 because those are the flags	21:33
DocScrutinizer05	are the flags named exactly identical to the threshold integers?	21:34
kerio	yep	21:34
DocScrutinizer05	then that's shit, and I'd rather change the flags' names to flag-EDVF and flag-EDV! or sth like that#	21:34
DocScrutinizer05	s/!/1/	21:35
infobot	DocScrutinizer05 meant: then that's shit, and I'd rather change the flags' names to flag-EDVF and flag-EDV1 or sth like that#	21:35
kerio	you're going to use the flags a lot more than the thresholds	21:35
kerio	also, there's GPIEN both in MODE and in PKCFG, i renamed the PKCFG one to GPIENP	21:35
kerio	(everything is well-commented, of course)	21:35
DocScrutinizer05	since when we're chosing name length based on usage frequency?	21:35
kerio	for for_loop_index in range(27):	21:36
kerio	DocScrutinizer05: anyway, the "correct" way would be to rename /both/	21:37
kerio	EDVF and EDVT	21:37
DocScrutinizer05	sure, go ahead	21:38
kerio	...meh, i'll just leave them as SEDVF/SEDV1, which is the official name	21:38
DocScrutinizer05	yes, since that's what DS does. I never seen a datasheet using ambiguous names for similar things	21:43
DocScrutinizer05	there's only one EDV1 and that's the flag. There's a SEDV1 that's upper half of EDV1-threshold	21:44
DocScrutinizer05	it's probably fair to keep this name for the normalized value	21:44
kerio	DocScrutinizer05: GPIEN is ambiguous :)	21:45
DocScrutinizer05	how so?	21:46
kerio	it's a bit in FLAGS and in PKCFG	21:46
DocScrutinizer05	ugh, right	21:46
kerio	er, a bit in MODE and PKCFG	21:46
DocScrutinizer05	yeah, then it's fair to use a prefix for the read-only derived value, like PKCFG:GPIEN	21:47
DocScrutinizer05	it's basically a constant here	21:50
DocScrutinizer05	since you can't change it by any reasonable procedure	21:50
DocScrutinizer05	and you usually don't even need to read it, since it's mostly irrelevant for anything you ever would want to code	21:51
DocScrutinizer05	anyway, if you need to use a prefix for one bit in a word, then you should use same prefix for all bits in same word, and maybe you even should use similar prefixes for all bits in similar class of words (EEPROM)	21:54
DocScrutinizer05	or actually use prefix "EEPROM" for all values in EEPROM	21:56
kerio	ooh, (v + 4) % 8 - 4 is how you do two's complement if v is a 3-bit value	21:59
kerio	DocScrutinizer05: meh, i'm already making up "AEE" as a name	22:00
DocScrutinizer05	but then a value like EEPROM_SEDV1 would be 8bit mandatory. In that case better use EDV1_threshold for the normalized (*2^8) value	22:00
kerio	it's always TAPER[7]	22:00
DocScrutinizer05	oops, SEDV1 = designed EDV1_threshold/8 - 256	22:14
DocScrutinizer05	not designed EDV1_threshold/2^8	22:14
kerio	yeah, yeah :)	22:18
DocScrutinizer05	yeah, I guessed/assumed ;-)	22:18
kerio	so EDV1_thr = 0b1-SEDV1--000	22:19
DocScrutinizer05	anyway I also guess, you want to export the normalized EDV1_threshold, not the raw register value? then you should use a different name than SEDV1	22:19
kerio	DocScrutinizer05: yeah, i'm normalizing, converting and unpacking everything i can	22:20
DocScrutinizer05	:nod:, sth like that (though I haven't evaluated your formula)	22:20
kerio	it's not a formula	22:20
kerio	0b1[SEDV1, 8 bits]000	22:21
DocScrutinizer05	ooh	22:22
DocScrutinizer05	i see	22:22
DocScrutinizer05	well, since you're exporting only normalized values, you're probably safe to use SEDV1, since nobody expects to see a non-normalized value in that var	22:23
DocScrutinizer05	doesn't matter how complex the normalization is, if it's just a factor like 3.57/20, or something like 8 + 256	22:25
kerio	i'm afraid i've strayed from joergthon in this version :<	22:25
DocScrutinizer05	err 8 + (2588)	22:25
DocScrutinizer05	btw making up names is a pretty poor idea. Devels should always have something to refer to, that they already know from the stuff they had to learn about in DS	22:33
kerio	DocScrutinizer05: why the hell is there an offset that goes in units of 2.45uV?	22:53
kerio	isn't that small beyond recognition?	22:53
kerio	every other voltage is bigger by at least 3 orders of magnitude	22:54
DocScrutinizer05	kerio: where?	22:59
kerio	BOFF	22:59
DocScrutinizer05	I'm absolutely sure you misinterpreted sth	22:59
kerio	maybe it's some specific sensor	23:00
DocScrutinizer05	meh, offset-calibration	23:00
DocScrutinizer05	that's for adjusting the ADC to 0.000000	23:00
DocScrutinizer05	it's not supposed to have an offset error of 50% of max range	23:01
DocScrutinizer05	if the value range for that sensor is 0 .. 100, then the offset calibration is in the range of 0.0001 or sth	23:02
kerio	what i don't get is why 0.0001 would matter	23:02
DocScrutinizer05	because it introduces an accumulating error	23:03
DocScrutinizer05	it's like a constant small current flowing in or out of cell	23:03
DocScrutinizer05	this would NAC make drift despite cell is not even connected to anything	23:04
kerio	i see	23:04
kerio	so you really want it to be 0 when it should be	23:04
DocScrutinizer05	kerio: we got RS=20mOhm, a current of 1mA creates a voltage across RS of 20µV	23:11
DocScrutinizer05	I'm actually amazed that the offset calibration granularity is that huge, I'd rather had expected sth like 0.0245µV	23:12
DocScrutinizer05	btw that's most probably 2.54, not 2.45	23:13
kerio	why?	23:15
DocScrutinizer05	well, 0.1mA error seems a lot	23:15
kerio	ah yes, it is	23:15
kerio	no, i meant the 2.45	23:15
DocScrutinizer05	lol, because I feel that	23:16
kerio	no, wait, 4.9 is 2.45*2	23:16
*** futpib has quit IRC		23:16
kerio	you feel wrong	23:16
* DocScrutinizer05 has closed the DS 10min ago :-S		23:16
DocScrutinizer05	btw BOFF has 8 discrete values, I'd not bother 2s complement, rather use your beloved lists for that, here it seems quite right ;-)	23:19
DocScrutinizer05	and yes, it's 2.45	23:19
kerio	o rly	23:19
kerio	thanks, i would've never guessed that, /while reading the DS/	23:20
DocScrutinizer05	pfff ;-P	23:20
*** LauRoman has quit IRC		23:20
kerio	DocScrutinizer05: is it "right" to correct the datasheet?	23:24
kerio	914 is clearly just 3.57 << 8	23:24
kerio	even though it's 913.92	23:25
kerio	and of course by 3.57 << 8 i mean 3.57 * (1 << 8)	23:28
*** Vlad_on_the_road has quit IRC		23:32
kerio	3.57 << 8 would be 18511595908343686758400.0	23:34
kerio	http://pastebin.mozilla.org/2260579	23:35
kerio	it's getting more and more ridiculous as time passes	23:35
DocScrutinizer05	what makes you think 3.57 is more exact/autoritative than 914?	23:35
kerio	maybe 914 is authoritative	23:37
kerio	then it would have to be 3.5703	23:37
kerio	3.57 is just so much cuter :3	23:38
kerio	anyway, it clearly states that ILMD is actually the high byte of ILMD, and if we go by that, it's silly to use 3.5703125 as the unit of the full ILMD when you use 3.57 everywhere else	23:39
DocScrutinizer05	btw forget about my explanation regarding accumulative error and BOFF, the chip goes into "idle" mode when a certain minimum threshold on current in/out is not reached	23:39
kerio	DocScrutinizer05: do you understand the above code?	23:48
DocScrutinizer05	> >The Digital Magnitude Filter (DMF) threshold can be set in EEPROM to indicate a threshold below which an ycharge or discharge accumulation is ignored. This allows setting a threshold above the maximum DSCC offse texpected from the IC and PCB combination, so that when no charge or discharge current is present, th emeasured capacity change by the bqJUNIOR is zero.<<	23:48
DocScrutinizer05	kerio: I only looked cursory across it	23:48
DocScrutinizer05	looks good to me	23:48
kerio	:D	23:49
kerio	comments are truly amazing	23:49
kerio	and i quite like the repeated divmod, more than the bit manipulation	23:49
DocScrutinizer05	I've seen two divmod with identical parameter#2 of 1<<1	23:50
DocScrutinizer05	I suspect the 2nd to be a typo	23:50
DocScrutinizer05	or rather c&p error	23:51
kerio	nope	23:51
kerio	read more closely	23:51
kerio	:)	23:51
DocScrutinizer05	maybe it's exactly what you wanted though	23:51
kerio	both tcfix and dcfix are 1b	23:51
*** NIN101 has quit IRC		23:53
DocScrutinizer05	int i = getsubbits(byte/int/word composedword, const int LSB, const int numofbits)	23:58

Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!