BeagLEDs

I AM AWESOME!

Okay, that probably sounds a lot better in my head, especially with the image of wearing a trenchcoat, riding a skateboard, and sucking a lollipop (<cough>Hackers</cough>).

Anyway.

Thing is, when I code, I tend to fart around. Try stuff. Play. Let my mind wander. But this was different. 95% of BeagLEDs was written in Metapad (think Notepad). Yes, on an XP PC. By removing the ARM and RISC OS from the equation, I could get down to cutting some code without the distractions.
So yesterday I sat outside in a deck chair enjoying the sun (about bloody time it made an appearance) and writing the startup of BeagLEDs. And just now? I wrote the vector handling stuff, read through it, tidied up a few odds and ends.

Dropped onto a USB key, moved to the Beagle, it assembled first time. It only sort-of worked, a dopey oversight. Nothing critical. I added one instruction, then it worked. Exactly as planned.

I’m happiest at this stage. Never got my head around that OO stuff, and as much as I’ve used VB5, I don’t consider it “real” programming. LDR? MOV? STMFD? That’s what programming ought to look like.
[I should probably point out, I’ve not done any serious ARM coding in ages, it’s nice to be back looking at Zap!]

Okay, what BeagLEDs does is kinda simple, yet in its way necessary. It hijacks the two user LEDs on a Beagleboard (any version, same basic layout) so that the LED on the left of the microSD card will blink on and off, resting for a second in each state.
The LED on the right of the microSD will blink for “disc activity”. I put disc activity in quotes as it links into FileV, ArgsV, BGetV, BPutV, GBPBV and FindV so some non-disc activity (*Modules, anyone?) can also trigger it, as can stuff like RAMdisc or ResourceFS. There are no plans to rectify this, as the possible delay of sanitising and filtering devices outweighs any gain it might provide. It is supposed to behave like a harddisc lamp, not be an exact clone.
The disc activity indicator is damped, it will be on for a minimum of 15cs, so repetitive accesses (successive byte reads for instance) occur with minimal delay from BeagLEDs.

This is posted to the “Porting…” forum as this software is specific to the Beagle (any version). It will check, and refuse to run, on anything else.

tl;dr – you can get the module from http://www.heyrick.co.uk/random/BeagLEDs,ffa (it’s a Module, type &FFA, size 1024 bytes).

In a (random-length) while, I’ll describe the module and its internal operation on my blog, for those interested in how it works.

Night guys [he says at half six in the morning ;)].

Best wishes,

Rick.

Like many readers of this thread, sorry but I’ve not tried this out yet. All the same, «Impressionnant!»

Like many readers of this thread, sorry but I’ve not tried this out yet. All the same, «Impressionnant!»

Explanation of how it works: http://www.heyrick.co.uk/blog/index.php?diary=20120528

Best wishes,

Rick.

Hi Rick. Just a quick word of warning: those LEDs are next to the SD card slot. So don’t be surprised if an SD card driver were to arrive that used them. :)

Hi Steve. Just a quick word of warning: ;-) there ought to be a proper API for things such as user LEDs.

I suspect this is why people didn’t like Acorn’s Timecode module (or whatever it was), as it hijacked the available ticker, and tough beep if anything else was using it.

If/when my Beagle is revived, I would be willing to modify BeagLEDs as follows:

Default behaviour is as it currently is.
SWIs provided to allow something else to turn the LED on and off, and also to turn it on with auto-off after X centiseconds (like the FileV behaviour). If something else uses an LED, BeagLEDs will refrain from its behaviour on that LED (or maybe just not do it at all – comments?). Also a SWI to provide direct addresses (and an API) for the functions themselves so code that needs speed (like an SDFS) needs only BL to it, not call a SWI. That said, with the auto-timeout, something only needs to turn the LED on, BeagLEDs will do the rest…

Just ideas while on break at work, I can flesh it out in more detail if you’re interested.
[added at 04h58 CET: think: not unlike Hourglass ]

Best wishes,

Rick.

there ought to be a proper API for things such as user LEDs.

