Will we ever see a true end-user-programmable UI?

[carrot]

Without a doubt, yes, one day. We are already at the point where the hardware can support it. Someone just needs to figure out how to write the software for an end-user to use.

 

[wyager]

A while back I had a thread about computer controllable lights... If you can program an AVR or a PIC, chances are whatever light manufacturer you use uses one of the two.

And as for boot time, with an internal oscillator an AVR can boot in like 20 clock cycles IIRC, which is .0000025 seconds at maximum speed.

 

[HKJ]

If your going to wait for the clock to stabilize, then load the user's program from flash into ram, then load the last saved states, while your checking for user input you are going to be waiting for more than 10ms, and it will be a noticeable delay.

Why do you believe it has to load a program into ram? The type of micro used here always runs the program directly from flash and only need to load one or maybe a few status bytes from EEPROM to ram.
A 10 ms startup time is easy to do.

The parasitic drain I mentioned would be from keeping the micro in a sleep state, or even keeping it ready for user input so as to avoid the input delay not from volatile memory, but what is to say that the user wouldn't choose an input scheme that would require an always active state?

Again: There is no delay from loading the program.

 

[SexieWASD]

Why do you believe it has to load a program into ram?

Well, because that is how processors work, if it were to try running a program directly from flash memory it would be incredibly slow to the point of being useless for ANY application.

I'm done trying to talk intelligently about the limitations you would find if you were to actually attempt to make a user programmable flashlight, which are quite different than one that is programmed once at assembly with a highly optimized program written in assembly language.

 

[HKJ]

Well, because that is how processors work, if it were to try running a program directly from flash memory it would be incredibly slow to the point of being useless for ANY application.

I'm done trying to talk intelligently about the limitations you would find if you were to actually attempt to make a user programmable flashlight, which are quite different than one that is programmed once at assembly with a highly optimized program written in assembly language.

That is how some processors work, but not the type used in flashlights.
A user programmable flashlight does not mean high level language, where you load operating system, drives and program each time you start. More realistic is a few bytes in the EEPROM that specifies user interface, levels, etc.
It would also be possible to write a PC program that would build a program for the flashlight and then load it into the micro processor, this would not change the startup time of the flashlight.

And about talking intelligently, I have done many projects on these small microprocessors and have a good idea about what they can do.

 

[RedLED]

Yes, we will.

 

[Chevy-SS]

Without a doubt, yes, one day. We are already at the point where the hardware can support it. Someone just needs to figure out how to write the software for an end-user to use.

Yes, thank you, I guess this strikes at the heart of my question. I kind of suspected the hardware was already adequate. So it's the software that is lacking.

But my goodness, I would think a programmable UI program would be pretty easy to write????

-

 

[HKJ]

We are already at the point where the hardware can support it.

Most hardware is missing a computer interface. It is not difficult to add, but it has to be there, either has usb or a bit protocol. A bit protocol is already present in many of the small microprocessors, often it is used to program the processors and sometimes it can be used from the program in the processor, but it is not accessible for the user.

But my goodness, I would think a programmable UI program would be pretty easy to write????

This depends what kind of programmable UI you wants. Defining brightness and flashing modes for a number of predefined selections are easy enough to do. This already exist in some lights, but must usual be programmed from the light.

 

[wyager]

The way I see it, the code would work like this-

Boot
Set registers
Load UI bytes from EEPROM
Start specified PWM duty cycle according to what's in the EEPROM //all of this stuff can be done much faster than we can possibly notice

loop forever{
do regular light stuff
poll the USART or other serial interface
if(serial data is available) then settheUI();
}

settheUI(){
write whatever is in the UART RX buffer to EEPROM 0x00
write whatever is in the UART RX buffer to EEPROM 0x01
write whatever is in the UART RX buffer to EEPROM 0x02
write whatever is in the UART RX buffer to EEPROM 0x03
etc.
}
I ignored changing PWM duty because the structure and design of each light varies so vastly, but it would go in there as well. And we have lots of free clock cycles if we use hardware PWM, we can set the duty and ignore it. If we set the computer interface code in the main loop, we don't have to worry about extra startup time. We really don't have to wait for the RC oscillator to stabilize as timing isn't really crucial until we start doing serial stuff.

 

[Beacon of Light]

With UI's from light's like the Jetbeam I.B.S and HDS Ra what else so you want to program? You can set those light's up to do just about everything you want.

Exactly, the Novatacs UI has spoiled me on most of the lights out there. I set my Novatacs up to super low and enjoy months of light before recharging.

 

[sylathnie]

This does exist for the mag hot-wire. I don't see why it couldn't exist for any other type of light as well.

https://www.candlepowerforums.com/threads/231886

