More Arc5 information.. (proto photos inside)

[Carpe Diem]

Hi Peter...

Well...I`ve decided to make another career change. /ubbthreads/images/graemlins/tongue.gif

Rather than continue my 30+ years in the practice of law, I`ve decided I`m going to be one of these guys who writes this "code stuff" for your new flashlights. /ubbthreads/images/graemlins/thumbsup.gif

I got this inspiration after reading all of the above posts. It all seems so easy! I`m kicking myself for not making this career change earlier. /ubbthreads/images/graemlins/ohgeez.gif

I earlier thought...after watching Don making wonderful mods on his lathe...that I would instead become a machinist. I was all set to buy a "lathe thingy" (a big one...with a lot of knobs and dials...and, of course, a manual), but then I read this thread. Praise the Lord! I`ve now found my new calling. /ubbthreads/images/graemlins/thumbsup.gif

Give me a call, Peter, and I`ll gladly share my new "code stuff" ideas with you and the rest of the Arc family. /ubbthreads/images/graemlins/wink2.gif

Boy...

Is this going to be great, OR WHAT! /ubbthreads/images/graemlins/thumbsup.gif




PS: Just what part of the Arc flashlight does this "code stuff" go into? (Knowing the answer to that question will help me get up to speed more quickly.) /ubbthreads/images/graemlins/tongue.gif


/ubbthreads/images/graemlins/wink2.gif /ubbthreads/images/graemlins/grin.gif /ubbthreads/images/graemlins/grin.gif /ubbthreads/images/graemlins/thumbsup.gif /ubbthreads/images/graemlins/thumbsup.gif

 

[McGizmo]

Carpe,

As a concerned friend, how shall I put this......... /ubbthreads/images/graemlins/thinking.gif ........... Uh, don't quit your day job just yet.






/ubbthreads/images/graemlins/nana.gif

 

[Gransee]

You got it Carpe! Send me your resume. /ubbthreads/images/graemlins/smile.gif

The "code stuff" is put the blender with the memory juice to make the LED brownies.

Peter

 

[Carpe Diem]

Peter...
Thanks for your support...and for the recipe! /ubbthreads/images/graemlins/thumbsup.gif

I just knew this was going to be pretty easy. From now on, just call me the "Code Guy"! /ubbthreads/images/graemlins/wink2.gif (PS: Can I get a desk that`s near Trevor? And do I get another Arc uniform to wear?) /ubbthreads/images/graemlins/tongue.gif


Don...
Not to worry! I can always fall back on my machinist skills. Again...pretty easy stuff! /ubbthreads/images/graemlins/grin.gif
PS: How many knobs and dials do you have on your lathe. I just want to be sure I get a bigger one than you have. /ubbthreads/images/graemlins/tongue.gif (Kind of a "Viagra moment", if you will.) /ubbthreads/images/graemlins/grin.gif


Boy...

Is this going to be great, OR WHAT!



/ubbthreads/images/graemlins/grin.gif /ubbthreads/images/graemlins/grin.gif /ubbthreads/images/graemlins/thumbsup.gif /ubbthreads/images/graemlins/thumbsup.gif

 

[BuddTX]

Important tip:

When writing code, DO NOT use a spell checker! /ubbthreads/images/graemlins/icon15.gif

Here is a guy who writes LOTS of pure assembly language:

Steve Gibson Research Corporation

 

[MY]

Carpe.

I reread your post and noticed after much thought that it must be written in some type of code.

This reminds me of a law professor years back who said that if you don't already know the answer before you ask the question, you might as well be talking in a code language. As such, I am not sure whether the real question is where the code stuff goes but how to stuff the code.

Regards.

 

[Carpe Diem]

Hi MY...

Those are some truly deep thoughts you`ve expressed. /ubbthreads/images/graemlins/thumbsup.gif (And this is one of those times where I really wish I was bright enough to understand what you`re saying.) /ubbthreads/images/graemlins/grin.gif

Gotta go now, though...
I`m pretty busy, after all, with all of this new "code stuff"!

/ubbthreads/images/graemlins/smile.gif /ubbthreads/images/graemlins/grin.gif

 

[Foss]

The ongoing discussion is very technical. Regardless, here is my input for the ARC 5 (more along the lines of practical matters); 1) If possible have the light tested and rated intrinsically safe. 2) Make a lock-out switch so no in-advertant powering (unsure if the 4 has that feature - I have the LS and really LIKE w/ the exception of the un-intentsional discharge) 3) Make sure it's rated water resistant to at least one atmosphere (33ft) 4) Shock resistant, and 5) Finally; small size. If it could be shorter or equal to the lenght of a LS (with clickie) and no larger in diameter than the light would be of perfect dimensions.

