AVR-Chat

(had to send this through the list "post" web page. For some reason
my messages are not showing up on the list. My messages get to other 
Yahoo groups.  Anyone know why?)

> From: Behrooz

So you can evaluate my comments below, I am an Electrical Engineer 
(minor in computer design) by training but spent my professional life 
as a software developer (now retired) developing software for large 
communications/message switching applications in financial networks.

I have a (hobby) interest in process control, communications, home 
automation, etc. and selected the AVR as the family that best 
addressed my needs.

So, with that intro, ...

> ....
> So my questions are:
> 1-
> Since I don't have very much spare time (as a hobbyist)in learning 
new 
> programming language(and my fear of dealing with complex hardware 
> details), do you think it is better for me to stick to the Bascom-
Avr 
> with my growing program size, or not??

In my opinion you will usually pay a code size/speed penalty for 
the 'ease' that some higher-level languages (like Bascom-AVR) 
provide.  A lot of what they are doing for you is taking care 
of 'details' for you but they sometimes have to do it in a 'general' 
way so as to satisfy the needs of a variety of users.

I don't think that C would be much more difficult for you than 
structured Basic, especially because you now have a level of 
familiarity for what the AVR can do and how programming in the AVR 
environment works (edit, compile, simulate, burn, test, etc. ...).  
You also now have a familiarity with program flow, etc. that you 
didn't have before.

I would recommend that you give C a try with some small test programs 
and then try converting your Bascom application.

The biggest 'learning curve' area will probably be in initializing 
the various hardware devices and (if you want to use them) getting 
familiar with interrupt-driven code.  I'm not familiar with Bascom-
AVR but I assume it hides many of these details from you.  You will 
quickly develop (or acquire from this list and other Internet 
sources) code snippets that you can use over and over.

Once you know C there isn't anything you can't do on the AVR except 
some very specialized things (like task switching in an RTOS).  Even 
those you can do with WinAVR by dropping into assembler when you want 
to explore more.

> 2-
> If not, what is my best option? I saw good books on teaching 
> CodeVision in book stores, but I read on the internet that WinAvr 
has 
> alot more piece of code on the net (I used to copy-paste those  
pieces 
> to my bascom and it was helpful, so more code samples may be 
decisive) 
> Which one has less bug and is more common among C programers?

When I got into the AVR I purchased (and recommend) "Embedded C 
Programming and the Atmel AVR" by Barnett, Cox & O'Cull.  It seems to 
cover everything without being too "high level" or getting you lost 
in a lot of detail.  It is written to be used with CodeVision but I 
use WinAVR.