In a way, I agree. But it is an odd one because we’re in the unusual position that there isn’t a single organisation (e.g. Acorn) who decide what features the hardware is going to provide and what they will be used for. Instead, we’ve got a community of developers making use of whatever appears in third party hardware.

My instinct is that RISC OS needs to have a standard set of functions that it can use LEDs for, if they are present on a board and this is documented somewhere. The idea of having an API for claiming LEDs is OK except what the users want is consistency and the idea that LEDs on your machine change their behaviour depending upon what software is running doesn’t really make sense to me.

If an API were to emerge, maybe it would be something based upon a list (e.g. bitfield) of LEDs by their defined function (e.g. “SD read”, “SD write”, “FS read”, “FS write”, etc). This list would be standard for RISC OS and common across all platforms – but with different platforms likely to provide just a subset. For each hardware platform, we’d need to agree (centrally) how the list of LEDs-by-function maps onto the physical LEDs available on that hardware. That would be fixed.

The API might look like:

1. a call to see if an LED (or set of LEDs) exists and claim it if it does (maybe return an address to read/write its/their state)
2. a call to release a claimed LED (or set of LEDs)
3. a call to read its state (abstracts over using the address)
4. a call to write its state (abstracts over using the address)

Maybe this would sit on top of a HAL device?

But it is an odd one because we’re in the unusual position that there isn’t a single organisation (e.g. Acorn) who decide what features the hardware is going to provide and what they will be used for.

Err, isn’t that RISC OS Open’s task? The alternative is crowdsourced anarchy…

If an API were to emerge, maybe it would be something based upon a list (e.g. bitfield) of LEDs by their defined function

Yes, that would seem to be an idea with some merit. It should also allow the possibility of being easily ported to other devices with on-board LEDs (IGEPv2, for instance), while also having an appropriate fallback option on non-LED devices (RPi).

Best wishes,

Rick.

isn’t that RISC OS Open’s task?

What I’m saying is there isn’t a company (as in the days of Acorn) with complete control of the OS and the hardware. Yes, ROOL do try to steer the community development of RISC OS, but we don’t want to start dictating how things should be to everyone.

The main problem in this topic, as I see it, is that you’ve announced something after having implemented it. In parallel, there’s a clashing development that’s underway which itself hasn’t announced its intentions for using those LEDs. Net result: clash.

So maybe an extension of our allocations system is needed (in addition to a central list of RISC OS LED functions) to allow people to claim LEDs on a particular bit of hardware…?

The main problem in this topic, as I see it, is that you’ve announced something after having implemented it.

It was only ever intended to be a stop-gap until something proper came along, since nothing else was making use of the LEDs and it seemed odd how RISC OS didn’t touch them (and, as you note, the parallel SD driver made no public note of its intentions to use said hardware).

Net result: clash.

Today, yes. But (assuming a working Beagle) I put it together in a weekend, it could be altered to provide the API instead. Just because it exists today doesn’t preclude something else tomorrow. :-)

So maybe an extension of our allocations system is needed (in addition to a central list of RISC OS LED functions) to allow people to claim LEDs on a particular bit of hardware…?

I would, frankly, prefer the “style guide” approach. Let’s say the RPi model C has one LED and I put in a request to use it to blink to show system health (which is granted). Then a filing system wants to flash it for SD access…are they stuffed because it has already been claimed? A good API may be able to overload to support both behaviours on the same LED,

Sorry form interrupting your discussion.
Why not using only one LED, like on any PC, for any disk activity and the other one could be used for different purposes.

Joe – that’s probably the plan, but the question is how to best implement this? For instance, my code goes a bit OTT and blinks an LED for any filesystem access (including ResourceFS and RamDisc!), while I have a suspicion that the pending SD filing system may only do it for SD accesses. Which is the preferred? I’m sure both camps will have their advocates. My RiscPC has three harddiscs and one drive lamp, to which all three are wired. I don’t need to know what drive is active, just that one is (because RISC OS doesn’t have a habit of using the disc at random times for “housekeeping”). Likewise, my PC (NAS box and eeePC both) have a single light connected to the motherboard that lights for an access to either drive. Therefore on a board such as the Beagle, it isn’t entirely illogical for USB devices and SD card both to light the lamp. Again, on RISC OS, it is reassuring to know activity is occurring – how, where, and why are usually able to be judged from context. For example, auto-save. Little wink of the light, you know it is done. Mail debatching, light still on, mail still being debatched… That sort of thing.

