Need help to make a programmable timer... 1

[Marton79]

Basically, I'm bothering because I want to make a programmable timer...
Here is the figure:

The timer must have three buttons: Two of them add a different, programmable number of minutes to the count on each press. The third one resets the counter to 0. As long as the count is not 0, the output is 1.
It should have a 3 digit display to see the remaining minutes.
The number of minutes to add can be programmed with jumpers.

Do I need to use a pic to make this? I saw the 4510 is a nice candidate to do it, the problem is that the counter is not cumulative, it just resets to preset value...

Any ideas?

Thanks!!

 

[Skogsgurra]

Sorry to be such a bore - go for FORTH. It takes care of so many of the details. And it is a breeze to work with.

Gunnar Englund

http://www.gke.org

--------------------------------------
100 % recycled posting: Electrons, ideas, finger-tips have been used over and over again...

 

[itsmoked]

skogs you should know better! Only true acolytes of the True Way can utilize the Language.

Keith Cress
Flamin Systems, Inc.-

http://www.flaminsystems.com

 

[MikeHalloran]

I use FORTH when I can, but I don't tell anyone I'm using it, and I don't tell them that they should.

The _new_ One True Way is an ancient language, older than FORTH, that Bell Labs threw away because it was such a piece of Crap.

That other language has one magical property; full employment. If you want to pick one small hardware module and become _the_ programming expert for it, that third generation language is definitely the way to go, because after you've finished dividing the source for a 1k executable into 500 tiny files, with diabolically arranged dependencies, you will never get all the bugs out of it, and neither will anyone else, so they _can't_ let you go until they despair of ever fixing the product.

I don't want to even talk about its evil doppelganger- generating offspring.



Mike Halloran
Pembroke Pines, FL, USA

 

[itsmoked]

I C what you meaCn and I knCow of whaCt youC speCak ofCf.

Keith Cress
Flamin Systems, Inc.-

http://www.flaminsystems.com

 

[Skogsgurra]

Anyone met Charles More? Or Elisabeth Rather?

Gunnar Englund

http://www.gke.org

--------------------------------------
100 % recycled posting: Electrons, ideas, finger-tips have been used over and over again...

 

[MikeHalloran]

In person, no.



Mike Halloran
Pembroke Pines, FL, USA

 

[Skogsgurra]

I talked to Chuck over the phone once. I felt religious afterwards.

Gunnar Englund

http://www.gke.org

--------------------------------------
100 % recycled posting: Electrons, ideas, finger-tips have been used over and over again...

 

[MacGyverS2000]

USARTs are talking and listening... got it working yesterday, just in time to be told I need to port it over to a different dev. board Oy vey! At least I'm having fun

Dan - Owner

http://www.Hi-TecDesigns.com

 

[itsmoked]

Well!! What was the problem? You gonna keep us in suspense?

Keith Cress
Flamin Systems, Inc.-

http://www.flaminsystems.com

 

[richs]

Hiya Keith and Mike-

O.K. to get serious for just a bit, even though we are going way off topic. This is a real issue for me that I'm currently investigating.

I'm "filling in" my architecture tools. I've got a pretty good handle on the microcontrollers and the higher end stuff (big ARMs, uClinux, etc, etc). My "middle micros" (Z80s and 68Ks) are getting pretty long in the tooth.

Some of the smaller ARMs are a little to small to really run uclinux and require some significant secondary storage.

So, forth is/was an option for me. Also some of the small o/s stuff in Contiki for example.

I have a forth interpreter for the 68K, but it's written in assembly language. Ugh. Not too portable.

I'm starting to turn my attention to tiny TCL, avaliable at sourceforge. The claim is the interpreter is rommable to less than 60K. That would allow some of the small single chip ARM solutions to have it in their flash complete and still have room left over for other stuff. A simple serial interface to a usart can usually provide quite a bit of usefull information for a developer to diagnose problems. You don't need to have a tcl/tk package to run. Shoot I have a little VT100 terminal program on my PDA. That would be enough sometimes.

I too have C'en the light, but the thought of a compiler in an embedded system just doesn't thrill me. I suppose the laptop, compiling and downloading is an option, however, it seems fraught with peril especially when I want to "freeze" the state of the machine, goto a little interface and gather some data or run a small digester program. Don't want to reset the machine, bootstrap a program over serial, USB, or JTAG and then hope to have usefull information on the current state of the machine. Just a context switch to the TCL program.

If you've got a better solution, I'd like to hear it. These are just my thoughts. Maybe a seperate thread for this. I think that it shouldn't be in the tech tips section as this is geared for embedded systems, not general purpose computing. What 'da 'ya think?

Cheers,

Rich S.

 

[MacGyverS2000]

Keith,

'twas a couple of problems. The USARTs were incorrectly set to Tx/Rx MSB first, and the idle task was set to near-maximum priority. The dev. board uses a 10MHz crystal which divides/multiplies the PLL nicely up to a 180MHz internal clock. The new board was designed with an 18.43 somethin'-somethin' Mhz crystal, so finding a ratio that gives me exactly 180 again is going to be interesting (if even possible). If I can't find it, I'll have to change other portions of code, such as the comm stuff

Dan - Owner

http://www.Hi-TecDesigns.com

 

[itsmoked]

Thanks Dan.

Richs; you probably should've started a new thread.. This one is pretty beat up.

I am also not too sure really what your question is... <sorry> Yah got a bit'o rambling going on there.

I don't really see a lot of need for a 'bunch' of different platforms. Get good a the right ones and you 'think' in their colors.

So, someone comes to me and sez I need X built. I can immediately start seeing how to implement everything the project needs in the platform/s I'm skilled at. You know, where potential pit falls lay, where to capitalize, what is a problem, etc., etc. Focusing on fewer platforms also allows you to perhaps have better tools as your $$ are not spread all over.

I would say knowing one microcontroller family really well and one microprocessor family really well would serve most people the best. That way jobs not requiring a bunch of storage can use your uC and jobs that need a bunch of storage you use the uP. All jobs can then be covered with alacrity.

Of course someone may show up and say we want to do Y and we want you to use ColdFire or this specific DSP, then you do your best and get to explore a new realm.

PICs or Atmels(uC) and then ARMS or maybe Rabbits(inexpensive screaming z80s with networking)(uP) would be the sort of course I would sail.

I don't know if this is answering your question..

Keith Cress
Flamin Systems, Inc.-

http://www.flaminsystems.com

 

[Skogsgurra]

Dan,

As you know, there is a 4+ percent tolerance allowed in UART speed before communication has any real problems. So, if you get within 1 percent, you should not have any problems at all. Exact timing may be the difficult part. Especially if you are measuring speed and things like that.

Gunnar Englund

http://www.gke.org

--------------------------------------
100 % recycled posting: Electrons, ideas, finger-tips have been used over and over again...

 

[MacGyverS2000]

I'll be a monkey's uncle, a ratio does exist for that frequency. I wrote a snippet of code to run through all possible ratios of clock dividers and multiplers for the PLL, saving the one with the smallest error. No way I would have found it by hand, but it exists.


Dan - Owner

http://www.Hi-TecDesigns.com