I did a search, but couldn't come up with anything...so....

Is it better to leave the unit plugged in all the time (while I have it in my house), or disconnect the power when I'm not using it? Wouldn't unplugging it a lot hurt the disk drives? Finally, how long after you power it down before the drives spin down and it's safe to unplug the unit?

It's safe to unplug it at any time, unless you're in the middle of a sync -- the drives are mounted read-only. So, unless something catastrophic occurs, your music is safe.

As for leaving it plugged in all the time, I tend to. However, you might be concerned about the blinking LED -- it's quite bright.

Is the blinkingness hard coded?

I don't know if the blinking light brightness can be changed in the kernel. Would be a cool mod if it could be.

My work-around on my Mk1 was to make the light smaller by doing some heat-shrink tubing around it (being careful of the VFD and its fill nipple). Now my Mk1's LED is a tiny itty bitty little light that you can barely see. This was necessary since I now have it mounted next to my television set and it would be distracting at its original brightness.

I don't know if the blinking light brightness can be changed in the kernel. Would be a cool mod if it could be.

Remember, the LED can be affected by visuals on the player, so in theory a userland app could interfere in just the right way

When in standby you can (in theory) control the LED, it has 2 modes when the display power is off:

- Pulsing (default)
- Controlled by host

In theory, if you set up interrupts and timers you could make it do anything; however this requires disabling of the LCD controller on the StrongARM and it's sometimes hard (been a while since I tried though...) to get everything to sync correctly when it comes up again.

Hugo

Hugo, can you give us at least a starting point on where we might be inserting such a hack to control the LED behavior on standby? You seem to have a good grasp on how this would be done, and there are some smart people hacking the kernel these days. If we knew where to start, or at least a pseudocode of what would have to be done to gain control of the LED, I could see this as a good feature to be worked into the mlord enhancements.

To do this, you may need to dig into the display driver and the sa1100 (or sa1110) datasheet from developer.intel.com.

1. disable the LCD controller (clear the LEN bit in LCCR0)
2. set bits 0 and 9 in PPDR (leaving the rest as-is), configuring LCD data line 0 and the LCLK (line clock) lines on the LCD interface as outputs. The PPSR allows you to set the state of these outputs.

WARNING! Incorrect setting of the PPDR could cause hardware damage - in theory, at least. If you disabled (say) UART3 and enabled the RX3 pin as an output then it would be driving against the serial receiver chip. Not good. We use the PPSR in its default state - ie 0. Setting bits 0 & 9 is no problem, as these are already outputs. The errant behaviour you sometimes see on the standby LED is from the LCD controller still running and occasional mirroring of LDD0 onto the display when LCLK is high.

Normal behaviour (blinking LED) is achieved by having LCLK low (bit 9 of PPSR). If you put LCLK high, the LED will mirror the state of LDD0 (bit 0 of PPSR) - ie, bit 0 high is LED ON, bit 0 low is LED OFF.

With some playing around you can do PWM on the LDD0 line and make the LED do whatever you want.

The LED is not controllable when the display is on, as the display PIC (which also controls the LED) is busy with more important business - like syncing the display up.

Hugo

Default is, I take it, varying the pulse width to create the pulsing effect on the LED. Could (someone) make it pulse at a standard 25% of full?

As default, the PWM is done *inside* the PIC on the display board. To change the default behaviour you have to do all the work on the strongarm.

Hugo

I was under the impression there was a driver that had an IOCTL entry point with a number of functions. Has this disappeared? I would have thought the assembly level activity you have just described should be resident in a device driver anyway!

oo
Just thought of a cool use for it! Instead of the default behaviour when updating the software, what about have it flash or something so it doesn't look like it's gone to sleep? I realise this may not be possible due to the timing issues, tho.

Yes, it does have an ioctl entry point - it's just there are no calls to do stuff with the LED, and no plans to do anything on this front (we just don't have time at the moment!)

If someone else gets it working and submits a neat patch, we'll test it out and put it in later v2.x's with emplode options to control it?

Hugo

Does this all apply to Mark1 units as well as Mark2(a) ?

Thanks

Yes, it does.

Hugo

Okay, I'll add something for it in Hijack v256.

Cheers