AVR-Chat

With all this talk on using bits & shifts & macros, I figured I 
should toss another one out:  Keeping track of which bits are used 
using the preprocessor...

I've been playing around with SiLabs' 8051 chips and their nifty 
digital crossbar (err... that thing is a pain, but it is nifty), and 
coming the AVR world has been a bit of a shock -- all pins don't do 
all things.

Background:

I've been playing with the AT90PWM2, and I wanted to add a I2C *or* a 
SPI bus to the project (no, not a silly DALI control.  I want it to 
talk to an Echelon part),  but after combing through the datasheets, 
it looked like the EUSART 
  1. wouldn't do I2C (nuts)
  2. SPI [slave] requires an additional line for the select, 
     and I'm using that for the power stage output.  The datasheets
     don't mention a way of hardcoding it (there's only 2 chips.  It 
     is *always* selected)

But figuring that out was annoying.

I've even been thinking of a way to do something like:

#define	PIN1	ADC0
#define PIN2	ADC1
#define PIN22	OCRA
#define PIN33	OCRB

#define ADC0_used
#define ADC1_used
#define OCR_used

//*** CheckPorts.h
#ifdef ADC0_used
#ifdef PA1_DIGITAL
#error "Pin one is ADC & Digital"
#endif
#endif
#ifdef PSC2_used
#ifdef SPI_ALTERNATE
#error "PSC2 uses SPI/SS_a as Bottom Mosfet"
#endif
#endif
  ...

---
But:
  1. Is this really useful for the compiler?  I'm beginning to keep 
it straight (for the current project; maybe I shouldn't be doing 3 at 
once)...
  2. Note the disconnect -- #define PIN1  ADC0, but I still have to 