I use my light for practical matters at work. So all of the modes and programming wouldn't be very important to me. More of a toy and gimmick.

In closing; it would be nice to have a couple of power levels so the user could determine the life of the battery or level of light needed in the type of environment. I can manually operate the switch to do pretty much anything that programming could do. (With perhaps the exception of the strobe feature. That might be handy for distress or getting a persons/ship/aircraft's attention). A clip on the light is a very handy feature for options to carry.

Let me know what you think.

 

[Photonian]

My Ideas for a Better Arc 5

I think the clip should be attached with button head Allen screws rather than the Phillips head screws Arc is currently using. Phillips head screws are so yesterday.

I replaced the screws on my Arc4 and now I'm very popular and a big hit with the opposite sex.

 

[jeryray]

request timer option for arc 5

 

[NewBie]

Humm, I've had my ARC4 accidentally turn on several times now, on accident, and the switch makes it difficult for me to do all these sequences. I carry mine on my belt. I changed the orientation to a diagonal on my belt, instead of straight up and down, and still have the issue. So a mechanical method of preventing turn on, would be most welcome.

Lets see, C and Assembler. When compiled, the machine code running on the flashlight is in the same language. If the ATMEL AVR RISC chip was used, it was optimized for a C compiler. Humm, a person could de-compile the compiled C code, a simple task for any kiddo hacker. Then just follow the C code, and program it Assembler. Lines blur between unique and sanitized, especially if they perform the same function. Now, if the code makes the flashlight do the same thing, is it new, or just a "copy"?

Still remains the issue of the implementation in electronics, being the same for the converter, the code is just a small piece. For protection of the design, a few simple changes, in parts, doesn't matter, it is more in the topology utilized. Are the electronics undergoing overhaul too?

So, I guess my question is, is the ARC5 going to be wholly different software, both to the user and how it makes the converter work inside, and is it a new converter also?

[ QUOTE ]
Gransee said:
Newbie, this was suggested when the Arc4 was in dev. The problem was the code was so large there was no room left for any new features. We are changing that with the new code but there are features planned that are more important and will use up the extra space. When things catch up, we may make a version of the code that allows user interface. We would then provide some notes on how to build your own interface. Or you may be able to buy it from us for $200 (we might sell a grand total of 5 and the engineers need to get paid for producing custom interface hardware).


If the interface is connected to a newer Arc (if version completed), you would get a simple ANSI terminal (like a BBS) type menu that would let you change the primary level, operating mode, etc. This would be another way to access the advanced menu (the first method is by using the button). There may even be some extra stuff like a run time meter, ESN, Owner name, etc. If someone wanted, they could build a software GUI that converts the serial protocol to a nice applet with check boxes, etc.

Peter

[/ QUOTE ]

Well, I'd be more than willing to put together something, with contruction details for everyone, if you are programming via the microcontroller RS-232 port, that most use. All it requires is a simple chip to go from your Comm port 232 to the microcontroller pins. If you are programming via a JTAG port, it is a tiny bit more complicated. Now that I think about it, I might be talked into providing a built up 232 board, since it would be so simple to do, the time involved is nearly a non-issue.

 

[Gransee]

Newbie, Yes, different hardware and software. This needs to happen because of the increased power and new features listed earlier.

When we are at that point, I will remember your offer to help with a serial interface.

Thanks again.

Peter

 

[Mr. Blue]

code? code? code you say? I o-nay ig-pay atin-lay! all-cay e-may Eter-pay.

 

[Canuckle]

Decoded: I no[know] Pig Latin. Call me Peter.

 

[MisterEd]

[ QUOTE ]
Here is a guy who writes LOTS of pure assembly language:

Steve Gibson Research Corporation

[/ QUOTE ]

Sigh, lets leave Steve Gibson out of this /ubbthreads/images/graemlins/smile.gif

Assembly programming does have its place, and packing all kinds of features into a tiny uC is one place where it might make sense. On desktop class processors though the compiler can often actually do a better job than an average assembly programmer.

 

[absoLite]

Right, and one needs to be one hell of an assembler programmer to beat the optimization of a good C compiler.
If I would have to maintain, change or debug the code, especially maybe with different programmers, I would with no doubt choose C.

But I suppose there is some assembler code needed anyway when directly adressing hardware as it is presumably done in those lights. So maybe if the program itself can be kept small, why not do it in assembler as a whole, provided the code documentation is very good.

Either one can be the right choice, if the outcome is an adaptable, easy to be maintained piece of code.

 

[PeLu]

[ QUOTE ]
absoLite said:Right, and one needs to be one hell of an assembler programmer to beat the optimization of a good C compiler.

[/ QUOTE ]

absolitely .-) This is also my experience from the last 25+ years. I think people should not have too high hopes in the gain. And there will be probably some code left out in the newer versions. Who needs a discharge protection for chemistries/combinations where you don't have the physical possibilities to use them?

