AVRs with accurate internal clocks

Go To Last Post
55 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 

I need it to send a accurately send a pulse every second for 1200 seconds when a button is pressed. I am ok with +-12s. I am looking at pin count greater than 14.

Is this possible to achieve using the internal oscillators? If yes, which AVRs have accurate clocks?

 

Thanks

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Is this possible to achieve using the internal oscillators? If yes, which AVRs have accurate clocks?

over what temperatures?  Alaska?  Phoenix?   Generally, yes to your question.  You can /should easily calibrate it out anyhow---you can tweak your timer OCR values (stored desired settings in EEPROM), for example.  That may be simpler than messing with the  osc cal byte, since OCR value is easily software written.

  The hard part is accounting for drift & there are some avr's that handle that as well. 

send a pulse every second for 1200 seconds when a button is pressed.

Who wants to hold a button for 1200 seconds?  Be clear in your requirements. 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

Last Edited: Sat. Aug 1, 2020 - 07:26 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

avrcandies wrote:

over what temperatures?  Alaska?  Phoenix?   Generally, yes to your question.  You can /should easily calibrate it out anyhow---you can tweak your timer OCR values (stored desired settings in EEPROM), for example.  That may be simpler than messing with the  osc cal byte, since OCR value is easily software written.

  The hard part is accounting for drift & there are some avr's that handle that as well. 

 

Great! Which AVR handle it well? How can I know? Most AVR datasheet I read do not specify the accuracy of internal clocks.

 

avrcandies wrote:
Who wants to hold a button for 1200 seconds?  Be clear in your requirements. 

When a button is pressed, the user need not hold it. 

When a start button is pressed, for the next 1200s the microcontroller sends a signal every second and a stop button is pressed before 1200s, the timer is reset and does not run again until the start button is pressed again.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

1200 seconds +- 12 seconds is +-1%

All modern AVRs possess internal RC clocks.   You can calibrate them to be within +- 0.5%

 

Every AVR datasheet gives typical graphs for the Internal RC oscillator for temperature and voltage variations.

 

Simple answer is:   Calibrate RC for +-0.5% and it should remain within +-1% in an office environment power by mains.

 

If you are battery powered in the desert sun,   use something better e.g. external clock or XTAL.

Since your human button pusher has 20 minutes to live,   I guess that the environment is not too hostile.

 

David.

Last Edited: Sat. Aug 1, 2020 - 07:58 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The datasheets do specify the accuracy. For the older devices it is around +/-10% over voltage and temperature.
You need to specify what accuracy you would like. More accuracy = more money. So don’t say very accurate -that means nothing. 1second +/- a percentage means something.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

david.prentice wrote:

1200 seconds +- 12 seconds is +-1%

All modern AVRs possess internal RC clocks.   You can calibrate them to be within +- 0.5%

 

Every AVR datasheet gives typical graphs for the Internal RC oscillator for temperature and voltage variations.

 

Simple answer is:   Calibrate RC for +-0.5% and it should remain within +-1% in an office environment power by mains.

 

If you are battery powered in the desert sun,   use something better e.g. external clock or XTAL.

Since your human button pusher has 20 minutes to live,   I guess that the environment is not too hostile.

 

David.

 

Thank You! 

 

Kartman wrote:
The datasheets do specify the accuracy. For the older devices it is around +/-10% over voltage and temperature. You need to specify what accuracy you would like. More accuracy = more money. So don’t say very accurate -that means nothing. 1second +/- a percentage means something.

 

I gave it in my first post.  I am ok with +/- 12s in the 1200s. So that's 1%.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The +-10% is the factory accuracy.

 

You can calibrate to a better accuracy at a fixed temp and voltage.   But the worst case temperature and voltage will be no good for the "older" Mega and Tiny.

 

The newer XTiny or Mega-0 chips have better worst cases.

 

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

uCnoob wrote:
 Most AVR datasheet I read do not specify the accuracy of internal clocks. 

 

 

For example:

 

The truth is more important than the facts.

Last Edited: Sat. Aug 1, 2020 - 09:42 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I doubt that OP want to use the 32KHz clk !

 

In general the new chips has clk that can't meet 1% out of the box, but can be calibrated to be there or close. But if you need to get into calibration I would just measure the speed it actually run at, and use that for your time, that way you can calibrate your timer with way better. But as said before that is only at one voltage and temperature. 

 

Many chips can run the cpu from a high speed internal osc. but at the same time use a 32768 Hz watch crystal for a timer, and that will meet your requirement without calibration.

 

Take  a look at the selector table at microchip.   

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

to achieve using the internal oscillators

Why are you opposed to supplying an accurate xtal???...then essentially no issue!!

Note as mentioned in #2 you can cal either the internal osc or your timer setting (or both!).   You can probably get there with the internal, but it will be much more work to verify over temperature, etc.  

What is your opinion/reason?  Make it good!

 

my point here:  send a pulse every second for 1200 seconds when a button is pressed was:

  you could mean only during the pressing of the button, so if you lift up, it halts.

 

  

 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

Last Edited: Sat. Aug 1, 2020 - 11:16 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


uCnoob wrote:
Most AVR datasheet I read do not specify the accuracy of internal clocks

Don't they??

 

Choosing one at random:

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am curious about the more-than-14 pin count requirement. I suppose there are other app requirements? But why pin count and not eg usable gp I/O pins?

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello uCnoob -

 

You need to be a little more aware of what the current state of "accurate" is.

 

Off the shelf, most older AVRs are spec'd at 5-8% clock frequency tolerance. In most applications, they are somewhat better tnan this because this number applies over the  full device temperture span. Close to 25C, they tend to be sort of 3-5%.

 