redo it vice-versa (#define ADC0_used).  Keeping track of this seems 
worse than #1.

Do you guys keep it all in your head and comments, or is there anyone 
out there with a better way?

Thanks,
Thor

At 01:05 AM 27/03/2007, you wrote:
>2. SPI [slave] requires an additional line for the select,

What's so strange about this? ALL SPI implementations require
a slave select line, you can ground the SS pin if you like
and it will work but if for some reason you lose synch then it
will no longer work and will need to reset the processor.

Regards

John Samperi

********************************************************
Ampertronics Pty. Ltd.
11 Brokenwood Place Baulkham Hills, NSW 2153 AUSTRALIA
Tel. (02) 9674-6495       Fax (02) 9674-8745
Email: john@ampertronics.com.au
Website  http://www.ampertronics.com.au
*Electronic Design * Custom Products * Contract Assembly
********************************************************

--- In AVR-Chat@yahoogroups.com, John Samperi <samperi@...> wrote:
>
> At 01:05 AM 27/03/2007, you wrote:
> >2. SPI [slave] requires an additional line for the select,
> 
> What's so strange about this? ALL SPI implementations require
> a slave select line, you can ground the SS pin if you like
> and it will work but if for some reason you lose synch then it
> will no longer work and will need to reset the processor.

Hrm... I hadn't thought about losing sync; I guess I was hoping (now 
there's a naive word) that if it lost clock for so long, it would 
consider the transmission done.

The problem with the concept -- I'm just using PSCOUT00 from the PSC 
(also pin 1)... so I was hoping (but I didn't see how) that I could 
set SS_A to just be an SFR, and I could write a 0 to it, and use the 
SPI on 3, 4, & 5 to communicate.  To synchronize I was thinkging I 
could do the above bit in software, or I could use a different line 
(eg, I'm not using pin 12), and I'd put a decent delay in the SS -> 
data phase.

So I started looking at I2C (TWI/Neurowire/???), but it appears that 
the EUSART can't do TWI.  So I hacked together software 
implementation, but the way I did it is limiting the speed and 
detracting from the control loop performance.

Still looking for suggestions, but since I got hung up on the SS_A vs 
PSCOUT00, I'm also wondering if anybody is using some clever tools / 
preprocessor / ??? to keep the pins/functions from clobbering each 
other.

-Thor

>
> Still looking for suggestions, but since I got hung up on the SS_A vs
> PSCOUT00, I'm also wondering if anybody is using some clever tools /
> preprocessor / ??? to keep the pins/functions from clobbering each
> other.


I'd sure like to see one.
It scares me a bit that those bit definitions are just equivalencies for
0-7.
It's SO easy to get things wrong in a way that seems to work.

And we have the fun of the PIN, PORT, and DDR registers for each port.
I've caught myself a couple of times, setting up inits for all the ports and
then only actually DOING the init on porta, because I copyed and pasted from
the porta init and forgot to change the destinations.

I'm not sure how it would be handled though.

I usually end up with something like:

sbi beeper_out_port, beeper_out_pin

Which isn't bad, till you forget which port or pin that was, or you make an
update to the code that isn't supported by the comments.

When are we going to get the ability in one of these editors to insert
hyperlinks, so I don't have to re-re-re copy definition comment blocks
around, and then later go edit them all (I hope) when something changes?

Jack Ganssle did an article on this sort of thing a while back.
It's past 2001, where are the flying cars and software tools that actually
make life EASIER?


[Non-text portions of this message have been removed]

Hello,

I have this idea that I think should work, but might have some problems...

The first "A" (Mega8) would do some specialized tasks, and it currently 
talks to a PC through it's serial port.  The PC issues commands, and gets 
results.

I want to replace the PC with a second "B" controller (I'm thinking Mega324 
so I can connect one serial to "A", and another serial to a PC if needs be).

Would I have any problems if I clock both from the same (external) clock 
source?

I'm also thinking I may need faster speed, so I might connect one 8 bit port 
from "A" to "B" to transmit 8 bits at a time... and maybe use another 2 bits 
(interrupt input?) of another port for "Data Ready" and "ACK".

Am I missing something?

The SPI of "A" is already used and I'd rather not share it even if it would 
be possible.

If SPI would be much better... I might chose another controller that has 2 
SPI ports if such a thing exists...?

Thank you,

Cat

_________________________________________________________________
http://local.live.com/?mkt=en-ca/?v=2&cid=A6D6BDB4586E357F!420

Ought to work just fine.

If they are using the same clock, then if the baud rates
are also set to be the same, the baud rates WILL be the
same. This should be as close to zero-error async serial as
you can get. You can also use any arbitrary baud rate for
the micro-micro link as it does not have to fit any
standard in order to talk to a desktop host.

An external clock source should be good. There should be
little or no interaction between the two clocked chips.

Jim Wagner

On 27 Mar 2007 10:08:56 -0700,Tue, 27 Mar 2007 11:08:49
-0600
 "Cat C" <catalin_cluj@hotmail.com> wrote:
> Hello,
> 
> I have this idea that I think should work, but might have
> some problems...
> 
> The first "A" (Mega8) would do some specialized tasks,
> and it currently 
> talks to a PC through it's serial port.  The PC issues
> commands, and gets 
> results.
> 
> I want to replace the PC with a second "B" controller
> (I'm thinking Mega324 
> so I can connect one serial to "A", and another serial to
> a PC if needs be).
> 
> Would I have any problems if I clock both from the same
> (external) clock 
> source?
> 
> I'm also thinking I may need faster speed, so I might
> connect one 8 bit port 
> from "A" to "B" to transmit 8 bits at a time... and maybe
> use another 2 bits 
> (interrupt input?) of another port for "Data Ready" and
> "ACK".
> 
> Am I missing something?
> 
> The SPI of "A" is already used and I'd rather not share
> it even if it would 
> be possible.
> 
> If SPI would be much better... I might chose another
> controller that has 2 
> SPI ports if such a thing exists...?
> 
> Thank you,
> 
> Cat
> 
>
_________________________________________________________________
>
http://local.live.com/?mkt=en-ca/?v=2&cid=A6D6BDB4586E357F!420
> 

---------------------------------------------------------------
The Think Different Store
http://www.thinkdifferentstore.com/
For All Your Mac Gear
---------------------------------------------------------------

>
>
>
> An external clock source should be good. There should be
> little or no interaction between the two clocked chips.


My only worry would be EMI.  Plan on a series resistor between the clock
source and each "client" of about 100-ish ohms, and a definite return path
in the ground. Dont' let the grounds of the processors and clock
source connect by a meandering path.  The difference in radiated EMI can be
enormous.


[Non-text portions of this message have been removed]

At 12:59 AM 28/03/2007, you wrote:
>Hrm... I hadn't thought about losing sync;

Think about some noise clobbering JUST 1 clock pulse :)

>So I started looking at I2C (TWI/Neurowire/???), but it appears that
>the EUSART can't do TWI.

I can't remember which chip you were using but it is not one that
I'm familiar with. If it does not have hardware TWI then you can simply
use a bit banged version. AVR300 works well as a master (seems you have
already looked at this). Does the chip have an USI? It may help speeding
things up a bit.



Regards

John Samperi

********************************************************
Ampertronics Pty. Ltd.
11 Brokenwood Place Baulkham Hills, NSW 2153 AUSTRALIA
Tel. (02) 9674-6495       Fax (02) 9674-8745
Email: john@ampertronics.com.au
Website  http://www.ampertronics.com.au
*Electronic Design * Custom Products * Contract Assembly
********************************************************

On Tue, Mar 27, 2007 at 12:57:32PM -0500, Jim Wagner wrote:
> Ought to work just fine.
>
> If they are using the same clock, then if the baud rates
> are also set to be the same, the baud rates WILL be the
> same. This should be as close to zero-error async serial as
> you can get. You can also use any arbitrary baud rate for
> the micro-micro link as it does not have to fit any
> standard in order to talk to a desktop host.
>
> An external clock source should be good. There should be
> little or no interaction between the two clocked chips.

Sharing an external *clock* is fine, just don't go casually connecting
two CPUs to the same *crystal*.

I remember MC68HC11 documentation describing safe ways to do this but  
you
are playing in the analog domain.

-- 
David Kelly N4HHE, dkelly@HiWAAY.net
========================================================================
Whom computers would destroy, they must first drive mad.

Thanks to everybody.

It is a real clock, in fact coming from another "system".

I'll see how it goes.

Cat

_________________________________________________________________
http://local.live.com/?mkt=en-ca/?v=2&cid=A6D6BDB4586E357F!399

sorry for poor english;

first of all, you may misunderstand power of your
micro
and actual data rate you need to transfer between A
and B. for a common good idea it could be used by a
shared network using a RS485 bus or something, which
could work with any micro even with one serial port.

at the other hand, you need to call communication
software by pooling or by interrupts, which interrupts
are better, but your main logic will be difficult to
implement if you use pooling method.

the interrupt logic is a heavy way because of context
switching between interrupted task and communication
task.

but in common ways interrupt logic specially if
implemeted using a simple state machine is more
effective than you ever think of.

so, I suggest use a shared bus of micros, with a byte
address in all frames in a master-slave or token-bus
style.

maybe parallel data transfer is more faster than
serial interfacing but serial interfacing reduces
count of pins u need to communicate and micro itself
supports some features for you.

good luck;



 
____________________________________________________________________________________
Bored stiff? Loosen up... 
Download and play hundreds of games for free on Yahoo! Games.
http://games.yahoo.com/games/front