(There seems to have been a production delay though. I'm not sure how long it might take to get one at this point.)

 

[KeyGrip]

JSBurly was working on this a while ago. Unfortunately the money wasn't there and the project was put on hold.

http://jsburlysbenchmark.com/flashlights/indiumsmart.php

 

[wquiles]

JSBurly was working on this a while ago. Unfortunately the money wasn't there and the project was put on hold.

http://jsburlysbenchmark.com/flashlights/indiumsmart.php

Man - a blast from the past. I definitely remember that project

 

[KeyGrip]

Yea, the concept seemed pretty solid. Maybe worth revisiting now that there is a larger, more connected flashlight enthusiast community.

 

[lolzertank]

Well, because that is how processors work, if it were to try running a program directly from flash memory it would be incredibly slow to the point of being useless for ANY application.

I'm done trying to talk intelligently about the limitations you would find if you were to actually attempt to make a user programmable flashlight, which are quite different than one that is programmed once at assembly with a highly optimized program written in assembly language.

Although your first statement is true for computers, it is not true for many microcontrollers. At 1 to 20Mhz, internal flash is more than fast enough to keep up with the rest of the microcontroller. At higher speeds, microcontrollers often include some type of accelerator or cache to speed up flash accesses. The reason is that micros do this is that SRAM is very expensive in terms of silicon space. Forcing programs to be copied into RAM would just restrict programs to very small sizes. Using another type of memory is just too complex.

On the other hand, there is no way to accelerate the hard drive of a computer to keep up with our insanely fast processors, so we have to live with our boot time and loading bars.

Second, there is no reason to optimize the program, unless one is cost-cutting. Even then, high end flashlights may benefit from faster processors with more memory running unoptimized programs because of reduced development time. Besides, how much computation must be done? It's a flashlight, not a supercomputer.

 

[longboat]

OK, hardware isn't a problem, software shouldn't be too big of an issue, what about the interface (between computer and flashlight)? Mini-USB has been mentioned, but that takes some space and can be problematic for waterproof standards. Can there be some type of wireless electromagnetic communication between the devices (forget Bluetooth, that is way too unreliable)? Maybe some sort of active integrated transponder switches using RFID? Maybe some sort of audio communication (my universal remote can be programmed by holding it up to the telephone while a series of beeps programs it from the mfr. on the other end of the country)?

Hmmm, maybe mini-USB is best to start with as far as easily-useable, cheap and robust, despite its drawbacks...

 

[Locoboy5150]

So, my question is - will we ever see a true end-user-programmable UI? You know, the kind that uses a mini-USB cable which goes from the light to my computer, and then I can select EXACTLY the UI that I want.

I sure hope not as I think that computers control too much of society already. Yeah...I'm old school. I still prefer carburetors and none of my vehicles have EFI in them...thankfully!

 

[wyager]

OK, hardware isn't a problem, software shouldn't be too big of an issue, what about the interface (between computer and flashlight)? Mini-USB has been mentioned, but that takes some space and can be problematic for waterproof standards. Can there be some type of wireless electromagnetic communication between the devices (forget Bluetooth, that is way too unreliable)? Maybe some sort of active integrated transponder switches using RFID? Maybe some sort of audio communication (my universal remote can be programmed by holding it up to the telephone while a series of beeps programs it from the mfr. on the other end of the country)?

Hmmm, maybe mini-USB is best to start with as far as easily-useable, cheap and robust, despite its drawbacks...

Asynchronous serial... Easy to implement, easy to use. Most micros have a USART or at least a half-duplex UART. Even if they don't, a bit-bang protocol is just fine. USB is tricky and requires complex circuits... you can do it on an AVR, but it takes extra space and power.

 

[lolzertank]

If there is space, there could be an IR transreciever next to the main LED for IrDA. That would make things much simpler, but it would require a larger hole in the reflector for the main LED, IR LED and IR sensor. Seeing how most reflectors already have large holes to account for their focal length and the position of the LED, this could actually be practical.

Even the main LED could be used (as a light sensor as well as its primary function as a LED) with half duplex communication.

Both of these would preserve waterproofing and in the case of the 2nd one could be possible with only a driver swap.

 

[HKJ]

Asynchronous serial... Easy to implement, easy to use. Most micros have a USART or at least a half-duplex UART. Even if they don't, a bit-bang protocol is just fine. USB is tricky and requires complex circuits... you can do it on an AVR, but it takes extra space and power.

The problem with RS232 is that you need components to handle voltage outside the processor range and that many of the small micros used in flashlights does not have the serial hardware.

I still believe that the best solution is I2C or or SPI with a few contact points in the head around around the battery plus pole connection.

The a cable with a USB-I2C or USB-SPI chip that can be connected instead of the battery, when the light has to be programmed.

This would not change the production cost of the light, the cable and PC software could be sold as an extra that would work with many lights from the same manufacturer.