Now, compare this with a bog-standard watch crystal. Room temperature specs tend to be around +/-30ppm. That is +/-0.003%. Just solder it (with the  right caps) and go). A standard "microprocessor crystal" tends to be a few hundred ppm (say, +/- 0.05%) pr so. Again, solder it, with the right caps and go. Many AVRs have an internal oscillator circuit designed to work with an external watch crystal and no external caps.

 

UARTS tend to need about 2% accuracy to communicate together. 

 

Wrist watches tend to be 5-10ppm, in part, because the temperature on a human wrist is quite stable.

 

The internal 32.768KHz clock of the new mega-0 chips has been described above.

 

So, this should give you a better sense of what "accurate" means in the microcontroller world and what the resources are for achieving the accuracy you need.

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

uCnoob wrote:

I need it to send a accurately send a pulse every second for 1200 seconds when a button is pressed. I am ok with +-12s. I am looking at pin count greater than 14.

Is this possible to achieve using the internal oscillators? If yes, which AVRs have accurate clocks?

As a broad general rule, the newer MCUs have better tempcos than the older ones. (As you would hope, as they get better at design and drift compensation.)

 

uCnoob wrote:

Most AVR datasheet I read do not specify the accuracy of internal clocks.

 

Then you are reading the wrong ones :) - see above examples.

 

You will need to trawl the data sheets, IIRC some AVRs also store tempos as %/°C, and they will define the %/Step on the adjust. 

 

If you are happy with room temperature level performance, a simple single point post-reflow-calibrate will likely be ok.

If you need wider range, two point calibrate with temperature capture design would be needed.

 

That leaves you with long term drift.

 

As well as crystals mentioned above, there are also ceramic resonators and the better (newer) ones there are ones like these

CSTNE8M00GH5L000R0    Murata Electronics    CERAMIC RES 8.0000MHZ 33PF SMD   Frequency Stability  ±0.11%    Frequency Tolerance ±0.07%

 

Those will easily meet your spec.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Not forget he only wants

uCnoob wrote:
I gave it in my first post.  I am ok with +/- 12s in the 1200s.

This can already be achieved with the most imprecise controller-clock using a simple timer-interrupt.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 

With the advances in everything, it seems like the resonator days are closer to over...good xtals, used to be $$, now accurate xtals are dirt cheap

note    0.11% is 1100 ppm ,  0.07% is 700ppm

 

xtal...half the cost and 22x better

 

 

For a few cents more than the resonator, you can get  a 110x stability & 70x freq tolerance improvement

 

 

 

 

 

 

 

 

 

 

 

 

 

 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

Last Edited: Sun. Aug 2, 2020 - 06:53 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

david.prentice wrote:

The +-10% is the factory accuracy.

 

You can calibrate to a better accuracy at a fixed temp and voltage.   But the worst case temperature and voltage will be no good for the "older" Mega and Tiny.

 

The newer XTiny or Mega-0 chips have better worst cases.

 

David.

 

Thank You, I will read up on the calibration part.

 

poftamunk wrote:

uCnoob wrote:
 Most AVR datasheet I read do not specify the accuracy of internal clocks. 

 

 

For example:

 

 

Thank You, I was able to find the graphs in the data sheet.

 

The above graph is for ATmega808, the variation in frequency is from 19.8 to 20.1 in the entire temperature range, assuming 19.95 as the mid-point, its close to 0.76% accuracy, am I righT?

 

sparrow2 wrote:

I doubt that OP want to use the 32KHz clk !

 

In general the new chips has clk that can't meet 1% out of the box, but can be calibrated to be there or close. But if you need to get into calibration I would just measure the speed it actually run at, and use that for your time, that way you can calibrate your timer with way better. But as said before that is only at one voltage and temperature. 

 

Many chips can run the cpu from a high speed internal osc. but at the same time use a 32768 Hz watch crystal for a timer, and that will meet your requirement without calibration.

 

Take  a look at the selector table at microchip.   

avrcandies wrote:

to achieve using the internal oscillators

Why are you opposed to supplying an accurate xtal???...then essentially no issue!!

Note as mentioned in #2 you can cal either the internal osc or your timer setting (or both!).   You can probably get there with the internal, but it will be much more work to verify over temperature, etc.  

What is your opinion/reason?  Make it good!

 

my point here:  send a pulse every second for 1200 seconds when a button is pressed was:

  you could mean only during the pressing of the button, so if you lift up, it halts.

 

  

 

 

I was looking at the ATmega808 since it is easier to use it with the Arduino ecosystem. The arduino library for that mcu, stated it cannot drive an external crystal or resonator. So, I decided to stick with the internal oscillator.

 

awneil wrote:

uCnoob wrote:
Most AVR datasheet I read do not specify the accuracy of internal clocks

Don't they??

 

Choosing one at random:

 

 

I couldn't it in the chips I looked at, ATmega808 being one.

 

theusch wrote:
I am curious about the more-than-14 pin count requirement. I suppose there are other app requirements? But why pin count and not eg usable gp I/O pins?

 

My bad, I meant GPIO pins. 

 

ka7ehk wrote:

Hello uCnoob -

 

You need to be a little more aware of what the current state of "accurate" is.

 

Off the shelf, most older AVRs are spec'd at 5-8% clock frequency tolerance. In most applications, they are somewhat better tnan this because this number applies over the  full device temperture span. Close to 25C, they tend to be sort of 3-5%.

 

Now, compare this with a bog-standard watch crystal. Room temperature specs tend to be around +/-30ppm. That is +/-0.003%. Just solder it (with the  right caps) and go). A standard "microprocessor crystal" tends to be a few hundred ppm (say, +/- 0.05%) pr so. Again, solder it, with the right caps and go. Many AVRs have an internal oscillator circuit designed to work with an external watch crystal and no external caps.

 

UARTS tend to need about 2% accuracy to communicate together. 

 