Furthermore, on a Beagle there are three or four LEDs that the user can access, though only two easily via GPIO. Other (future?) hardware may have more, or none. Perhaps if an API of some form is drawn up, then it can be determined from the HAL itself what LEDs are present, and protocol/convention will guide us as to how it/they can be used.

I guess the only sensible move would be to have a central configuration plugin which checks the available LEDs via a yet-to-be-designed API and lets the user select which LED should display what – other modules would offer their “LED functionality” to the yet-to-be-designed API and the configuration plugin would connect the source to the target.

It occurs to me that a similar module using the same API could blink an onscreen indicator, for devices with no controllable LEDs.

Wasn’t there a USB you’ve got mail indicator with a driver?

Should applications be able to send a sequence they want displayed? (e.g. a morse code letter.)

Wasn’t there a USB you’ve got mail indicator with a driver?

Courtesy of Dave ‘Cheeky’ Higton:

http://www.apts04.dsl.pipex.com/Progs/MBoxAlert.htm

…while also having an appropriate fallback option on non-LED devices (RPi).

The RPi has an ‘O.K.’ LED and three for Network at least one of which various Linux people have suggested being redeployed.

Many moons ago I wrote IGEPv2LEDs – not as flashy (ha!) or as well named as Rick’s BB offering, but another hardware platform to throw into the mix. If anyone was designing an API for board LEDs, it would be worth taking a look as it illustrates that some hardware offers not just on/off, but PWM dimmable LEDs as well.

PWM dimmable LEDs as well

I believe the LED hooked to the helper chip (659508) can do this. Datasheet is insane, as it looks like that chip is the “everything else” device. ;-)

Yay Joe! ;-)

http://www.heyrick.co.uk/random/18192611.png

[taken today]

Is that the core temperature? Also, nice to see a Zap user.

Somebody just swore ;-)

Is that the core temperature?

I believe so. I think that’s the only temperature sensor in the OMAP. Gets a little warmer when I try to play XviDs (obviously, no GPU code around) but otherwise hangs around that.

Also, nice to see a Zap user.

Wouldn’t have it any other way. I’d love to find something that can do under Windows what Zap makes so easy. ASCII mode, byte mode, colourisation… Notepad++ isn’t bad, but it isn’t Zap.

@ Keith: I hated Impression, loved Ovation. Likewise, hated StrongEd, loved Zap. Love Firefox (even though it is a lethargic memory-hungry hulking monster that puts Gojira to shame) and really don’t like Opera much (since the new MSIE (10?) won’t work on XP, I just pretend like MSIE never existed in the first place…).
It isn’t a religious war so much as one sort of clicks with how my mind works, the other really doesn’t.

I believe the LED hooked to the helper chip (659508) can do this. Datasheet is insane, as it looks like that chip is the “everything else” device. ;-)

Sorry – missed this post. Yes, most probably the LED hooked up to the helper chip can do it, just as it does on the IGEP. In fact, the same code might even work. You could give it a try if you were feeling brave. Datasheet is a bit intimidating, but once you find what you’re looking for it’s not quite so bad.

Hi Rick,

I went stright into your random folder and got you this:
http://www.heyrick.co.uk/random/nodame_meriikurisumasu.avi

Joe – just in the car on the way to a boot sale (keep my eyes open for a cheap DVI monitor!) and it is a beautiful sunny day (finally!).
Nodame is very cute, isn’t she?

Not sure what this has to do with RISC OS, but nevermind. Maybe if the system becomes more popular, somebody somewhere might think of either porting the GPU driver, or writing a wrapper so Linux modules could be loaded…

Hi Rick,
If you’ve checked your email, you would know that I was reffeing
to Christmas in July, there is a present awaiting you.