I think that we should be more than happy that we have such a troublefree software version available .-)

[ QUOTE ]
If I would have to maintain, change or debug the code, especially maybe with different programmers, I would with no doubt choose C.

[/ QUOTE ] exactly. I would just take as much as possible from the existing code then, just remove the unwanted parts.

 

[mattheww50]

that is well and good, but frankly it is usually less expensive to just up the fire power on the processor, than debug and maintain the assembler code. IF you are going to make 5,000 of them, spending an extra $1 or $2 on a faster engine is usually peanuts compared to the costs of writing and support and assembler application.

For example going from 8mhz 8088 to a 12Mhz 80286 could hide an amazing number of sins, and incredibly poor code. The manufacturers have gotten pretty good a putting very hot cpu cores into cheap controller engines.

 

[alanhuth]

If you want to make a small kernel and still have a tty interface to an interpreter, then FORTH is one way to go. It's been around for a long time and some programmers are excellent. People either love it or hate it, but it's very compact and it gives the user the chance to go in, with just a tty serial port and have full control. With a good programmer, it is not uncommon for a forth kernel, complete with interpreter, assembler, compiler, and interface, to be as small or smaller than an assembly program. It's just a little slower (but you can hand-code repetitive code in assembly to speed it up).

 

[gadget_lover]

[ QUOTE ]
absoLite said:
Right, and one needs to be one hell of an assembler programmer to beat the optimization of a good C compiler.
If I would have to maintain, change or debug the code, especially maybe with different programmers, I would with no doubt choose C.



[/ QUOTE ]

As a programmer, I have to point out that this is drastically over simplified. A Properly written C program with a good compiler will frequently generate good, tight code. So will a properly written program in assembler. Either way you need a skilled programmer to keep it small.

A common mistake in C is to use small, efficient functions that call other functions that are much bigger. The same problem arises in macro assemblers as well. It's a huge problem with C++.

So choose the language based on the hardware you want to use and the talent pool available. As long as you require fully commented code and proper design docs, both are equally maintainable.

Daniel