Wrist watches tend to be 5-10ppm, in part, because the temperature on a human wrist is quite stable.

 

The internal 32.768KHz clock of the new mega-0 chips has been described above.

 

So, this should give you a better sense of what "accurate" means in the microcontroller world and what the resources are for achieving the accuracy you need.

 

Jim

Hello Jim,

Thank you for the explanation. 

 

Who-me wrote:

uCnoob wrote:

I need it to send a accurately send a pulse every second for 1200 seconds when a button is pressed. I am ok with +-12s. I am looking at pin count greater than 14.

Is this possible to achieve using the internal oscillators? If yes, which AVRs have accurate clocks?

As a broad general rule, the newer MCUs have better tempcos than the older ones. (As you would hope, as they get better at design and drift compensation.)

 

uCnoob wrote:

Most AVR datasheet I read do not specify the accuracy of internal clocks.

 

Then you are reading the wrong ones :) - see above examples.

 

You will need to trawl the data sheets, IIRC some AVRs also store tempos as %/°C, and they will define the %/Step on the adjust. 

 

If you are happy with room temperature level performance, a simple single point post-reflow-calibrate will likely be ok.

If you need wider range, two point calibrate with temperature capture design would be needed.

 

That leaves you with long term drift.

 

As well as crystals mentioned above, there are also ceramic resonators and the better (newer) ones there are ones like these

CSTNE8M00GH5L000R0    Murata Electronics    CERAMIC RES 8.0000MHZ 33PF SMD   Frequency Stability  ±0.11%    Frequency Tolerance ±0.07%

 

Those will easily meet your spec.

Thank You. 

 

Would it be easier for  a beginner to interface a external crystal/resonator than trying to calibrate the internal oscillator? Can the 808's drive a external crystal/resonator?

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

avrcandies wrote:

With the advances in everything, it seems like the resonator days are closer to over...good xtals, used to be $$, now accurate xtals are dirt cheap

note    0.11% is 1100 ppm ,  0.07% is 700ppm

xtal...half the cost and 22x better

 

For a few cents more than the resonator, you can get  a 110x stability & 70x freq tolerance improvement

As always, it's a trade off. The cheapest crystals are significantly larger than the resonators, and they need two more caps, adding to BOM and placement costs. 

That's why resonators are not dead yet...

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

uCnoob wrote:

Would it be easier for  a beginner to interface a external crystal/resonator than trying to calibrate the internal oscillator? Can the 808's drive a external crystal/resonator?

Data sheets are your friends.

Did you open the 808 data and search for Crystal ? 

 

That shows the 808 family supports a 32.768kHz crystal, which you can directly use for timekeeping, and avoid any calibrate needs.

 

Even if you do arrange calibrate of the internal RC, with no crystal, you still have long term drift you cannot compensate for. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

GermanFranz wrote:
Not forget he only wants
uCnoob wrote:
I gave it in my first post.  I am ok with +/- 12s in the 1200s.
This can already be achieved with the most imprecise controller-clock using a simple timer-interrupt.

Timer Interrupt? I will read about it.

 

avrcandies wrote:

 

With the advances in everything, it seems like the resonator days are closer to over...good xtals, used to be $$, now accurate xtals are dirt cheap

note    0.11% is 1100 ppm ,  0.07% is 700ppm

 

xtal...half the cost and 22x better

 

 

For a few cents more than the resonator, you can get  a 110x stability & 70x freq tolerance improvement

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Who-me wrote:

uCnoob wrote:

Would it be easier for  a beginner to interface a external crystal/resonator than trying to calibrate the internal oscillator? Can the 808's drive a external crystal/resonator?

Data sheets are your friends.

Did you open the 808 data and search for Crystal ? 

 

That shows the 808 family supports a 32.768kHz crystal, which you can directly use for timekeeping, and avoid any calibrate needs.

 

Even if you do arrange calibrate of the internal RC, with no crystal, you still have long term drift you cannot compensate for. 

 

Great, I will use a crystal then. 

 

I feel I haven't explained my use case properly in the first post. Here it is:

There are two buttons start and stop. When start button is pressed, the MCU should turn the relay ON and hold it in that state for 1200s or until stop button is pressed whichever is earlier. I read MCUs tend to be inaccurate in timing only over larger periods. Am I over engineering if all I want to do is - Switch ON a relay for 1200s. Again, +-12s is what I am trying to achieve 

Last Edited: Sun. Aug 2, 2020 - 09:41 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

uCnoob wrote:
 Thank You, I was able to find the graphs in the data sheet.

The above graph is for ATmega808, the variation in frequency is from 19.8 to 20.1 in the entire temperature range, assuming 19.95 as the mid-point, its close to 0.76% accuracy, am I righT? 

 

Yes, the OSC20M is quite accurate (for an RC oscillator).

 

Do you intend to work in the whole temperature range?

 

For long term applications you can use an external 32768Hz crystal oscillator.

 

 

The truth is more important than the facts.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Your requirement is +/- 1%. That's close to the spec of the chip (assuming +/-1% for the micro).

What temperature range do you expect your device to work in? Eg: many of my designs swelter at 70C for 8+ hours a day in the middle east and when the sun sets, the temperature plummets. It might be automotive where the temperature could be less than 0 in winter and 70C in the cabin in summer.

 

Is there a cost constraint?

Is there a size constraint?

Is there high vibration , acceleration or shock?

 

Or you might just say, stuff it and add a crystal or external oscillator and avoid the tolerance problem. How many problems do you want to tackle??

Put it another way, the average microwave oven has a resonator or crystal for its micro.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes,  you are over engineering.

 

The Internal RC will be plenty good enough for this sort of use.

It sounds like a courtesy light on a staircase or your bedside clock-radio going to sleep.

 

I doubt if +- 12 seconds would be noticed.   Or even +- 30 seconds.

 

