Sign in
Search avrclub
Subscribe to avrclub
avrclub by Keywords
AT90S2313 | AT90S8515 | ATMega | ATmega128 | ECL | FETS | IAR | Keyboard | LCD | STK50 | TMOS | UART
Ads
Discussion Groups
See Also
Discussion Groups | AVRclub | [AVR club] Basic ISR question - where should the "meat" of the code go? In the ISR or in the while loop?
Atmel AVR Microcontroller discussion group.
[AVR club] Basic ISR question - where should the "meat" of the code go? In the ISR or in the while loop? - Jeff Blaine AC0C - Oct 5 11:08:33 2009
When an ISR is called, the state of the CPU is pushed onto the stack and then after the
ISR handling is completed, the machine resume it's prior state and executes the next
instruction in turn. Right? So for an instruction that has no "end" like SLEEP, is that
the case also?
My current application is very sensitive to the noise of the AVR and associated gadgets. So I want my AVR to run in deep sleep, waking only when the ISR wakes it up.
I have a few push-buttons setup poling now (for testing) but want to migrate this basic code over to trigger an ISR. That way the thing is in sleep with the exception of time spent handing the ISR, and taking the actions kicked off by the ISR.
Where is the proper place to have the heavy-lifting of the ISR activated code?
It seems to me that you want to get out of the ISR as soon as possible to avoid having the rest of the AVR hung working on an long running ISR.
On the other hand, if the machine is in sleep, does that mean that the sleep operation is resumed once the ISR is handled?
Or will the while(1) sleep loop increment one?
My feeling is that the sleep should be at the top of the function while(1) {}. And then the processing needed AFTER an ISR indentifies what key was pressed should follow. Like this:
while(1) {
sleep();
..
other code
..
..
..
}
OR - should all this "other code" stuff stay inside the ISR loop?
thanks.jeff
[Non-text portions of this message have been removed]
------------------------------------
______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.
(You need to be a member of avrclub -- send a blank email to avrclub-subscribe@yahoogroups.com )
My current application is very sensitive to the noise of the AVR and associated gadgets. So I want my AVR to run in deep sleep, waking only when the ISR wakes it up.
I have a few push-buttons setup poling now (for testing) but want to migrate this basic code over to trigger an ISR. That way the thing is in sleep with the exception of time spent handing the ISR, and taking the actions kicked off by the ISR.
Where is the proper place to have the heavy-lifting of the ISR activated code?
It seems to me that you want to get out of the ISR as soon as possible to avoid having the rest of the AVR hung working on an long running ISR.
On the other hand, if the machine is in sleep, does that mean that the sleep operation is resumed once the ISR is handled?
Or will the while(1) sleep loop increment one?
My feeling is that the sleep should be at the top of the function while(1) {}. And then the processing needed AFTER an ISR indentifies what key was pressed should follow. Like this:
while(1) {
sleep();
..
other code
..
..
..
}
OR - should all this "other code" stuff stay inside the ISR loop?
thanks.jeff
[Non-text portions of this message have been removed]
------------------------------------
______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.
(You need to be a member of avrclub -- send a blank email to avrclub-subscribe@yahoogroups.com )
[AVR club] Re: Basic ISR question - where should the "meat" of the code go? In the ISR or in the while loop? - "h.ch_y" - Oct 5 16:56:05 2009
Hi, Jeff,
have you ever consulted the AVR (toolchain) docs? IMHO there's a lot of info concerning SLEEP... Eg. (citation from first AVR doc found on my disk -- ATtiny12):
> To enter the sleep modes, the SE bit in MCUCR must be set (one) and
> a SLEEP instruction must be executed. The SM bit in the MCUCR
> register selects which sleep mode (Idle or Power-down) will be
> activated by the SLEEP instruction. If an enabled interrupt occurs
> while the MCU is in a sleep mode, the MCU awakes. The CPU is then
> halted for four cycles, it executes the interrupt routine, and
> resumes execution from the instruction following SLEEP. The contents
> of the register file and I/O memory are unaltered. If a reset occurs
> during sleep mode, the MCU wakes up and executes from the Reset
> vector.
brings details about SLEEP intruction behaviour. There must be similar info about C-lib sleep() function elsewhere. (Short answer to your question: if the CPU has to wait for user input to do something useful, your while(1){} loop is laid out quite properly; interrupt awakes the CPU and it's your responsibility to handle the cause of the disturbance, and to lull it again.)
Generally spoken, ISR routines should be kept short. As the name suggests, they interrupt normal flow of code (even being it a sleepy, non-flowing state ;-)). The "meat" should react upon data given by ISRs -- now tasks, context switching etc. comes to our play. (This "task" does not necesarily mean the same beast as task/thread in high-level operating systems.)
Just for the sake you might miss it: Do not forget to handle button bouncing somewhere (in the ISR or following code). A single puhs will trigger several interrupts most probably.
HTH,
H.
PS: Sorry for my English, it isn't my mother tongue.
------------------------------------
(You need to be a member of avrclub -- send a blank email to avrclub-subscribe@yahoogroups.com )
[AVR club] Re: Basic ISR question - where should the "meat" of the code go? In the ISR or in the while loop? - "h.ch_y" - Oct 5 18:10:54 2009
Hi, Jeff,
have you ever consulted the AVR (toolchain) docs? IMHO there's a lot of info concerning SLEEP... Eg. (citation from first AVR doc found on my disk -- ATtiny12):
> To enter the sleep modes, the SE bit in MCUCR must be set (one) and
> a SLEEP instruction must be executed. The SM bit in the MCUCR
> register selects which sleep mode (Idle or Power-down) will be
> activated by the SLEEP instruction. If an enabled interrupt occurs
> while the MCU is in a sleep mode, the MCU awakes. The CPU is then
> halted for four cycles, it executes the interrupt routine, and
> resumes execution from the instruction following SLEEP. The contents
> of the register file and I/O memory are unaltered. If a reset occurs
> during sleep mode, the MCU wakes up and executes from the Reset
> vector.
brings details about SLEEP intruction behaviour. There must be similar info about C-lib sleep() function elsewhere. (Short answer to your question: if the CPU has to wait for user input to do something useful, your while(1){} loop is laid out quite properly; interrupt awakes the CPU and it's your responsibility to handle the cause of the disturbance, and to lull it again.)
Generally spoken, ISR routines should be kept short. As the name suggests, they interrupt normal flow of code (even being it a sleepy, non-flowing state ;-)). The "meat" should react upon data given by ISRs -- now tasks, context switching etc. comes to our play. (This "task" does not necesarily mean the same beast as task/thread in high-level operating systems.)
Just for the sake you might miss it: Do not forget to handle button bouncing somewhere (in the ISR or following code). A single puhs will trigger several interrupts most probably.
HTH,
H.
PS: Sorry for my English, it isn't my mother tongue.
PPS: I posted this re: a while ago, but it seems it did not worked... I'm going to try it for the 2nd time.
------------------------------------
______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.
(You need to be a member of avrclub -- send a blank email to avrclub-subscribe@yahoogroups.com )
have you ever consulted the AVR (toolchain) docs? IMHO there's a lot of info concerning SLEEP... Eg. (citation from first AVR doc found on my disk -- ATtiny12):
> To enter the sleep modes, the SE bit in MCUCR must be set (one) and
> a SLEEP instruction must be executed. The SM bit in the MCUCR
> register selects which sleep mode (Idle or Power-down) will be
> activated by the SLEEP instruction. If an enabled interrupt occurs
> while the MCU is in a sleep mode, the MCU awakes. The CPU is then
> halted for four cycles, it executes the interrupt routine, and
> resumes execution from the instruction following SLEEP. The contents
> of the register file and I/O memory are unaltered. If a reset occurs
> during sleep mode, the MCU wakes up and executes from the Reset
> vector.
brings details about SLEEP intruction behaviour. There must be similar info about C-lib sleep() function elsewhere. (Short answer to your question: if the CPU has to wait for user input to do something useful, your while(1){} loop is laid out quite properly; interrupt awakes the CPU and it's your responsibility to handle the cause of the disturbance, and to lull it again.)
Generally spoken, ISR routines should be kept short. As the name suggests, they interrupt normal flow of code (even being it a sleepy, non-flowing state ;-)). The "meat" should react upon data given by ISRs -- now tasks, context switching etc. comes to our play. (This "task" does not necesarily mean the same beast as task/thread in high-level operating systems.)
Just for the sake you might miss it: Do not forget to handle button bouncing somewhere (in the ISR or following code). A single puhs will trigger several interrupts most probably.
HTH,
H.
PS: Sorry for my English, it isn't my mother tongue.
PPS: I posted this re: a while ago, but it seems it did not worked... I'm going to try it for the 2nd time.
------------------------------------
______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.
(You need to be a member of avrclub -- send a blank email to avrclub-subscribe@yahoogroups.com )
[AVR club] Re: Basic ISR question - where should the "meat" of the code go? In the ISR or in the while loop? - "h.ch_y" - Oct 6 8:48:42 2009
Hi, Jeff,
have you ever consulted the AVR (toolchain) docs? IMHO there's a lot of info concerning SLEEP... Eg. (citation from first AVR doc found on my disk -- ATtiny12):
> To enter the sleep modes, the SE bit in MCUCR must be set (one) and
> a SLEEP instruction must be executed. The SM bit in the MCUCR
> register selects which sleep mode (Idle or Power-down) will be
> activated by the SLEEP instruction. If an enabled interrupt occurs
> while the MCU is in a sleep mode, the MCU awakes. The CPU is then
> halted for four cycles, it executes the interrupt routine, and
> resumes execution from the instruction following SLEEP. The contents
> of the register file and I/O memory are unaltered. If a reset occurs
> during sleep mode, the MCU wakes up and executes from the Reset
> vector.
brings details about SLEEP intruction behaviour. There must be similar info about C-lib sleep() function elsewhere. (Short answer to your question: if the CPU has to wait for user input to do something useful, your while(1){} loop is laid out quite properly; interrupt awakes the CPU and it's your responsibility to handle the cause of the disturbance, and to lull it again.)
Generally spoken, ISR routines should be kept short. As the name suggests, they interrupt normal flow of code (even being it a sleepy, non-flowing state ;-)). The "meat" should react upon data given by ISRs -- now tasks, context switching etc. comes to our play. (This "task" does not necesarily mean the same beast as task/thread in high-level operating systems.)
Just for the sake you might miss it: Do not forget to handle button bouncing somewhere (in the ISR or following code). A single puhs will trigger several interrupts most probably.
HTH,
H.
PS: Sorry for my English, it isn't my mother tongue.
PPS: I posted this re: even twice a while ago, but it seems it did not worked... I'm going to try it for the next, last time.
------------------------------------
______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.
(You need to be a member of avrclub -- send a blank email to avrclub-subscribe@yahoogroups.com )
have you ever consulted the AVR (toolchain) docs? IMHO there's a lot of info concerning SLEEP... Eg. (citation from first AVR doc found on my disk -- ATtiny12):
> To enter the sleep modes, the SE bit in MCUCR must be set (one) and
> a SLEEP instruction must be executed. The SM bit in the MCUCR
> register selects which sleep mode (Idle or Power-down) will be
> activated by the SLEEP instruction. If an enabled interrupt occurs
> while the MCU is in a sleep mode, the MCU awakes. The CPU is then
> halted for four cycles, it executes the interrupt routine, and
> resumes execution from the instruction following SLEEP. The contents
> of the register file and I/O memory are unaltered. If a reset occurs
> during sleep mode, the MCU wakes up and executes from the Reset
> vector.
brings details about SLEEP intruction behaviour. There must be similar info about C-lib sleep() function elsewhere. (Short answer to your question: if the CPU has to wait for user input to do something useful, your while(1){} loop is laid out quite properly; interrupt awakes the CPU and it's your responsibility to handle the cause of the disturbance, and to lull it again.)
Generally spoken, ISR routines should be kept short. As the name suggests, they interrupt normal flow of code (even being it a sleepy, non-flowing state ;-)). The "meat" should react upon data given by ISRs -- now tasks, context switching etc. comes to our play. (This "task" does not necesarily mean the same beast as task/thread in high-level operating systems.)
Just for the sake you might miss it: Do not forget to handle button bouncing somewhere (in the ISR or following code). A single puhs will trigger several interrupts most probably.
HTH,
H.
PS: Sorry for my English, it isn't my mother tongue.
PPS: I posted this re: even twice a while ago, but it seems it did not worked... I'm going to try it for the next, last time.
------------------------------------
______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.
(You need to be a member of avrclub -- send a blank email to avrclub-subscribe@yahoogroups.com )
Re: [AVR club] Re: Basic ISR question - where should the "meat" of the code go? In the ISR or in the while loop? - Jeff Blaine AC0C - Oct 6 8:49:02 2009
H,
Your English is excellent. and thank you for your comments.
I am learning every day more source of documents. On the Atmel web site is quite a few. And also, quite deep in the directory structure of the WinAVR are found the AVI-libc examples.
In my early days, the source of data was simple. Device data sheet, application note and book. Now with internet, a million more sources.
Thanks! Jeff
Thank you
From: h.ch_y
Sent: Tuesday, October 06, 2009 4:52 AM
To: a...@yahoogroups.com
Subject: [AVR club] Re: Basic ISR question - where should the "meat" of the code go? In the ISR or in the while loop?
Hi, Jeff,
have you ever consulted the AVR (toolchain) docs? IMHO there's a lot of info concerning SLEEP... Eg. (citation from first AVR doc found on my disk -- ATtiny12):
> To enter the sleep modes, the SE bit in MCUCR must be set (one) and
> a SLEEP instruction must be executed. The SM bit in the MCUCR
> register selects which sleep mode (Idle or Power-down) will be
> activated by the SLEEP instruction. If an enabled interrupt occurs
> while the MCU is in a sleep mode, the MCU awakes. The CPU is then
> halted for four cycles, it executes the interrupt routine, and
> resumes execution from the instruction following SLEEP. The contents
> of the register file and I/O memory are unaltered. If a reset occurs
> during sleep mode, the MCU wakes up and executes from the Reset
> vector.
brings details about SLEEP intruction behaviour. There must be similar info about C-lib sleep() function elsewhere. (Short answer to your question: if the CPU has to wait for user input to do something useful, your while(1){} loop is laid out quite properly; interrupt awakes the CPU and it's your responsibility to handle the cause of the disturbance, and to lull it again.)
Generally spoken, ISR routines should be kept short. As the name suggests, they interrupt normal flow of code (even being it a sleepy, non-flowing state ;-)). The "meat" should react upon data given by ISRs -- now tasks, context switching etc. comes to our play. (This "task" does not necesarily mean the same beast as task/thread in high-level operating systems.)
Just for the sake you might miss it: Do not forget to handle button bouncing somewhere (in the ISR or following code). A single puhs will trigger several interrupts most probably.
HTH,
H.
PS: Sorry for my English, it isn't my mother tongue.
PPS: I posted this re: a while ago, but it seems it did not worked... I'm going to try it for the 2nd time.
[Non-text portions of this message have been removed]
------------------------------------
______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.
(You need to be a member of avrclub -- send a blank email to avrclub-subscribe@yahoogroups.com )
Your English is excellent. and thank you for your comments.
I am learning every day more source of documents. On the Atmel web site is quite a few. And also, quite deep in the directory structure of the WinAVR are found the AVI-libc examples.
In my early days, the source of data was simple. Device data sheet, application note and book. Now with internet, a million more sources.
Thanks! Jeff
Thank you
From: h.ch_y
Sent: Tuesday, October 06, 2009 4:52 AM
To: a...@yahoogroups.com
Subject: [AVR club] Re: Basic ISR question - where should the "meat" of the code go? In the ISR or in the while loop?
Hi, Jeff,
have you ever consulted the AVR (toolchain) docs? IMHO there's a lot of info concerning SLEEP... Eg. (citation from first AVR doc found on my disk -- ATtiny12):
> To enter the sleep modes, the SE bit in MCUCR must be set (one) and
> a SLEEP instruction must be executed. The SM bit in the MCUCR
> register selects which sleep mode (Idle or Power-down) will be
> activated by the SLEEP instruction. If an enabled interrupt occurs
> while the MCU is in a sleep mode, the MCU awakes. The CPU is then
> halted for four cycles, it executes the interrupt routine, and
> resumes execution from the instruction following SLEEP. The contents
> of the register file and I/O memory are unaltered. If a reset occurs
> during sleep mode, the MCU wakes up and executes from the Reset
> vector.
brings details about SLEEP intruction behaviour. There must be similar info about C-lib sleep() function elsewhere. (Short answer to your question: if the CPU has to wait for user input to do something useful, your while(1){} loop is laid out quite properly; interrupt awakes the CPU and it's your responsibility to handle the cause of the disturbance, and to lull it again.)
Generally spoken, ISR routines should be kept short. As the name suggests, they interrupt normal flow of code (even being it a sleepy, non-flowing state ;-)). The "meat" should react upon data given by ISRs -- now tasks, context switching etc. comes to our play. (This "task" does not necesarily mean the same beast as task/thread in high-level operating systems.)
Just for the sake you might miss it: Do not forget to handle button bouncing somewhere (in the ISR or following code). A single puhs will trigger several interrupts most probably.
HTH,
H.
PS: Sorry for my English, it isn't my mother tongue.
PPS: I posted this re: a while ago, but it seems it did not worked... I'm going to try it for the 2nd time.
[Non-text portions of this message have been removed]
------------------------------------
______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.
(You need to be a member of avrclub -- send a blank email to avrclub-subscribe@yahoogroups.com )
Re: [AVR club] Re: Basic ISR question - where should the "meat" of the code go? In the ISR or in the while loop? - Zack Widup - Oct 6 9:16:41 2009
Hi,
All new members are moderated in an attempt to keep spam out. You would not
believe how much spam is sent to the group. It never gets posted.
The group's moderators are in different countries. One is in Europe and I am
in the USA. We do our best to get the messages on the topic of AVR's
approved fast but sometimes it takes a little while. So if your message
doesn't appear immediately, please be patient. It should show up within half
a day under most circumstances.
Thanks for your patience.
Zack
On Mon, Oct 5, 2009 at 3:52 PM, h.ch_y wrote:
PPS: I posted this re: a while ago, but it seems it did not worked... I'm
going to try it for the 2nd time.
[Non-text portions of this message have been removed]
------------------------------------
(You need to be a member of avrclub -- send a blank email to avrclub-subscribe@yahoogroups.com )
All new members are moderated in an attempt to keep spam out. You would not
believe how much spam is sent to the group. It never gets posted.
The group's moderators are in different countries. One is in Europe and I am
in the USA. We do our best to get the messages on the topic of AVR's
approved fast but sometimes it takes a little while. So if your message
doesn't appear immediately, please be patient. It should show up within half
a day under most circumstances.
Thanks for your patience.
Zack
On Mon, Oct 5, 2009 at 3:52 PM, h.ch_y
PPS: I posted this re: a while ago, but it seems it did not worked... I'm
going to try it for the 2nd time.
[Non-text portions of this message have been removed]
------------------------------------
(You need to be a member of avrclub -- send a blank email to avrclub-subscribe@yahoogroups.com )
[AVR club] Re: Basic ISR question - where should the "meat" of the code go? In the ISR or in the while loop? - "h.ch_y" - Oct 6 14:06:01 2009
Helo, Zack,
thank you for your explanation. I might miss this information. Anyway, I've learned to wait last night ;-)
If you can delete my duplicate post (#2530), do it, please. I didn't find any way to do it myself. TIA.
Regards,
H.
------------------------------------
______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.
(You need to be a member of avrclub -- send a blank email to avrclub-subscribe@yahoogroups.com )
thank you for your explanation. I might miss this information. Anyway, I've learned to wait last night ;-)
If you can delete my duplicate post (#2530), do it, please. I didn't find any way to do it myself. TIA.
Regards,
H.
------------------------------------
______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.
(You need to be a member of avrclub -- send a blank email to avrclub-subscribe@yahoogroups.com )
Re: [AVR club] Re: Basic ISR question - where should the "meat" of the code go? In the ISR or in the while loop? - Zack Widup - Oct 6 14:25:31 2009
OK, no problem, I deleted the duplicates. If that's the worst thing that
happens to me today I have it made!
:-)
You're unmoderated now so you should see your posts go through pretty
quickly.
Zack
On Tue, Oct 6, 2009 at 1:05 PM, h.ch_y wrote:
> Helo, Zack,
>
> thank you for your explanation. I might miss this information. Anyway, I've
> learned to wait last night ;-)
>
> If you can delete my duplicate post (#2530), do it, please. I didn't find
> any way to do it myself. TIA.
>
> Regards,
> H.
>
[Non-text portions of this message have been removed]
------------------------------------
(You need to be a member of avrclub -- send a blank email to avrclub-subscribe@yahoogroups.com )
happens to me today I have it made!
:-)
You're unmoderated now so you should see your posts go through pretty
quickly.
Zack
On Tue, Oct 6, 2009 at 1:05 PM, h.ch_y
> Helo, Zack,
>
> thank you for your explanation. I might miss this information. Anyway, I've
> learned to wait last night ;-)
>
> If you can delete my duplicate post (#2530), do it, please. I didn't find
> any way to do it myself. TIA.
>
> Regards,
> H.
>
[Non-text portions of this message have been removed]
------------------------------------
(You need to be a member of avrclub -- send a blank email to avrclub-subscribe@yahoogroups.com )
[AVR club] Re: Basic ISR question - where should the "meat" of the code go? In the ISR or in the while loop? - "h.ch_y" - Oct 6 15:19:37 2009
Hi, Jeff,
you're right, the Internet is almost unlimited source of information, and sometimes mis-information ;-) It's really hard to differentiate various levels of utility, and one is unable to capture all the info laying around.
Anyway, generally I've been satisfied with most manufacturer's effort to publish accurate and extensive data and examples on their products. (Ehm, I mean semiconductor manufacturers, and yes, there're many annoying exceptions and secrets even in this field ;-).) That's why I usually start just there, and choose lower-end representative of the family if possible to begin my learing.
And while reading the manuals is a bit stodgy, there're zillions ways to play (and try and error ;-)) even with the simplest circuits (home made or breadboarded in my case) based on the respective processor, which is what I really enjoy. One can "blink the stupid LED" using this or that approach, to combine various features together, and get accustomed with the device. No serious damages, negligible influence on my neighbourhood, anger at me when stuck somwehere, pleasure when going on finally, fun ;-) Fortunately, it's my hobby, not a way to earn my daily bread.
Just another 2 cents from me. Have a nice time with your deal,
H.
------------------------------------
(You need to be a member of avrclub -- send a blank email to avrclub-subscribe@yahoogroups.com )
you're right, the Internet is almost unlimited source of information, and sometimes mis-information ;-) It's really hard to differentiate various levels of utility, and one is unable to capture all the info laying around.
Anyway, generally I've been satisfied with most manufacturer's effort to publish accurate and extensive data and examples on their products. (Ehm, I mean semiconductor manufacturers, and yes, there're many annoying exceptions and secrets even in this field ;-).) That's why I usually start just there, and choose lower-end representative of the family if possible to begin my learing.
And while reading the manuals is a bit stodgy, there're zillions ways to play (and try and error ;-)) even with the simplest circuits (home made or breadboarded in my case) based on the respective processor, which is what I really enjoy. One can "blink the stupid LED" using this or that approach, to combine various features together, and get accustomed with the device. No serious damages, negligible influence on my neighbourhood, anger at me when stuck somwehere, pleasure when going on finally, fun ;-) Fortunately, it's my hobby, not a way to earn my daily bread.
Just another 2 cents from me. Have a nice time with your deal,
H.
------------------------------------
(You need to be a member of avrclub -- send a blank email to avrclub-subscribe@yahoogroups.com )
Re: [AVR club] Re: Basic ISR question - where should the "meat" of the code go? In the ISR or in the while loop? - Jeff Blaine AC0C - Oct 12 5:39:03 2009
A follow up on this...
For guys like me, meaning guys interested in a compiler option that has common hardware library functions included, I did find one solution that looks very promising. The Mikroe series at www.mkkroe.com.
The cost is reasonable. Quite a lot of hardware is included. And PASCAL, C and BASIC versions of the compiler are available. And it looks like the product is under active development (means they are still in business and working on the bugs - something important for everyone).
There are two other interesting things that I want to mention.
1. They offer a development board series for the AVR that features the hardware that the compiler supports. They have similar boards for other MCU families - and one that is a modular sort of arrangement where the MCU card is interchangeable. I have ordered one of the boards and the shipment was on the next day. I anticipate receiving it this week.
2. The company is in Serbia. But the web page, the documentation and instructions are excellent even by native English speaking standards. They are not flawless, however, from a technical writing standpoint, their material is much better than a lot of stuff I see from "US based" companies. I have a couple of well known programming related texts that have more errors than their compiler manual. Queries sent to the company on the products were answered the same day. Wonder around the web site and you will get a feel for what I mean. I only mention this because it's just so infrequent that I see any tech topics distilled into such a simple basis. Einstein said, make things as simple as possible - but no simpler. They really have done well here.
I have no affiliation with this company. I am just extremely pleased with what I have seen so far. For a guy looking to taking an easy path into this line of fun, this Mikroe solution looks like the best of the offerings out there - at least that I've found so far.
hope it helps!
jeff
From: h.ch_y
Sent: Tuesday, October 06, 2009 2:19 PM
To: a...@yahoogroups.com
Subject: [AVR club] Re: Basic ISR question - where should the "meat" of the code go? In the ISR or in the while loop?
Hi, Jeff,
you're right, the Internet is almost unlimited source of information, and sometimes mis-information ;-) It's really hard to differentiate various levels of utility, and one is unable to capture all the info laying around.
Anyway, generally I've been satisfied with most manufacturer's effort to publish accurate and extensive data and examples on their products. (Ehm, I mean semiconductor manufacturers, and yes, there're many annoying exceptions and secrets even in this field ;-).) That's why I usually start just there, and choose lower-end representative of the family if possible to begin my learing.
And while reading the manuals is a bit stodgy, there're zillions ways to play (and try and error ;-)) even with the simplest circuits (home made or breadboarded in my case) based on the respective processor, which is what I really enjoy. One can "blink the stupid LED" using this or that approach, to combine various features together, and get accustomed with the device. No serious damages, negligible influence on my neighbourhood, anger at me when stuck somwehere, pleasure when going on finally, fun ;-) Fortunately, it's my hobby, not a way to earn my daily bread.
Just another 2 cents from me. Have a nice time with your deal,
H.
[Non-text portions of this message have been removed]
------------------------------------
(You need to be a member of avrclub -- send a blank email to avrclub-subscribe@yahoogroups.com )
For guys like me, meaning guys interested in a compiler option that has common hardware library functions included, I did find one solution that looks very promising. The Mikroe series at www.mkkroe.com.
The cost is reasonable. Quite a lot of hardware is included. And PASCAL, C and BASIC versions of the compiler are available. And it looks like the product is under active development (means they are still in business and working on the bugs - something important for everyone).
There are two other interesting things that I want to mention.
1. They offer a development board series for the AVR that features the hardware that the compiler supports. They have similar boards for other MCU families - and one that is a modular sort of arrangement where the MCU card is interchangeable. I have ordered one of the boards and the shipment was on the next day. I anticipate receiving it this week.
2. The company is in Serbia. But the web page, the documentation and instructions are excellent even by native English speaking standards. They are not flawless, however, from a technical writing standpoint, their material is much better than a lot of stuff I see from "US based" companies. I have a couple of well known programming related texts that have more errors than their compiler manual. Queries sent to the company on the products were answered the same day. Wonder around the web site and you will get a feel for what I mean. I only mention this because it's just so infrequent that I see any tech topics distilled into such a simple basis. Einstein said, make things as simple as possible - but no simpler. They really have done well here.
I have no affiliation with this company. I am just extremely pleased with what I have seen so far. For a guy looking to taking an easy path into this line of fun, this Mikroe solution looks like the best of the offerings out there - at least that I've found so far.
hope it helps!
jeff
From: h.ch_y
Sent: Tuesday, October 06, 2009 2:19 PM
To: a...@yahoogroups.com
Subject: [AVR club] Re: Basic ISR question - where should the "meat" of the code go? In the ISR or in the while loop?
Hi, Jeff,
you're right, the Internet is almost unlimited source of information, and sometimes mis-information ;-) It's really hard to differentiate various levels of utility, and one is unable to capture all the info laying around.
Anyway, generally I've been satisfied with most manufacturer's effort to publish accurate and extensive data and examples on their products. (Ehm, I mean semiconductor manufacturers, and yes, there're many annoying exceptions and secrets even in this field ;-).) That's why I usually start just there, and choose lower-end representative of the family if possible to begin my learing.
And while reading the manuals is a bit stodgy, there're zillions ways to play (and try and error ;-)) even with the simplest circuits (home made or breadboarded in my case) based on the respective processor, which is what I really enjoy. One can "blink the stupid LED" using this or that approach, to combine various features together, and get accustomed with the device. No serious damages, negligible influence on my neighbourhood, anger at me when stuck somwehere, pleasure when going on finally, fun ;-) Fortunately, it's my hobby, not a way to earn my daily bread.
Just another 2 cents from me. Have a nice time with your deal,
H.
[Non-text portions of this message have been removed]
------------------------------------
(You need to be a member of avrclub -- send a blank email to avrclub-subscribe@yahoogroups.com )
[AVR club] Re: Basic ISR question - where should the "meat" of the code go? In the ISR or in the while loop? - stevec - Oct 12 22:30:16 2009
Their AVR compilers are unusably buggy and persistently so for 2 years. Read the gripes on their forum.
--- In a...@yahoogroups.com, "Jeff Blaine AC0C"
>
> A follow up on this...
>
> For guys like me, meaning guys interested in a compiler option that has common hardware library functions included, I did find one solution that looks very promising. The Mikroe series at www.mkkroe.com.
>
> The cost is reasonable. Quite a lot of hardware is included. And PASCAL, C and BASIC versions of the compiler are available. And it looks like the product is under active development (means they are still in business and working on the bugs - something important for everyone).
>
> There are two other interesting things that I want to mention.
>
> 1. They offer a development board series for the AVR that features the hardware that the compiler supports. They have similar boards for other MCU families - and one that is a modular sort of arrangement where the MCU card is interchangeable. I have ordered one of the boards and the shipment was on the next day. I anticipate receiving it this week.
>
> 2. The company is in Serbia. But the web page, the documentation and instructions are excellent even by native English speaking standards. They are not flawless, however, from a technical writing standpoint, their material is much better than a lot of stuff I see from "US based" companies. I have a couple of well known programming related texts that have more errors than their compiler manual. Queries sent to the company on the products were answered the same day. Wonder around the web site and you will get a feel for what I mean. I only mention this because it's just so infrequent that I see any tech topics distilled into such a simple basis. Einstein said, make things as simple as possible - but no simpler. They really have done well here.
>
> I have no affiliation with this company. I am just extremely pleased with what I have seen so far. For a guy looking to taking an easy path into this line of fun, this Mikroe solution looks like the best of the offerings out there - at least that I've found so far.
>
> hope it helps!
> jeff
> From: h.ch_y
> Sent: Tuesday, October 06, 2009 2:19 PM
> To: a...@yahoogroups.com
> Subject: [AVR club] Re: Basic ISR question - where should the "meat" of the code go? In the ISR or in the while loop?
> Hi, Jeff,
>
> you're right, the Internet is almost unlimited source of information, and sometimes mis-information ;-) It's really hard to differentiate various levels of utility, and one is unable to capture all the info laying around.
>
> Anyway, generally I've been satisfied with most manufacturer's effort to publish accurate and extensive data and examples on their products. (Ehm, I mean semiconductor manufacturers, and yes, there're many annoying exceptions and secrets even in this field ;-).) That's why I usually start just there, and choose lower-end representative of the family if possible to begin my learing.
>
> And while reading the manuals is a bit stodgy, there're zillions ways to play (and try and error ;-)) even with the simplest circuits (home made or breadboarded in my case) based on the respective processor, which is what I really enjoy. One can "blink the stupid LED" using this or that approach, to combine various features together, and get accustomed with the device. No serious damages, negligible influence on my neighbourhood, anger at me when stuck somwehere, pleasure when going on finally, fun ;-) Fortunately, it's my hobby, not a way to earn my daily bread.
>
> Just another 2 cents from me. Have a nice time with your deal,
> H.
>
> [Non-text portions of this message have been removed]
>
------------------------------------
______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.
(You need to be a member of avrclub -- send a blank email to avrclub-subscribe@yahoogroups.com )
[AVR club] Re: Basic ISR question - where should the "meat" of the code go? In the ISR or in the while loop? - STEVEN - Oct 13 8:54:15 2009
BASIC !! (urggghh !!), steve is right, their compilers are very buggy, stick with WinAvr,
its free well documented, plenty of forum support what else do you need.
You are right about the dev boards though , they do some good ones.
Regards
--- In a...@yahoogroups.com, "stevec" wrote:
> Their AVR compilers are unusably buggy and persistently so for 2 years. Read the gripes on their forum.
> --- In a...@yahoogroups.com, "Jeff Blaine AC0C" wrote:
> >
> > A follow up on this...
> >
> > For guys like me, meaning guys interested in a compiler option that has common hardware library functions included, I did find one solution that looks very promising. The Mikroe series at www.mkkroe.com.
> >
> > The cost is reasonable. Quite a lot of hardware is included. And PASCAL, C and BASIC versions of the compiler are available. And it looks like the product is under active development (means they are still in business and working on the bugs - something important for everyone).
> >
> > There are two other interesting things that I want to mention.
> >
> > 1. They offer a development board series for the AVR that features the hardware that the compiler supports. They have similar boards for other MCU families - and one that is a modular sort of arrangement where the MCU card is interchangeable. I have ordered one of the boards and the shipment was on the next day. I anticipate receiving it this week.
> >
> > 2. The company is in Serbia. But the web page, the documentation and instructions are excellent even by native English speaking standards. They are not flawless, however, from a technical writing standpoint, their material is much better than a lot of stuff I see from "US based" companies. I have a couple of well known programming related texts that have more errors than their compiler manual. Queries sent to the company on the products were answered the same day. Wonder around the web site and you will get a feel for what I mean. I only mention this because it's just so infrequent that I see any tech topics distilled into such a simple basis. Einstein said, make things as simple as possible - but no simpler. They really have done well here.
> >
> > I have no affiliation with this company. I am just extremely pleased with what I have seen so far. For a guy looking to taking an easy path into this line of fun, this Mikroe solution looks like the best of the offerings out there - at least that I've found so far.
> >
> > hope it helps!
> > jeff
> >
> >
> > From: h.ch_y
> > Sent: Tuesday, October 06, 2009 2:19 PM
> > To: a...@yahoogroups.com
> > Subject: [AVR club] Re: Basic ISR question - where should the "meat" of the code go? In the ISR or in the while loop?
> >
> >
> > Hi, Jeff,
> >
> > you're right, the Internet is almost unlimited source of information, and sometimes mis-information ;-) It's really hard to differentiate various levels of utility, and one is unable to capture all the info laying around.
> >
> > Anyway, generally I've been satisfied with most manufacturer's effort to publish accurate and extensive data and examples on their products. (Ehm, I mean semiconductor manufacturers, and yes, there're many annoying exceptions and secrets even in this field ;-).) That's why I usually start just there, and choose lower-end representative of the family if possible to begin my learing.
> >
> > And while reading the manuals is a bit stodgy, there're zillions ways to play (and try and error ;-)) even with the simplest circuits (home made or breadboarded in my case) based on the respective processor, which is what I really enjoy. One can "blink the stupid LED" using this or that approach, to combine various features together, and get accustomed with the device. No serious damages, negligible influence on my neighbourhood, anger at me when stuck somwehere, pleasure when going on finally, fun ;-) Fortunately, it's my hobby, not a way to earn my daily bread.
> >
> > Just another 2 cents from me. Have a nice time with your deal,
> > H.
> >
> >
> >
> >
> >
> > [Non-text portions of this message have been removed]
>
------------------------------------
(You need to be a member of avrclub -- send a blank email to avrclub-subscribe@yahoogroups.com )
You are right about the dev boards though , they do some good ones.
Regards
--- In a...@yahoogroups.com, "stevec"
> Their AVR compilers are unusably buggy and persistently so for 2 years. Read the gripes on their forum.
> --- In a...@yahoogroups.com, "Jeff Blaine AC0C"
> >
> > A follow up on this...
> >
> > For guys like me, meaning guys interested in a compiler option that has common hardware library functions included, I did find one solution that looks very promising. The Mikroe series at www.mkkroe.com.
> >
> > The cost is reasonable. Quite a lot of hardware is included. And PASCAL, C and BASIC versions of the compiler are available. And it looks like the product is under active development (means they are still in business and working on the bugs - something important for everyone).
> >
> > There are two other interesting things that I want to mention.
> >
> > 1. They offer a development board series for the AVR that features the hardware that the compiler supports. They have similar boards for other MCU families - and one that is a modular sort of arrangement where the MCU card is interchangeable. I have ordered one of the boards and the shipment was on the next day. I anticipate receiving it this week.
> >
> > 2. The company is in Serbia. But the web page, the documentation and instructions are excellent even by native English speaking standards. They are not flawless, however, from a technical writing standpoint, their material is much better than a lot of stuff I see from "US based" companies. I have a couple of well known programming related texts that have more errors than their compiler manual. Queries sent to the company on the products were answered the same day. Wonder around the web site and you will get a feel for what I mean. I only mention this because it's just so infrequent that I see any tech topics distilled into such a simple basis. Einstein said, make things as simple as possible - but no simpler. They really have done well here.
> >
> > I have no affiliation with this company. I am just extremely pleased with what I have seen so far. For a guy looking to taking an easy path into this line of fun, this Mikroe solution looks like the best of the offerings out there - at least that I've found so far.
> >
> > hope it helps!
> > jeff
> >
> >
> > From: h.ch_y
> > Sent: Tuesday, October 06, 2009 2:19 PM
> > To: a...@yahoogroups.com
> > Subject: [AVR club] Re: Basic ISR question - where should the "meat" of the code go? In the ISR or in the while loop?
> >
> >
> > Hi, Jeff,
> >
> > you're right, the Internet is almost unlimited source of information, and sometimes mis-information ;-) It's really hard to differentiate various levels of utility, and one is unable to capture all the info laying around.
> >
> > Anyway, generally I've been satisfied with most manufacturer's effort to publish accurate and extensive data and examples on their products. (Ehm, I mean semiconductor manufacturers, and yes, there're many annoying exceptions and secrets even in this field ;-).) That's why I usually start just there, and choose lower-end representative of the family if possible to begin my learing.
> >
> > And while reading the manuals is a bit stodgy, there're zillions ways to play (and try and error ;-)) even with the simplest circuits (home made or breadboarded in my case) based on the respective processor, which is what I really enjoy. One can "blink the stupid LED" using this or that approach, to combine various features together, and get accustomed with the device. No serious damages, negligible influence on my neighbourhood, anger at me when stuck somwehere, pleasure when going on finally, fun ;-) Fortunately, it's my hobby, not a way to earn my daily bread.
> >
> > Just another 2 cents from me. Have a nice time with your deal,
> > H.
> >
> >
> >
> >
> >
> > [Non-text portions of this message have been removed]
>
------------------------------------
(You need to be a member of avrclub -- send a blank email to avrclub-subscribe@yahoogroups.com )
Re: [AVR club] Re: Basic ISR question - where should the "meat" of the code go? In the ISR or in the while loop? - Dan Roganti - Oct 14 7:36:47 2009
I use to program with Bascom for a very long time with the Atmel parts,
since the 2051 series.
But last year, I changed over to WinAVR C since I programmed other
micros in C too.
The forums are very helpful and the documentation is very good.
We have a robot club and and use the ATmega128 , this made a big difference.
We're still trying to get the hang of it, there's a few little things to
work out.
Such as, entering and comparing strings from the keyboard, it's no where
near the same as in Basic.
We used the controller board from Olimex that we bought thru
MicroController Pros, AVR-MT-128
For what it has , you can't beat the price, and it's very small and fits
in our robot.
=Dan
Pittsburgh Robotics Society
STEVEN wrote:
>
>
> BASIC !! (urggghh !!), steve is right, their compilers are very buggy,
> stick with WinAvr, its free well documented, plenty of forum support
> what else do you need.
>
> You are right about the dev boards though , they do some good ones.
>
------------------------------------
(You need to be a member of avrclub -- send a blank email to avrclub-subscribe@yahoogroups.com )
Re: [AVR club] Re: Basic ISR question - where should the "meat" of the code go? In the ISR or in the while loop? - STEVEN HOLDER - Oct 14 9:32:24 2009
hI DAN,
=A0
How did you get on with AVRx , i assume you are up and running with it now =
?
=A0
I agree with the board below, very good value.
=A0
Regards
--- On Wed, 14/10/09, Dan Roganti wrote:
From: Dan Roganti
Subject: Re: [AVR club] Re: Basic ISR question - where should the "meat" of=
the code go? In the ISR or in the while loop?
To: a...@yahoogroups.com
Date: Wednesday, 14 October, 2009, 12:09 PM
=A0=20
I use to program with Bascom for a very long time with the Atmel parts,=20
since the 2051 series.
But last year, I changed over to WinAVR C since I programmed other=20
micros in C too.
The forums are very helpful and the documentation is very good.
We have a robot club and and use the ATmega128 , this made a big difference=
.
We're still trying to get the hang of it, there's a few little things to=20
work out.
Such as, entering and comparing strings from the keyboard, it's no where=20
near the same as in Basic.
We used the controller board from Olimex that we bought thru=20
MicroController Pros, AVR-MT-128=20
For what it has , you can't beat the price, and it's very small and fits=20
in our robot.
=3DDan
Pittsburgh Robotics Society
STEVEN wrote:
>=20
>
> BASIC !! (urggghh !!), steve is right, their compilers are very buggy,=20
> stick with WinAvr, its free well documented, plenty of forum support=20
> what else do you need.
>
> You are right about the dev boards though , they do some good ones.
>
[Non-text portions of this message have been removed]
------------------------------------
(You need to be a member of avrclub -- send a blank email to avrclub-subscribe@yahoogroups.com )
=A0
How did you get on with AVRx , i assume you are up and running with it now =
?
=A0
I agree with the board below, very good value.
=A0
Regards
--- On Wed, 14/10/09, Dan Roganti
From: Dan Roganti
Subject: Re: [AVR club] Re: Basic ISR question - where should the "meat" of=
the code go? In the ISR or in the while loop?
To: a...@yahoogroups.com
Date: Wednesday, 14 October, 2009, 12:09 PM
=A0=20
I use to program with Bascom for a very long time with the Atmel parts,=20
since the 2051 series.
But last year, I changed over to WinAVR C since I programmed other=20
micros in C too.
The forums are very helpful and the documentation is very good.
We have a robot club and and use the ATmega128 , this made a big difference=
.
We're still trying to get the hang of it, there's a few little things to=20
work out.
Such as, entering and comparing strings from the keyboard, it's no where=20
near the same as in Basic.
We used the controller board from Olimex that we bought thru=20
MicroController Pros, AVR-MT-128=20
For what it has , you can't beat the price, and it's very small and fits=20
in our robot.
=3DDan
Pittsburgh Robotics Society
STEVEN wrote:
>=20
>
> BASIC !! (urggghh !!), steve is right, their compilers are very buggy,=20
> stick with WinAvr, its free well documented, plenty of forum support=20
> what else do you need.
>
> You are right about the dev boards though , they do some good ones.
>
[Non-text portions of this message have been removed]
------------------------------------
(You need to be a member of avrclub -- send a blank email to avrclub-subscribe@yahoogroups.com )
Re: [AVR club] Re: Basic ISR question - where should the "meat" of the code go? In the ISR or in the while loop? - Dan Roganti - Oct 14 22:23:02 2009
STEVEN HOLDER wrote:
>
>
> hI DAN,
>
> How did you get on with AVRx , i assume you are up and running with it
> now ?
>
> I agree with the board below, very good value.
>
>
Steve,
I had to put the AVRx on the shelf for now. We still had to work out
several bugs in the code and hardware first. I may have to bug you again
once we iron out all the sensors and interfaces first. I really like to
get the RTOS running on this but this will be very new for us to get it
running the right way without help.
thanks
=Dan
------------------------------------
______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.
(You need to be a member of avrclub -- send a blank email to avrclub-subscribe@yahoogroups.com )
>
>
> hI DAN,
>
> How did you get on with AVRx , i assume you are up and running with it
> now ?
>
> I agree with the board below, very good value.
>
>
Steve,
I had to put the AVRx on the shelf for now. We still had to work out
several bugs in the code and hardware first. I may have to bug you again
once we iron out all the sensors and interfaces first. I really like to
get the RTOS running on this but this will be very new for us to get it
running the right way without help.
thanks
=Dan
------------------------------------
______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.
(You need to be a member of avrclub -- send a blank email to avrclub-subscribe@yahoogroups.com )