For beginning, I'd recommend WinAVR (free) used with AVR Studio (free 
from Atmel), a development board of your choice and the "Ice-Cube" 
Jtag device from ECROS Technology 
(http://www.ecrostech.com/AtmelAvr/AvrIceCube/index.htm).

AVR Studio will provide you framework to develop, compile, simulate, 
burn and test your programs as well as set breakpoints, step, etc. in 
the target system for debugging (using the Jtag device).

This is what I did in the beginning.  Because my work is getting a 
little more involved (RTOS's, Ethernet, etc.) I am now transitioning 
away from AVR Studio to tools that come with WinAVR like Programmers 
Workbench (IDE-like environment), AVRDude (burning, etc.), DBG 
(debugger), etc.

> 3-
> Is the C language exactly the same for WinAvr and CodeVision? Are C 
> and C ANSI Identical? (sorry if specially the last question seems 
very
> basic)

Unfortunately there are some differences between the available C 
compilers for the AVR (WinAVR, CodeVision, ImageCraft, etc.) 
particularly in the area of bit fields, registers, interrupts, etc. 
and they all have their own libraries with varying amounts 
of 'extras' so programs are slightly different from compiler to 
compiler.

All of the software components I suggested (AVR Studio, WinAVR) are 
free, so if you don't like them you can throw them away and it didn't 
cost you anything :-)

> Thanks in advance for ur reply.

Well, my advice may be worth what you paid for it (i.e.: 0) but I'm 
sure others on this list will jump in if I've led you astray :-)

Cheers,

Chuck Hackett
"Good judgment comes from experience, experience comes from bad 
judgment"
7.5" gauge Union Pacific Northern (4-8-4) 844 
http://www.whitetrout.net/Chuck

--- In AVR-Chat@yahoogroups.com, "Chuck Hackett" <egroupscdh@...> 
wrote:
Dear Chuck,

Glad to hear from you, and thanks for your in depth reply to my 
questions. Your instructive explanations encouraged me to go more 
through this and take advantage of your experience.

I wonder if it is good idea to create another topic, but I go on with 
this topic for now:

> Once you know C there isn't anything you can't do on the AVR except 
> some very specialized things (like task switching in an RTOS).  
Even  those you can do with WinAVR by dropping into assembler when 
you want  to explore more.
> This is what I did in the beginning.  Because my work is getting a 
> little more involved (RTOS's, Ethernet, etc.) 

U talked of RTOS. Never heared of it before, but my MCU needed to 
control RH, light level and temperature real time and show them on 
LCD, so I thought and then I made for myself a sort of virtual multi-
tasking procedure, for example:

Do
  Gosub v
  Gosub w
  Gosub x
  Gosub y
  Gosub z
Loop
End

Since the whole loop takes about 0.1-0.2 second, it seems 
multitasking to the user. It works rather fine now even with my large 
code. But is it all we can do to make a multitasking procedure?


> > 3-
> > Is the C language exactly the same for WinAvr and CodeVision? Are 
C 
> > and C ANSI Identical? (sorry if specially the last question seems 
> very
> > basic)
> 
> Unfortunately there are some differences between the available C 
> compilers for the AVR (WinAVR, CodeVision, ImageCraft, etc.) 
> particularly in the area of bit fields, registers, interrupts, etc.

So what else remains? lol. If I find a snipplet I have to become 
Poirot to find the clues and know which version it is written for?!

> and they all have their own libraries with varying amounts 
> of 'extras' so programs are slightly different from compiler to 
> compiler.
Slightly. I hope so.  :)

Thanks again and waiting...
Behrooz

What might be a standard for 'fast'? If Gosubs take one milisecons is 
it fast? If the whole process takes less tha 0.1 Sec then what is the 
difference if you break it into 1000 piececs or 10? Doesnt it make 
you work harder, if you play too much with ISRs? 

Behrooz

--- In AVR-Chat@yahoogroups.com, "David VanHorn" <microbrix@...> 
wrote:
>
> > U talked of RTOS. Never heared of it before, but my MCU needed to
> > control RH, light level and temperature real time and show them on
> > LCD, so I thought and then I made for myself a sort of virtual 
multi-
> > tasking procedure, for example:
> >
> > Do
> >  Gosub v
> >  Gosub w
> >  Gosub x
> >  Gosub y
> >  Gosub z
> > Loop
> > End
> >
> 
> This is the guts of a cooperative multitasker.
> The trick is to divide up the tasks so that none of them really do
> very much, and they don't do anything if they don't have to.
> Then take your time-critical I/O and handle that in ISRs, just
> buffering the data into ram and letting the system deal with the
> buffered data.
> 
> In one system I'm working on, there's an ISR to catch serial data 
from
> a GPS, putting that in a serial input buffer.
> One of the routines in the main loop scans that buffer for a valid
> NMEA sentence.
> Another routine takes a valid sentence from that buffer and puts it 
in
> another buffer for parsing.
> Another parses any sentences that arrive.
> ...
> ...
> ...
> and so on.
> 
> Each does very little, and the idea is to return to main as fast as 
possible.
>

> U talked of RTOS. Never heared of it before, but my MCU needed to
> control RH, light level and temperature real time and show them on
> LCD, so I thought and then I made for myself a sort of virtual multi-
> tasking procedure, for example:
>
> Do
>  Gosub v
>  Gosub w
>  Gosub x
>  Gosub y
>  Gosub z
> Loop
> End
>

This is the guts of a cooperative multitasker.
The trick is to divide up the tasks so that none of them really do
very much, and they don't do anything if they don't have to.
Then take your time-critical I/O and handle that in ISRs, just
buffering the data into ram and letting the system deal with the
buffered data.

In one system I'm working on, there's an ISR to catch serial data from
a GPS, putting that in a serial input buffer.
One of the routines in the main loop scans that buffer for a valid
NMEA sentence.
Another routine takes a valid sentence from that buffer and puts it in
another buffer for parsing.
Another parses any sentences that arrive.
...
...
...
and so on.

Each does very little, and the idea is to return to main as fast as possible.

On Jan 22, 2008 11:44 AM, Behrooz <behrooz_hariri@yahoo.com> wrote:
> What might be a standard for 'fast'?

Depends ENTIRELY on the application. That's what they pay us the big
bucks for, to know what's appropriate for a given system.

>If Gosubs take one milisecons is it fast?

That might be horribly slow for some apps, and way overkill for others.

> If the whole process takes less tha 0.1 Sec then what is the
> difference if you break it into 1000 piececs or 10?

This is about multitasking though.  If I have a lot of things going on
(frequently I do) then it matters.

>Doesnt it make you work harder, if you play too much with ISRs?

??????  Hell no.  ISRs are your friend!  Just don't abuse them.

And that is the core of multi tasking real time code.  The standard for fast
is as fast as you need to go in order to get all the stuff you need done on
time.

If you're inside a laser printer and the mirror is coming around you'd
better be ready so fast means one thing.  In an instrument I've worked on,
fast meant that I had to have a piece of data from a sensor updated every
100ms.  On another instrument, it was 300 channels of ADC every 100ms.  In
each case you just need to structure your code so that the stuff that MUST
happen on time gets done and the other stuff shares the leftover time.  The
RTOS takes care of that for you so that you don't have to time everything in
a main loop to make it come out right.

-----Original Message-----
From: AVR-Chat@yahoogroups.com [mailto:AVR-Chat@yahoogroups.com] On Behalf
Of Behrooz
Sent: Tuesday, January 22, 2008 8:44 AM
To: AVR-Chat@yahoogroups.com
Subject: [AVR-Chat] Re: WinAvr or CodeVision, which one is more public?

What might be a standard for 'fast'? If Gosubs take one milisecons is 
it fast? If the whole process takes less tha 0.1 Sec then what is the 
difference if you break it into 1000 piececs or 10? Doesnt it make 
you work harder, if you play too much with ISRs? 

Behrooz

--- In AVR-Chat@yahoogroups.com, "David VanHorn" <microbrix@...> 
wrote:
>
> > U talked of RTOS. Never heared of it before, but my MCU needed to
> > control RH, light level and temperature real time and show them on
> > LCD, so I thought and then I made for myself a sort of virtual 
multi-
> > tasking procedure, for example:
> >
> > Do
> >  Gosub v
> >  Gosub w
> >  Gosub x
> >  Gosub y
> >  Gosub z
> > Loop
> > End
> >
> 
> This is the guts of a cooperative multitasker.
> The trick is to divide up the tasks so that none of them really do
> very much, and they don't do anything if they don't have to.
> Then take your time-critical I/O and handle that in ISRs, just
> buffering the data into ram and letting the system deal with the
> buffered data.
> 
> In one system I'm working on, there's an ISR to catch serial data 
from
> a GPS, putting that in a serial input buffer.
> One of the routines in the main loop scans that buffer for a valid
> NMEA sentence.
> Another routine takes a valid sentence from that buffer and puts it 
in
> another buffer for parsing.
> Another parses any sentences that arrive.
> ...
> ...
> ...
> and so on.
> 
> Each does very little, and the idea is to return to main as fast as 
possible.
>




 
Yahoo! Groups Links






-- 
No virus found in this incoming message.
Checked by AVG Free Edition. 
Version: 7.5.516 / Virus Database: 269.19.9/1237 - Release Date: 1/22/2008
11:04 AM