However,  if you were controlliing a V1 flying bomb the navigation accuracy would be important.

I don't know whether the original V1 used a timer or the pulse-jet just ran out of fuel.

 

I am sure that a mega808 would be fine.   It can use an external clock.   It can't use a HF crystal or resonator.

Older chips have less accurate RC but more flexible clock options.

 

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

uCnoob wrote:
There are two buttons start and stop. When start button is pressed, the MCU should turn the relay ON and hold it in that state for 1200s or until stop button is pressed whichever is earlier. I read MCUs tend to be inaccurate in timing only over larger periods. Am I over engineering if all I want to do is - Switch ON a relay for 1200s. Again, +-12s is what I am trying to achieve 

The internal clock is completely sufficient for your application.
There is definitely no need for any crystal or resonator.
+-12s @ 1200s are much leeway for any inaccuracies. Even if an internally generated seconds cycle would become too imprecise, you could easily readjust it one time.

The task is usually solved with a timer interrupt.
Then you can do many other useful things in between.
Let this interrupt count down a variable to zero in 1,10 or 100 seconds steps. Variable= 0 -> Relay OFF, Variable <>0 -> Relay ON.
Your start button loads the variable with the maximum time, your stop button sets the variable zero. Depending on the controller, there are really many options for implementation.

Last Edited: Sun. Aug 2, 2020 - 10:37 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

When start button is pressed, the MCU should turn the relay ON and hold it in that state for 1200s

What if the start button is held down for 300 seconds...is any effect desired?

What if the start button is pushed 200 seconds after the start....is any effect desired?

 

Either of these may have no effect, or some effect, as desired....but you should not forget considering them.

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

avrcandies wrote:

When start button is pressed, the MCU should turn the relay ON and hold it in that state for 1200s

What if the start button is held down for 300 seconds...is any effect desired?

What if the start button is pushed 200 seconds after the start....is any effect desired?

One could interpret this as a conscious decision to start the cycle permanently or not to let it end. This could be an additional feature if wanted 😏

Should the cycle run strictly, the variable may only be reloaded from Start-Button if it is zero (in proposed solution) ...

Last Edited: Sun. Aug 2, 2020 - 11:36 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

poftamunk wrote:

uCnoob wrote:
 Thank You, I was able to find the graphs in the data sheet.

The above graph is for ATmega808, the variation in frequency is from 19.8 to 20.1 in the entire temperature range, assuming 19.95 as the mid-point, its close to 0.76% accuracy, am I righT? 

 

Yes, the OSC20M is quite accurate (for an RC oscillator).

 

Do you intend to work in the whole temperature range?

 

For long term applications you can use an external 32768Hz crystal oscillator.

 

 

 

Thank you. The device will be put in a home environment. The place where I live temperatures can 30-35 deg C during summer. I am worried about the PCB temperature, the power supply will be on the same board as the Micro. I guess the it can in increase the temperature.

By long term do you mean for long timing applications or long life cycle?

 

Kartman wrote:

Your requirement is +/- 1%. That's close to the spec of the chip (assuming +/-1% for the micro).

What temperature range do you expect your device to work in? Eg: many of my designs swelter at 70C for 8+ hours a day in the middle east and when the sun sets, the temperature plummets. It might be automotive where the temperature could be less than 0 in winter and 70C in the cabin in summer.

 

Is there a cost constraint?

Is there a size constraint?

Is there high vibration , acceleration or shock?

 

Or you might just say, stuff it and add a crystal or external oscillator and avoid the tolerance problem. How many problems do you want to tackle??

Put it another way, the average microwave oven has a resonator or crystal for its micro.

 

 

Thank you. The ambient temperatures less than 40C and the device will be used only for a brief amount of time - 1hr continuous at max. There are no size or high vibration constraints. I would like to keep the costs minimal.

That's a great question.. I am not very experienced and I would like to keep the problems I need to tackle less. If adding a crystal will be the cheapest and reliable, I would stick with. 

 

david.prentice wrote:

Yes,  you are over engineering.

 

The Internal RC will be plenty good enough for this sort of use.

It sounds like a courtesy light on a staircase or your bedside clock-radio going to sleep.

 

I doubt if +- 12 seconds would be noticed.   Or even +- 30 seconds.

 

However,  if you were controlliing a V1 flying bomb the navigation accuracy would be important.

I don't know whether the original V1 used a timer or the pulse-jet just ran out of fuel.

 

I am sure that a mega808 would be fine.   It can use an external clock.   It can't use a HF crystal or resonator.

Older chips have less accurate RC but more flexible clock options.

 

David.

Thank you. Yes, 10-15s of extra delay won't cause any catastrophe or even a mild injury. I just felt that it would be nice to keep the timing uniform. :)

 

GermanFranz wrote:
uCnoob wrote:
There are two buttons start and stop. When start button is pressed, the MCU should turn the relay ON and hold it in that state for 1200s or until stop button is pressed whichever is earlier. I read MCUs tend to be inaccurate in timing only over larger periods. Am I over engineering if all I want to do is - Switch ON a relay for 1200s. Again, +-12s is what I am trying to achieve 
The internal clock is completely sufficient for your application. There is definitely no need for any crystal or resonator. +-12s @ 1200s are much leeway for any inaccuracies. Even if an internally generated seconds cycle would become too imprecise, you could easily readjust it one time. The task is usually solved with a timer interrupt. Then you can do many other useful things in between. Let this interrupt count down a variable to zero in 1,10 or 100 seconds steps. Variable= 0 -> Relay OFF, Variable <>0 -> Relay ON. Your start button loads the variable with the maximum time, your stop button sets the variable zero. Depending on the controller, there are really many options for implementation.

Thank you. Timer interrupt is  a great idea. I will look into how to implement it.

 

avrcandies wrote:

When start button is pressed, the MCU should turn the relay ON and hold it in that state for 1200s

What if the start button is held down for 300 seconds...is any effect desired?

What if the start button is pushed 200 seconds after the start....is any effect desired?

 

Either of these may have no effect, or some effect, as desired....but you should not forget considering them.

Thank You. I am still thinking of and noting down edge cases. But they shouldn't have any effect.

 

GermanFranz wrote:

One could interpret this as a conscious decision to start the cycle permanently or not to let it end. This could be an additional feature if wanted 😏

Should the cycle run strictly, the variable may only be reloaded from Start-Button if it is zero (in proposed solution) ...

 

Thank you again. That's a nice tip

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

uCnoob wrote:
 By long term do you mean for long timing applications or long life cycle? 

 

Sorry, certainly long timing. 
If you would like to get a time period of e.g. exactly 1 hour (±1s), then an external oscillator would be indispensable.

The truth is more important than the facts.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

poftamunk wrote:

uCnoob wrote:
 By long term do you mean for long timing applications or long life cycle? 

 

Sorry, certainly long timing. 
If you would like to get a time period of e.g. exactly 1 hour (±1s), then an external oscillator would be indispensable.

Got it. But the maximum I am looking at is 1200s or 20mins

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It turns out that interpreting the state of pushbutton switches is more complex than it might at first seem, if you want to cover all eventualities and only respond to precise situations.

 

I wrote an Arduino class that enables me to write logic like "if the switch state has changed AND the switch is released AND the previous state time was between 100ms and 1000ms, ..."

 

e.g.

if (switchA.stateChanged() && !switchA.isPressed() && switchA.getLastStateDuration() > 100 && switchA.getLastStateDuration() < 1000) {
    new_state = (current_state == STATE_IDLE) ? STATE_TRACK_FWD : STATE_IDLE;
}

The class uses either interrupts or polling, and the standard Arduino millis() timer. The 100ms check handles debouncing.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

obdevel wrote:

It turns out that interpreting the state of pushbutton switches is more complex than it might at first seem, if you want to cover all eventualities and only respond to precise situations.

 

I wrote an Arduino class that enables me to write logic like "if the switch state has changed AND the switch is released AND the previous state time was between 100ms and 1000ms, ..."

 

e.g.

if (switchA.stateChanged() && !switchA.isPressed() && switchA.getLastStateDuration() > 100 && switchA.getLastStateDuration() < 1000) {
    new_state = (current_state == STATE_IDLE) ? STATE_TRACK_FWD : STATE_IDLE;
}

The class uses either interrupts or polling, and the standard Arduino millis() timer. The 100ms check handles debouncing.

 

Great Thanks.

 

I am planning to use capactitive touch buttons, either using MTCH105 or CAP1206. I am also considering the ATtiny817 since it offers PTC with no extra hardware. Debouncing, shouldn't be a problem.

 

This is the ATtiny 817's osc graph:

 

The chip seems to be more accurate than the 808 over the entire temperature range and it also comes with a PTC that cuts down the requirement for a separate touch controller. Only downside being, sticking to the Atmel studio if I want to use the Qtouch library. Would this chip be a better choice over the 808?

 

Thanks 

 

Edit: The attiny817 has fewer GPIO pins than the atmega808. I will be interfacing this 7 seg LED which uses the most pins(16). Can I cut down on the pins if I don't need the dots(I would need the colon) and the first digit will always either be a 0 or 1(the g segment on D1 will never be used). On a different thread, many suggested that I use charlieplexing, I read about it and I feel its a bit complex to implement for me rn.

Last Edited: Sun. Aug 2, 2020 - 01:51 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

For the short time & restricted temperature , you don't need to do much...you can just change the clock cal (if needed), or change the timer setting slightly...depends on what you have to measure timings (you prob don't wan to wait 20 min & say oh that was 78 sec too slow, let's adjust...or maybe that's an ok proceedure).   Are you making 1 unit ? 10 units? 10000 units?

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

avrcandies wrote:

For the short time & restricted temperature , you don't need to do much...you can just change the clock cal (if needed), or change the timer setting slightly...depends on what you have to measure timings (you prob don't wan to wait 20 min & say oh that was 78 sec too slow, let's adjust...or maybe that's an ok proceedure).   Are you making 1 unit ? 10 units? 10000 units?

Thank you.

You mean I can stick with 808? I am interested in the 817 because it offers cap touch sensing capabilities without any extra hardware. Also, going by the graph, I think the tiny817 is more accurate than the 808, correct me if I am wrong.

I am working on a 10 unit prototype, if all goes well, I will start with 500units.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 

I had e quick look at the 808 datasheet and it actually have a register there tell the calibrated error :

 

The idea with this is to make sure that the BAUD rate is within spec but can of course also be used for timing in general.(that give a resolution of 0.1% or 0.25% I'm not sure depends where the 8 bit isplaced! it's 0.1% I guess).

So after all I guess that you can get within 1% without any calibration (microchip has done it all for you) 

 

Add:

Does anyone know what they mean with compressed  Q1.10 ?

Last Edited: Sun. Aug 2, 2020 - 05:28 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Though they do not appear to apply to OP,

there can be sensible reasons for avoiding an external crystal,

even on a one-off.

One might want to breadboard the circuit.

My recollection is that breadboards and crystals are not a good match.

OP might be lousy at soldering and simply want to reduce the pin count.

How hard would it be for a Mr. Magoo to destroy a crystal with a soldering iron?

 

That said, calibrating can be a significant issue.

At some point, would have to use a clock with sufficient accuracy.

Moving the device from that point to where it is used

might destroy the calibration.

In the case of a device that almost works out of the box,

environment-matching would not be much of an issue.

 

All that said, the chosen solution seems to be the right one.

No only does a crystal work,

knowing that it works is easier than with any other solution.

