Rockbox

Button will also execute its designed action

With that in mind, anyone think of a reason it'd be bad to just have it be the same button as the Quick Menu on all targets? As far as I can see, it's "safe" to use in all screens because it won't actually interrupt playback, FM, or recording, or cause any of them to start. But I may have missed something.

Or perhaps invert the logic, so it charges by default and you need a button to connect.

Linus: I think that would be bad from the User's viewpoint. The obvious action when plugging in USB is to connect. I can only imagine the waves of "my player won't connect" questions.

Of course, it'd be slightly more convenient once you know it, since on some players, you plug more often to charge than to connect (probably), but to be consistent with every other msc-capable device in the world, I think the logic should be kept as-is.

I think the general feeling was that it might be better to do two things (both, not one of)

1) Have holding *any* button down invert behaviour, rather than any specific button, so that the user can choose for himself what he'd like to hold, based on what won't interrupt things.

2) Add an option, "On USB: Charge, Connect, Ask" in which the user can choose if it defaults to charging, defaults to USB connection, or always puts up a prompt.

There's still a bit of disagreement on this though from some directions.

I like option 1 very much; good idea Paul (or whoever came up with it). I guess you'd want to exclude the hold switch though (or any others that don't require physical pressure).

I also think option 2 would be useful, at least with a Charge or Connect. Not sure an Ask is needed here though.

Sorry - I didn't mean to cause all this trouble...

I like Llorean's suggestion, I have no great feeling about No1, but No2 I rellay like but I suggest that it should not be a new config but an extension of the existing USB charging option (and do we need to add USB connect but don't charge? - tenchinally it completes the set but is it useful?).

Well,
1) Is to solve the "different screens have different suitable buttons, as you usually want to pick the least disruptive button." Even if you set the default to "Charge" you obviously will still want to connect *sometimes* and being able to hold a button down while plugging in is simpler than going to the menu and changing it before and after every connection. Hold definitely should be excluded in my opinion, and any other button that doesn't require explicit user interaction (basically, no accidental changed behaviour.) This idea is thanks to LinusN

2) Ask was proposed because some people would rather never have to hold a button down. Basically the idea is that when you plug it in, a pop-up occurs. Charging starts immediately, playback continues, and if you want to connect you agree, otherwise you cancel. Simpler than having to manually pick a setting in the menu for each connect, and solves the problem of having to hold down a button, which people seem to find problematic. I think Zagor suggested the addition of an "Ask" option to a "Charge or Connect" menu. I think "Connect but don't charge" doesn't really serve a purpose, there's never really a reason not to top off a lithium battery, and I'm not even wholly sure you can tell it not to charge.

A usb charge by default is in the patches section, however it hasn't been updated in ages and no longer works - Confirmed, just checked then.

Now my suggestion for a solution is to implement a simple text box to appear when inserting the usb (this is while having the usb charge by default) saying something along the lines of, "Hold any key while inserting to enter USB mode". Of course this could also be reversed to say the opposite before reverting to disk mode (or even displayed while in it.)

I've just noticed that there is a Feature Request (#8147) for USB with no charge - apparently the user is concerned about battery cycles - I have no idea bout the validity of their concern.

I think I'm pretty close to having a first pass Patch for this (thanks to 'nls' on the IRC) - the only thing I wonder is how many combinations of connect/charge and button presses we want... currently I have;
- Always Connect
- Always Charge
- Connect but charge if button pressed
- Charge but connect if button pressed
- Ask (popup like the Radio scan option)

There should be three options (at least based on the original discussion in IRC I was part of):

"Charge" which means "Charge, but connect if any button (not including hold) is held down"
"Connect" which means "Connect, but charge if any button (not including hold) is held down"
"Ask"

Always connecting and always charging are essentially redundant.

Yeah, I agree. I had a good look at this and the simple options with button override are pretty easy but the real challenge, and the thing I want, is the Ask option. The challenge is that the USB thread is a background(firmware) task and the screen is handled by the foreground(apps) task, it's going to be a mega challenge (for a lowly ex-code plugger like me) to deal with that. I've come up with two thoughts:
A) send the USB inserted messge to pause the other treads, put up the USB screen and overlay the query, then act accordingly
B) add a message to be sent to the foreground tasks with are then responsible for doing the query
The first will interrupt the foreground task (WPS, Plugin, Video Playback) they may recover I haven't checked, but it won't be the nice operation I imagined. The second requires lots of bits of code to be modified(every plugin, main menu, WPS etc).

This is also a challenge because you need to be on real hardware, I haven't (quite) given up yet but it's a lot bigger than I imagined...

Actually there is a reason not to top off a charge on lithium batteries. Lithium batteries age faster the more fully they are charged. Regular topping off of a lithium battery is quite harmful to extended life. This is non-linear and as the batter approaches full charge the rate of aging increases dramatically and even modest overcharging is extremely harmful, while the difference in aging between fully discharged and 50% charged is quite small. Being fully discharged (the point where the low voltage cutoff kicks in) on a lithium ion cell is also bad as if voltage drops much lower the cell will be destroyed and due to a slow internal self discharge this will eventually happen to a cell left discharged for too long. Thus most suggest leaving lithium ion batteries at 50% charge for storage.

It would actually be a very nice feature to be able to specify how far to charge a battery. For my own use I would want the battery to always charge to a minimum of 3.85 volts (~50%) with a single override to 4.05 volts (~75%) which is more than sufficient for typical use and a secondary override to go to full charge which I would only rarely do for extended trips. These voltages are approximate for most lithium cells although there are chemistries such as phosphate (lower) and iron cobalt (higher).

To summarize, to best extend the life of lithium cells always keep them between 25% and 75% charged - don't fully charge. Also, keep them cool. The rate of aging dramatically increases as temps rise above room temperature. Regularly leave a fully charged battery inside a hot car and the battery can be ruined in a single summer. Store a half charged battery in your refrigerator and it will last for many, many years. I keep my laptop battery and my mp3 player in the fridge when not in use. The freezer would be slightly better for extended storage of a bare battery but condensation from regularly moving an mp3 player in and out of the freezer could be very bad. Also, a frozen mp3 player is likely unpleasant to grab and use. Finally, a very cold battery will perform poorly until it warms up and high current rates in or out of very cold batteries is also harmful.

If nobody else addresses the charging feature to offer options to maximize the life of lithium batteries, I will eventually do so, but as I'm very new to rockbox development I plan on doing some trivial patches first.

Todd, if using just a single setting for the charge current and voltage, what values would be sensible?
I'm interested in improving charging behaviour for the sansa e200 and just created a patch for charging from USB under rockbox, see
http://www.rockbox.org/tracker/task/8363
It uses a charge current of 300 mA (=0.4C for the 750 mAh sansa e200 battery) and a voltage of 4.0V (the voltage that the original firmware seems to use).
A charge voltage of 3.85 cannot be reached, the sansa e200 charge controller can only set a minimum voltage of 3.9V.

This patch solves the original bug report, i.e. it documents the existing charging behaviour (except for H10, where the default is charge)