Iluvatar is the better part of Valar.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

>Does anyone know what they mean with compressed  Q1.10 ?

 

In this case its simply a signed 8bit value that gives the fraction amount of a 10bit value (Q1.10 'compressed' into 8bits, I suppose). If the stored value is 2, then the clock runs 2/1024 faster that it should, if -2 then its 2/1024 slower. If your 16bit timer has a period of 10000, then a +2 sigrow error value would require a corrected period of 10000*(1024+2)/1024, or 10019. If its -2, then 10000*(1024+(-2))/1024, or 9980. Using the sigrow correction probably gets you a few seconds better in the span of 1200 seconds. On a mega4809 I have, running at 3v3 and 75degrees, the error in 20 minutes is about 3-4 seconds, with the sigrow correction its under a second. That is a sample of 1, anyway.

 

Since the higher pin count mega0's don't have ptc, one could also split the tasks- a 20pin tiny406 to drive the display, and a tiny816/817 for the main mcu. The tiny81x is probably the same cost as those touch ic's, so would be a wash in price (I don't use the ptc/touch peripheral so don't know how easy/hard it is to use). With a dozen pins freed up (less 1 or 2 for communication to display), the main mcu can now be a 20/24 pin tiny of some kind.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

david.prentice wrote:

However,  if you were controlliing a V1 flying bomb the navigation accuracy would be important.

I don't know whether the original V1 used a timer or the pulse-jet just ran out of fuel.

 

I believe it used a little propellor.  As the flight went on it would unscrew itself, and when it fell off, the bomb fell down.  Marine torpedoes are a bit like that too but I think they use the unscrewing prop as arming, not detonating.  S.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

uCnoob wrote:

Great, I will use a crystal then. 

 

uCnoob wrote:

I will be interfacing this 7 seg LED which uses the most pins(16).

You mean I can stick with 808? I am interested in the 817 because it offers cap touch sensing capabilities without any extra hardware. Also, going by the graph, I think the tiny817 is more accurate than the 808, correct me if I am wrong.

I am working on a 10 unit prototype, if all goes well, I will start with 500units.

 

If you are also using a 4 digit LED display, that elevates this to more than a simple 'jelly bean' timer, and I would suggest you lay the PCB to support the 32kHz crystal, which you can always decide to not fit later.

 

You might want to include new parts like AVR32DA32 in your search short list too, and also look at 'easier' packages like TQFP32  ?

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


I'm really surprised about this (808 ...... datasheet):

 

That basically say: if you run in the slow end, the speed don't change over temperature (looks like 14MHz is the sweet spot) 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That basically say: if you run in the slow end, the speed don't change over temperature (looks like 14MHz is the sweet spot) 

I don't think it infers a sweet spot; more like operating at 25C gives the most straight-line linear adjustment across the range.

If you could really see them forming a solid "X" (curves crossing each other) at 14 MHz, then maybe a sweet spot...but the graph looks pretty mushed & blurred there.

 

Yes,  agreed,  there is definitely a correlation of more % deviation vs temperature at higher frequencies

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

sparrow2 wrote:

I'm really surprised about this (808 ...... datasheet):

That basically say: if you run in the slow end, the speed don't change over temperature (looks like 14MHz is the sweet spot) 

 

For the sample device they measured to create that graph, yes, that appears to be true :)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

sparrow2 wrote:

 

I had e quick look at the 808 datasheet and it actually have a register there tell the calibrated error :

 

The idea with this is to make sure that the BAUD rate is within spec but can of course also be used for timing in general.(that give a resolution of 0.1% or 0.25% I'm not sure depends where the 8 bit isplaced! it's 0.1% I guess).

So after all I guess that you can get within 1% without any calibration (microchip has done it all for you) 

 

Add:

Does anyone know what they mean with compressed  Q1.10 ?

 

That's great then, I can just use the MegaCoreX library and use the arduino ecosystem to code it without much effort. 

 

skeeve wrote:

Though they do not appear to apply to OP,

there can be sensible reasons for avoiding an external crystal,

even on a one-off.

One might want to breadboard the circuit.

My recollection is that breadboards and crystals are not a good match.

OP might be lousy at soldering and simply want to reduce the pin count.

How hard would it be for a Mr. Magoo to destroy a crystal with a soldering iron?

 

That said, calibrating can be a significant issue.

At some point, would have to use a clock with sufficient accuracy.

Moving the device from that point to where it is used

might destroy the calibration.

In the case of a device that almost works out of the box,

environment-matching would not be much of an issue.

 

All that said, the chosen solution seems to be the right one.

No only does a crystal work,

knowing that it works is easier than with any other solution.

Agreed. That was one of the reasons I wanted to avoid using a external clock. In my previous post, @Kartman advised me to keep the components low so that the points of failure are low.

 

curtvm wrote:

>Does anyone know what they mean with compressed  Q1.10 ?

 

In this case its simply a signed 8bit value that gives the fraction amount of a 10bit value (Q1.10 'compressed' into 8bits, I suppose). If the stored value is 2, then the clock runs 2/1024 faster that it should, if -2 then its 2/1024 slower. If your 16bit timer has a period of 10000, then a +2 sigrow error value would require a corrected period of 10000*(1024+2)/1024, or 10019. If its -2, then 10000*(1024+(-2))/1024, or 9980. Using the sigrow correction probably gets you a few seconds better in the span of 1200 seconds. On a mega4809 I have, running at 3v3 and 75degrees, the error in 20 minutes is about 3-4 seconds, with the sigrow correction its under a second. That is a sample of 1, anyway.

 

Since the higher pin count mega0's don't have ptc, one could also split the tasks- a 20pin tiny406 to drive the display, and a tiny816/817 for the main mcu. The tiny81x is probably the same cost as those touch ic's, so would be a wash in price (I don't use the ptc/touch peripheral so don't know how easy/hard it is to use). With a dozen pins freed up (less 1 or 2 for communication to display), the main mcu can now be a 20/24 pin tiny of some kind.

 

After a night of trying to wrap my head around setting up Qtouch, I finally gave up. The library has little support and I think I can better spend few cents on the touch controller than trying to set up the PTC. I am looking at the MTCH105, which gives digital output. I can just hook it up to the 808 and have the touch interfaced.

 

Who-me wrote:

uCnoob wrote:

Great, I will use a crystal then. 

 

uCnoob wrote:

I will be interfacing this 7 seg LED which uses the most pins(16).

You mean I can stick with 808? I am interested in the 817 because it offers cap touch sensing capabilities without any extra hardware. Also, going by the graph, I think the tiny817 is more accurate than the 808, correct me if I am wrong.

I am working on a 10 unit prototype, if all goes well, I will start with 500units.

 

If you are also using a 4 digit LED display, that elevates this to more than a simple 'jelly bean' timer, and I would suggest you lay the PCB to support the 32kHz crystal, which you can always decide to not fit later.

 

You might want to include new parts like AVR32DA32 in your search short list too, and also look at 'easier' packages like TQFP32  ?

 


The 808s are available in TQFP32 package... And isn't 32k a overkill for a simple application like this?

 

sparrow2 wrote:

I'm really surprised about this (808 ...... datasheet):

 

That basically say: if you run in the slow end, the speed don't change over temperature (looks like 14MHz is the sweet spot) 

 

avrcandies wrote:

That basically say: if you run in the slow end, the speed don't change over temperature (looks like 14MHz is the sweet spot) 

I don't think it infers a sweet spot; more like operating at 25C gives the most straight-line linear adjustment across the range.

If you could really see them forming a solid "X" (curves crossing each other) at 14 MHz, then maybe a sweet spot...but the graph looks pretty mushed & blurred there.

 

Yes,  agreed,  there is definitely a correlation of more % deviation vs temperature at higher frequencies

Who-me wrote:

sparrow2 wrote:

I'm really surprised about this (808 ...... datasheet):

That basically say: if you run in the slow end, the speed don't change over temperature (looks like 14MHz is the sweet spot) 

 

For the sample device they measured to create that graph, yes, that appears to be true :)

 

I guess, I will use the default frequency since it is within my tolerance levels. 

 

Yesterday I came to know about the Configurable Custom Logic feature, it is a awesome feature. I'm reading how to set it up.

 

I have now decided to go with a ATmega808 + MTCH105. Would love to have your suggestions

 

Thanks a lot for everyone that replied. Appreciate it. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

uCnoob wrote:

The 808s are available in TQFP32 package... And isn't 32k a overkill for a simple application like this?

Sure, but code size is further down the list these days - it comes almost for free on the simpler MCUs.

eg if you need cap-sense, maybe the new DA's are better at that ?

You may be best to mock this up on more than one MCU, depending on final ultimate volumes you expect. 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am working on a 10 unit prototype, if all goes well, I will start with 500units.

 

Unless you have a bit of experience, don't even waste your time doing a pcb until you've mocked up your circuit using available dev boards. Trying to debug a dodgy circuit on a dodgy pcb will send you around in circles. 

Look at this guy:

https://www.avrfreaks.net/forum/...

He's done a pcb that is probably not viable due to some basic mistakes - like not placing the required capacitors. Now he's figuring out how to get library code for a micro that is probably the wrong choice and the list goes on.

You might tell yourself 'how hard can it be'??? You'll be telling yourself 'harder than I thought' after the fact. I've been down this path many times. 

Last Edited: Mon. Aug 3, 2020 - 09:59 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

And for me in general it's the more RAM that make me prototype with a bigger chip (in same house). 

I often do fast ADC's for regulators etc. and then it's nice to make a kind of storage scope in real time the way the AVR see the world.

 

And it seems I'm the only one that still prototype with wirewrap!

I have never got used to use those prototype boards, to many lose connections.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Who-me wrote:

uCnoob wrote:

The 808s are available in TQFP32 package... And isn't 32k a overkill for a simple application like this?

Sure, but code size is further down the list these days - it comes almost for free on the simpler MCUs.

eg if you need cap-sense, maybe the new DA's are better at that ?

You may be best to mock this up on more than one MCU, depending on final ultimate volumes you expect. 

 

Thank you. Right, I will experiment with more than one mcu before deciding on one.

 

Kartman wrote:

I am working on a 10 unit prototype, if all goes well, I will start with 500units.

 

Unless you have a bit of experience, don't even waste your time doing a pcb until you've mocked up your circuit using available dev boards. Trying to debug a dodgy circuit on a dodgy pcb will send you around in circles. 

Look at this guy:

https://www.avrfreaks.net/forum/...

He's done a pcb that is probably not viable due to some basic mistakes - like not placing the required capacitors. Now he's figuring out how to get library code for a micro that is probably the wrong choice and the list goes on.

You might tell yourself 'how hard can it be'??? You'll be telling yourself 'harder than I thought' after the fact. I've been down this path many times. 

 

Thank you. Yes, that's why I am sticking to chips that already have been ported to the Arduino ecosystem so I can look at the official Arduino schematics and just accommodate the pin changes.

 

 

sparrow2 wrote:

And for me in general it's the more RAM that make me prototype with a bigger chip (in same house). 

I often do fast ADC's for regulators etc. and then it's nice to make a kind of storage scope in real time the way the AVR see the world.

 

And it seems I'm the only one that still prototype with wirewrap!

I have never got used to use those prototype boards, to many lose connections.

Thank you. Yes more ram is better, but now since the touch functionality is also taken care by a ext chip, I still I won't be needing much. Just a few varibles to keep track of the state.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

uCnoob, do yo have the ability to purchase on-line?

 

I sounds like the device will be Mains powered, not battery powered, if it has to run a relay and a display, so low power isn't an issue.

 

A micro, a character LCD, two PB Switches, and a relay for a simple timer is a pretty straight forward circuit, (even if one as touch sense for the user interface).

 

Why not purchase an Arduino Nano and wire up your circuit on a breadboard to build a working prototype?

 

The Nano (obviously) works with the Arduino IDE & libraries, etc.; and includes a power supply, by-pass caps on the micro, an crystal / resonator, and a reset switch and LED as "extra".

 

You could even built 10 of them, based upon the Nano, to give to people for them to test your product and see how it works, before you make 500 of them.

Real user feedback can be incredibly important to a future product's success.

 

(Oh man, I'm beginning to sound like Simonetta!)

 

The photo shows an old project which is similar to what you are building.

It has a Tiny micro, running a character display, and a power supply.

The pads on the right hold two transistors and two relays, which aren't installed in this photo.

A couple of pads went  to a keypad, but in your case would be your Start/Stop switches.

 

The breadboard photo shows how much smaller the project is when one uses a Nano.

The breadboard makes it easy to prototype your project, work on your code, and learn a lot in the process.

With a working prototype you will have a lot more experience and insight into your project that can help you make better decisions about micros, user interfaces, displays, power supplies, etc.

 

You are 50 posts into this Thread.

I think you need to pick a micro, (any micro!), draw up a schematic, wire it up, and start structuring your code for your first prototype!

 

JC

 

 

 

? ? ? 

I don't seem to have the ability to adjust the size of the images?

 

JC

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

what's the square guy in the middle with 3 wires?

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

GPS module!

 

(Possum Lodge oath) Quando omni flunkus, moritati.

"I thought growing old would take longer"

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Jim -

 

What sort of GPS module is it? 

 

West Coast Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have a pair of them, one is an Adafruit module I'm using in an arduino clock (self setting).

The other looks like the above used in WSPR mode on a QRSS transmitter beacon.

 

Jim

Edit: link https://www.adafruit.com/product...

QRSS/WSPR kit https://www.qrp-labs.com/ultimat... Uses M328p for it's brains.

 

(Possum Lodge oath) Quando omni flunkus, moritati.

"I thought growing old would take longer"

 

Last Edited: Mon. Aug 3, 2020 - 07:17 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

uCnoob wrote:

... Yes more ram is better, but now since the touch functionality is also taken care by a ext chip, I still I won't be needing much. Just a few varibles to keep track of the state.

 

It's a good idea to use a pre-built touch for the initial lash-ups, but since you ideally want to remove those expensive parts later, you should not under-power the MCU

 

When I look at 

https://www.microchip.com/design-centers/8-bit/avr-mcus/device-selection/avr-da

and scroll down, there are a lot of touch example PCBs, so that also infers a lot of working examples for this part.

You may be able to do a proof of concept design entirely using existing modules. (as suggested above)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

what's the square guy in the middle with 3 wires?

 

 

Sorry, didn't mean to derail the Thread.

Its a rubidium atomic clock module ! cheeky

 

Actually, Non-East Coast / Non-West Coast Jim called it, it is a small GPS module with a built-in patch antenna.

 

I can't find the "data sheet" for it at the moment, but I think I paid $5 USD for it, and said that's clearly an offer that is "Too good to be true", but what the heck, let's give it a try.

Since I also, (unfortunately!), have several $50+ GPS modules, it was particularly depressing when this one worked just fine.

 

This Link is for a similar unit, (but not quite the same one), for $8 USD, from Banggood Electronics, (Small GPS module with a patch antenna).

 

JC

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

DocJC wrote:

uCnoob, do yo have the ability to purchase on-line?

 

I sounds like the device will be Mains powered, not battery powered, if it has to run a relay and a display, so low power isn't an issue.

 

A micro, a character LCD, two PB Switches, and a relay for a simple timer is a pretty straight forward circuit, (even if one as touch sense for the user interface).

 

Why not purchase an Arduino Nano and wire up your circuit on a breadboard to build a working prototype?

 

The Nano (obviously) works with the Arduino IDE & libraries, etc.; and includes a power supply, by-pass caps on the micro, an crystal / resonator, and a reset switch and LED as "extra".

 

You could even built 10 of them, based upon the Nano, to give to people for them to test your product and see how it works, before you make 500 of them.

Real user feedback can be incredibly important to a future product's success.

 

(Oh man, I'm beginning to sound like Simonetta!)

 

The photo shows an old project which is similar to what you are building.

It has a Tiny micro, running a character display, and a power supply.

The pads on the right hold two transistors and two relays, which aren't installed in this photo.

A couple of pads went  to a keypad, but in your case would be your Start/Stop switches.

 

The breadboard photo shows how much smaller the project is when one uses a Nano.

The breadboard makes it easy to prototype your project, work on your code, and learn a lot in the process.

With a working prototype you will have a lot more experience and insight into your project that can help you make better decisions about micros, user interfaces, displays, power supplies, etc.

 

You are 50 posts into this Thread.

I think you need to pick a micro, (any micro!), draw up a schematic, wire it up, and start structuring your code for your first prototype!

 

JC

 

 

 

? ? ? 

I don't seem to have the ability to adjust the size of the images?

 

JC

 

 

 

 

Thank You,

 

YEs I can buy online. I have few UNOs for prototyping. I have designed the rest of the circuit only thing that's remaining is interfacing it with the micro. I will post schematic soon. 

 

Yes, I completely agree that I should stop thinking and start doing. I have decided not to think any more and start with the ATmega1608+MTCH105

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I now have a 555IC configurged as a watch dog timer. Can I switch to the MCU default WDT? Is it as reliable as the hardware WDT?