Searching \ for 'Syncing' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/index.htm?key=syncing
Search entire site for: 'Syncing'.

No exact or substring matches. trying for part
PICList Thread
'Syncing to the prescaler (was: "Re: a mpsim questi'
2000\02\06@181008 by Andrew Warren

face
flavicon
face
Paul B. Webster VK2BZC <spam_OUTpaulbTakeThisOuTspammidcoast.com.au> wrote:

> using no prescaler, and performing an ADDWF on the timer rather
> than simply loading a value .... nicely compensates for interrupt
> latency.

If one MUST use the TMR0 prescaler, though, it's still possible to
get precisely-accurate timing by synchronizing the ADDWF with the
prescaler rollover.

Those of you who were on the list three years ago have seen this
before, but for everyone else, here's an example of how to do it:

   ; Enter this section with TMR0 between 128 and 255, inclusive,
   ; and the prescaler divide-by-ratio set to divide-by-4.

   WAITFOR0:

       BTFSC   TMR0,BIT7       ;WAIT FOR TMR0 TO OVERFLOW.
       GOTO    WAITFOR0        ;

   ; AT THIS POINT (SINCE OUR "WAITFOR0" LOOP HAS A RESOLUTION OF 3
   ; CYCLES), THE TMRO:PRESCALER REGISTERS CAN BE EQUAL TO ANY OF
   ; THE FOLLOWING COMBINATIONS:
   ;
   ;     TMRO  PRE
   ;      00    2
   ;      00    3
   ;      01    0

       BTFSS   TMR0,BIT0       ;IF TMR0 = 01, WASTE 2 CYCLES.
       GOTO    $+1             ;OTHERWISE, WASTE 3 CYCLES.

   ; AT THIS POINT, TMR0:PRE CAN ONLY BE EQUAL TO ONE OF THESE:
   ;
   ;     TMRO  PRE
   ;      01    1
   ;      01    2

       GOTO    $+1             ;WASTE TWO CYCLES.

   ; AT THIS POINT, TMR0:PRE CAN ONLY BE EQUAL TO ONE OF THESE:
   ;
   ;     TMRO  PRE
   ;      01    3
   ;      02    0

       BTFSS   TMR0,BIT1       ;IF TMR0 = 02, WASTE 2 CYCLES.
       GOTO    $+1             ;OTHERWISE, WASTE 3 CYCLES.

   ; AT THIS POINT, TMR0:PRE CAN ONLY BE EQUAL TO:
   ;
   ;     TMRO  PRE
   ;      02    2

       GOTO    $+1              ;WASTE TWO CYCLES.

   ; TMR0 ALWAYS INCREMENTS FROM 02 TO 03 RIGHT HERE.

       MOVLW   RELOAD+4         ;RELOAD TMR0.  WE NEED TO ADD 4 TO
       MOVWF   TMR0             ;THE RELOAD VALUE BECAUSE THESE TWO
                                ;INSTRUCTIONS TAKE 2 CYCLES TO
                                ;EXECUTE AND THERE'S AN ADDITIONAL
                                ;2-CYCLE SYNCHRONIZATION DELAY.
                                ;WHEN TMR0 STARTS INCREMENTING
                                ;AGAIN, IT WILL BE AT -EXACTLY- THE
                                ;MOMENT THAT TMRO:PRE WOULD HAVE
                                ;ROLLED FROM 03:3 TO 04:0.

-Andy


=== Andrew Warren - .....fastfwdKILLspamspam@spam@ix.netcom.com
=== Fast Forward Engineering - Vista, California
=== http://www.geocities.com/SiliconValley/2499
===
=== The reports of my demise have been greatly exaggerated.


'[PIC:] Syncing a receiver to a USART stream w/o'
2003\12\12@190711 by Ishaan Dalal
flavicon
face
I have a USART, say A, sending out a continous stream of data. I'd like my
receiver USART, say B, to sync to this continous stream and receive data,
but without B itself transmitting anything, USART or otherwise
(ACK/NACK...).

Other than using something like a training byte/preamble (e.g. 0xAA) every
few bytes, what ways are there to do this?

Thanks,
Ishaan

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestspamKILLspammitvma.mit.edu

2003\12\12@194447 by Sergio Masci

picon face
----- Original Message -----
From: Ishaan Dalal <.....izxKILLspamspam.....XIZX.NET>
To: <EraseMEPICLISTspam_OUTspamTakeThisOuTMITVMA.MIT.EDU>
Sent: Saturday, December 13, 2003 12:05 AM
Subject: [PIC:] Syncing a receiver to a USART stream w/o


{Quote hidden}

The simplest way is to restrict the data bytes so that some values are reserved
for control. If you reserved the char '^' as an escape character and the
character '~' as a sync character, you could arrange for the sender to insert
the escape character before all escape and sync characters that occur in the
data stream and for the receiver to convert these back into data.

If the receiver sees '^~' it treats this as data '~'
If the receiver sees '^^' it treats this as data '^'
If the receiver sees '~' it treats this as sync (control info not data)
Any other data is treated as data

A different scheme would be to use the same character for both escape and sync.
Here the sender would always add an extra sync character to every valid sync
character found in the real data stream and the receiver would strip one away.

If the receiver sees '~~' it treats this as data '~'
If the receiver sees '~~~~' it treats this as data '~~'
If the receiver sees '~' it treats this as sync (control info not data)
If the receiver sees '~~~' it treats this as data '~' + sync OR sync + data '~'
If the receiver sees '~~~~~' it treats this as data '~~' + sync OR sync + data
'~~' OR data '~' + sync + data '~'

In this scheme you should be carefull about mixing sync and data '~' (sending
sync immediately before or after data '~') since the receiver will not know
which of the '~' to sync on

You could send the sync automatically at given time intervals, maybe once a
second.

Regards
Sergio Masci

http://www.xcprod.com/titan/XCSB - optimising structured PIC BASIC compiler

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestspamspam_OUTmitvma.mit.edu

2003\12\12@194902 by David Minkler

flavicon
face
Ishaan,

Just do it.  If the clocks on the two USARTs are within about 3% (easy
for crystals) the data should transmit cleanly.   If they aren't that
close, a response from B won't help anyway.

A little dead time (a couple of data byte times is plenty) every now and
then will allow the system to re-synch if it gets out of synch.

Best regards,

Dave

Ishaan Dalal wrote:
{Quote hidden}

--
http://www.piclist.com hint: To leave the PICList
KILLspampiclist-unsubscribe-requestKILLspamspammitvma.mit.edu

2003\12\12@195317 by Bob Ammerman

picon face
If you are not in sync, then you will probably be getting framing errors.
So, when you get a framing error, reset the receiver and keep looking for
alignment.

After seeing "N" bytes go by without a framing error you can declare
yourself "in sync".

Alternatively, you can embed my magic self-syncing bytes in the stream.
These bytes have the special property that they force the receiver to align,
within a relatively few bytes, no matter where it is when starting to
receive. See:

http://www.piclist.com/techref/microchip/ammermansync.htm

Although that is discussing an RF link, the same theory would apply in your
case.

Bob Ammerman
RAm Systems



{Original Message removed}

2003\12\12@215724 by William Chops Westfield

face picon face
On Friday, Dec 12, 2003, at 16:05 US/Pacific, Ishaan Dalal wrote:

> I have a USART, say A, sending out a continous stream of data. I'd
> like my
> receiver USART, say B, to sync to this continous stream and receive
> data,
> but without B itself transmitting anything, USART or otherwise
> (ACK/NACK...).
>
> Other than using something like a training byte/preamble (e.g. 0xAA)
> every
> few bytes, what ways are there to do this?
>
Why do you think you need to do something like that?  if you're running,
you should end up resycnchronizing each byte during the stop/start bits,
so there's no reason to expect that you'd drift out of synch.  For
synchronous, you have a clock and its not an issue.

Unidirectional serial data streams work fine, usually.  Consider
printers...

BillW

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestTakeThisOuTspammitvma.mit.edu

2003\12\12@231553 by Dan Oelke

flavicon
face
Not to be disrespectful - but this looks like you just re-invented
byte-stuffed HDLC.

Punching HDLC and "byte stuffing" into google gets you a number of
hits.  Apparently PPP uses a form of HDLC byte stuffing.

I know data-link/network protocols really well, but I don't know the PIC
USART very well.

If you have byte synchronization from the port, then you can just use a
byte stuffing scheme and as someone else said, just keep checking your
check sequence.  If your CRC/checksum fails repeatedly (usually 3x in a
row) then declare loss of frame and start hunting for a new start of frame.

If you don't have byte synchronization then things get more interesting as
you need to check for your start of frame flag, shift a *bit* then check
again, and repeat.  Once you have start of frame found you just declare
that as your byte boundary and read 8 bits at a time.  That's something
usually easier done in hardware than software, but doable.

That's probably more information than you need - especially since I gave
two options not knowing enough about the PIC hardware in that area.....

Dan

At 12:45 AM 12/13/2003 +0000, you wrote:

{Quote hidden}

--
http://www.piclist.com hint: To leave the PICList
spamBeGonepiclist-unsubscribe-requestspamBeGonespammitvma.mit.edu

2003\12\12@232008 by Bob Ammerman

picon face
> Unidirectional serial data streams work fine, usually.  Consider
> printers...
>
> BillW

This is not the case if you start 'listening' to the data in mid-stream.
Your receiver can easily get confused about what is a start bit, and end up
with a bunch of framing errors. This is usually self correcting after a
reasonably short period of time, but I have seen cases where it went on
merrily out of sync indefinitely (it all depends on the data and the
receiver implementation.)

Bob Ammerman
RAm Systems

--
http://www.piclist.com hint: To leave the PICList
TakeThisOuTpiclist-unsubscribe-requestEraseMEspamspam_OUTmitvma.mit.edu

2003\12\13@003030 by Ishaan Dalal

flavicon
face
Bob Ammerman wrote...


> If you are not in sync, then you will probably be getting framing errors.
> So, when you get a framing error, reset the receiver and keep looking for
> alignment.

That seems to be the best idea, for now.

> http://www.piclist.com/techref/microchip/ammermansync.htm

This is an IR link @ 2400 bps; will try the magic bytes if I need to "drop"
more than 16 bytes or so with the frame error sync.

BTW, once the USART receive is switched on (16F877), does it automatically
give a framing error and set RCIF if it does not receive any data in a given
time (i.e. there is NO transmission at the other end)? I've had this happen
and it sounds weird; but the RX pin is held low locally when idle, so maybe
that's what confuses it.

Cheers,
Ishaan

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2003\12\13@004533 by Russell McMahon

face
flavicon
face
> This is an IR link @ 2400 bps; will try the magic bytes if I need to
"drop"
> more than 16 bytes or so with the frame error sync.

The most magic of all magic bytes is no byte at all. If you have the ability
to insert such bytes into the data stream then you presumably also have the
ability to pause transmission occasionally. If you pause for 1 word time (10
bits) (so that the circuit is at logical 1 / mark) then any properly behaved
UART that is monitoring the line will automatically drop into sync when the
character stream is restarted. This is the whole point of async
communications. (Having a longer stop "bit" will also increase
synchronisation capability, but not as well as just stopping sending
occasionally).




       Russell McMahon
.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2003\12\13@033053 by Sergio Masci

picon face
Dan Oelke wrote:

{Quote hidden}

No offense taken Dan.

I read the original post as meaning synchronising data not the bit stream - as
in sending groups of binary data bytes (maybe floating point or long integer) as
a stream. Without knowing a lot more about the data being sent it just struck me
that this was the simplest way to inject markers into binary data. I was
actually borrowing from HDLC rather than trying to re-invent it :-)

Regards
Sergio Masci

http://www.xcprod.com/titan/XCSB - optimising structured PIC BASIC compiler

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2003\12\13@033715 by Sergio Masci

picon face
Russell McMahon wrote:

> > This is an IR link @ 2400 bps; will try the magic bytes if I need to
> "drop"
> > more than 16 bytes or so with the frame error sync.
>
> The most magic of all magic bytes is no byte at all. If you have the ability
> to insert such bytes into the data stream then you presumably also have the
> ability to pause transmission occasionally. If you pause for 1 word time (10
> bits) (so that the circuit is at logical 1 / mark) then any properly behaved
> UART that is monitoring the line will automatically drop into sync when the
> character stream is restarted. This is the whole point of async
> communications. (Having a longer stop "bit" will also increase
> synchronisation capability, but not as well as just stopping sending
> occasionally).
>
>
>
>
>         Russell McMahon

Adding parity would also help in this respect

Regards
Sergio Masci

http://www.xcprod.com/titan/XCSB - optimising structured PIC BASIC compiler

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2003\12\13@044922 by Samuel BOUQUET

flavicon
face
If you don't have the ability of changing the stream, a solution is to
ignore hardware USART and making one by software

In the stream, there will be some characters, or some chain of
characteres you can recognize.
First, I will connect the RX to a portB pin, and activate the int_portb.
Second, i will use a timer to count the number of 0 or 1 between each
trig of the int_portb
The int portb will "construct" a chain of 0-1. let's go to 30bit. This
chain will contain all the startbit, data bit, parity bit and stop bit
in this order.
The third phase is to "analyse" this chain in order to know where are
the start and stop bit.

If your stream contains only (or mainly) alphanumeric characters, it
will be easier
If your stream contains parity bit, it will be more easier.

Once you have find that, you can start the hardware USART between the
stop and the start bit.

Do you have more info about your stream: baud rate, format (7, 8 or 9
bit) and his content....


Sam

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2003\12\13@064451 by Ishaan Dalal

flavicon
face
Sam wrote...

> Do you have more info about your stream: baud rate, format (7, 8 or 9
> bit) and his content....

Baud rate is 1200 (or if I can get it that far with only parity and a
reasonably low error ratio) 2400 bps at most. There's 7 actual data bits
needed, UART transmits 8 of course; 9-bi transmission can also be used. The
stream is actually data from a PC parallel port to a printer (7-bit ASCII).

Speaking of which, is SPP printer communication limited to using 7-bits, or
do higher level "languages" such as PCL or PostScript use non-ASCII
characters (8-bit)?

Cheers,
Ishaan

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2003\12\13@070355 by Sergio Masci

picon face
----- Original Message -----
From: Ishaan Dalal <RemoveMEizxspamTakeThisOuTXIZX.NET>
To: <PICLISTEraseMEspam.....MITVMA.MIT.EDU>
Sent: Saturday, December 13, 2003 11:44 AM
Subject: Re: [PIC:] Syncing a receiver to a USART stream w/o


{Quote hidden}

8 bit

Regards
Sergio Masci

http://www.xcprod.com/titan/XCSB - optimising structured PIC BASIC compiler

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2003\12\13@085005 by Bob Ammerman

picon face
> The most magic of all magic bytes is no byte at all. If you have the
ability
> to insert such bytes into the data stream then you presumably also have
the
> ability to pause transmission occasionally. If you pause for 1 word time
(10
> bits) (so that the circuit is at logical 1 / mark) then any properly
behaved
> UART that is monitoring the line will automatically drop into sync when
the
> character stream is restarted. This is the whole point of async
> communications. (Having a longer stop "bit" will also increase
> synchronization capability, but not as well as just stopping sending
> occasionally).
>
>         Russell McMahon
> .

This is absolutely correct. There is one small problem however.... it is
sometimes tricky to ensure a one-character-time idle on the link.

Also, my "magic-bytes" solution was intended to apply over an RF link where
a long idle time could confuse the data slicer. Note that such an issue
might also apply to an IR link.

If the data-slicer problem is not an issue, I am sure that there is a
shorter 'magic' sequence that would ensure byte alignment. This would allow
the transmitter to continue sending characters at all times, and not have to
pause.

Bob Ammerman
RAm Systems

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2003\12\13@094851 by Dan Oelke

flavicon
face
Hey - I like that phrase - I'll use it in the future "borrowing from xxx
not reinventing it"

<very big grin>

Dan


{Quote hidden}

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2003\12\13@204821 by Lucas Hartmann

flavicon
face
Ten seconds ago I had a problem like yours.
Try using SLIP, worked for me.

Look at google for RFC 1055.

Very simple one.
Defines only 4 constants (ESC, END, ESC_ESC and ESC_END).

Lucas Hartmann.

--{Original Message removed}

2003\12\14@092832 by Olin Lathrop

face picon face
Ishaan Dalal wrote:
> I have a USART, say A, sending out a continous stream of data. I'd
> like my receiver USART, say B, to sync to this continous stream and
> receive data, but without B itself transmitting anything, USART or
> otherwise (ACK/NACK...).
>
> Other than using something like a training byte/preamble (e.g. 0xAA)
> every few bytes, what ways are there to do this?

There are many ways to address this and the best answer depends on a lot of
factors unique to your application.  Can the electrical connection itself be
considered reliable?  Do both ends initialize at the same time, like at
power up?  Must a receiver be able to sync to the middle of an arbitrary
stream?  How much of the serial bandwidth is really needed for the data?

I usually structure my host to/from PIC serial communication in the form of
command and response packets.  "Commands" are sent by the host, and
"responses" sent by the PIC, although they may not always be in direct
response to a command.

Each packet starts with an opcode byte followed by whatever data bytes might
be defined for that command/response.  Each receiver knows about all
possible packets it might receive, and stays in sync by knowing how many
data bytes follow each different opcode byte.  All undefined opcodes are
ignored.  At least one opcode is specifically reserved as NOP, which means
it has no data bytes and should be ignored.  0, 255, or both are good
choices for NOP opcodes because these are the most likely results of line
glitches.

This scheme can be easily arranged to have a known upper packet length
limit.  Each side can send out at least that many NOP opcodes on startup or
whenever resync is required.  This guarantees the other side will interpret
the next byte as an opcode.

If packets are only sent occasionally, I often define a packet timeout.
Within a packet, bytes must be sent in rapid succession.  If a receiver sees
more than a 100mS gap, for example, then the next byte must be interpreted
as an opcode.

If the connection is unreliable or a receiver must synchronize mid stream,
checksums and short packets can help.  To synchronize, a receiver buffers as
many bytes as can be in the longest packet.  It treats each new byte as a
potential start of packet until all conditions (valid opcode, valid
checksum, possibly timeout) are met for a complete packet.  The sender can
make this easier by sending NOP opcodes on occasion, or when it has nothing
else to send.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\12\14@093640 by Olin Lathrop

face picon face
Bob Ammerman wrote:
> This is not the case if you start 'listening' to the data in
> mid-stream. Your receiver can easily get confused about what is a
> start bit, and end up with a bunch of framing errors. This is usually
> self correcting after a reasonably short period of time, but I have
> seen cases where it went on merrily out of sync indefinitely (it all
> depends on the data and the receiver implementation.)

Note that a single 0 or FFh byte forces byte synchronization.  Each of these
contain only a single rising edge, which is the leading edge of the start
bit.  There are a total of 9 codes that have this property.  Any one of them
will guarantee byte synchronization for the following byte.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\12\14@193932 by Josh Koffman

flavicon
face
Does anyone else see Lucas' emails as being sent in June?
Subject: Re: [PIC:] Syncing a receiver to a USART stream w/o
Date: Fri, 20 Jun 2003 22:18:29 -0300

Josh
--
A common mistake that people make when trying to design something
completely foolproof is to underestimate the ingenuity of complete
fools.
       -Douglas Adams

Lucas Hartmann wrote:

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\12\14@195839 by Ishaan Dalal

flavicon
face
Josh wrote...

> Does anyone else see Lucas' emails as being sent in June?
> Subject: Re: [PIC:] Syncing a receiver to a USART stream w/o
> Date: Fri, 20 Jun 2003 22:18:29 -0300

Yes. His past few emails (as of the last week) also have wrong time stamps.

Let's hope his next post heralds a working flux capacitor ;)

Cheers,
Ishaan

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\12\15@001647 by William Chops Westfield

face picon face
On Sunday, Dec 14, 2003, at 06:34 US/Pacific, Olin Lathrop wrote:

> Note that a single 0 or FFh byte forces byte synchronization.

Is that true with hardware uarts?  I can see that a single 0 or FF
must cause a framing error, but is it certain that a framing error
will result in correct re-synchronization?

BillW

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\12\15@102946 by Olin Lathrop

face picon face
William Chops Westfield wrote:
>> Note that a single 0 or FFh byte forces byte synchronization.
>
> Is that true with hardware uarts?  I can see that a single 0 or FF
> must cause a framing error, but is it certain that a framing error
> will result in correct re-synchronization?

I'm not sure what you are asking.  A 0 or FFh byte by itself looks like a
single positive pulse.  It therefore has only one rising edge, which is what
the receiving UART uses to synchronize at the bit level.

A UART that is out of sync might confuse a rising edge in the middle of the
byte as the start of a new start bit.  This confusion can in theory continue
as long as data rising edges are spaced less than a full character time
apart.  The 0 and FFh bytes (and 7 others) contain only a single rising
edge, which is the start of the start bit.  The next rising edge is
therefore at least a full character time later, and must the start of the
next start bit.  No matter where the UART thought it was in the bit
sequence, it should be able to resync after just one such byte.  Whether it
actually does depends on the implementation and possibly how fast the
software can clear a framing error condition so that it is ready to
interpret the next rising edges as the start of a start bit.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


'[OT]SyncingworkCand home email client.'
2005\06\01@200515 by Michael Davidson
flavicon
face
> On Wed, 2005-06-01 at 13:07 -0700, Harold Hallikainen wrote:
> > A couple other approaches... One would be to use IMAP instead of
> > POP. Then all your folders, etc. stay on the server. I use
> > SquirrelMail as a webmail client that I can use anywhere, and get
> > access to the tons of saved email.
>
> Only BIG problem in my mind is IMAP requires the server to be alive to
> access ANY of your email, that's bad when your connection goes down,
> or the server goes down.

I've never encountered a mail client (apart from web ones) that don't keep a local cache. So you'll always be able to play with your existing mail, just not necessarily the new stuff you haven't synced with yet.
But then, that's going to be occur if you use your POP-syncing method, so it's a moot point, right? :)

{Quote hidden}

I'd definately go the way of IMAP. It's designed to facilitate working with your email from multiple locations, so why not use it rather than trying to shoehorn POP to do the same thing?

I personally work with 3 IMAP accounts and 1 POP account from this mail client. Two of the IMAP accounts I then use via a webterface from other locations. It works great. Provided I don't click the "Show all mail"
link as I'd then have to wait for several thousand message titles to be displayed over the web :)

Michael Davidson

--
Fortune:

Genetics explains why you look like your father, and if you don't, why you should.



'[EE] Issues syncing PIC24FJ128 with C328 camera mo'
2007\11\05@153710 by nesl7998
picon face

I am having issues syncing a Microchip Explorer 16 demo board (running a
PIC24FJ128) with a C328 camera module. I am sending the data signal
"0xAA0D00000000" at a baud rate of 9600 through UART1. I verified the signal
with an oscilloscope and comparing the signal to the one pictured in the
C328's documentation giving an exact match. My problem is that after sending
this signal, I am not receiving an acknowledgment or sync signal from the
camera. Is there a specific baud rate or delay between signals I need to
use? Is there an initial toggle signal needed to be sent (0x5 or 0xA) before
the sync signal is to be sent?
--
View this message in context: www.nabble.com/Issues-syncing-PIC24FJ128-with-C328-camera-module-tf4752514.html#a13589621
Sent from the PIC - [EE] mailing list archive at Nabble.com.

2007\11\19@102524 by nesl7998

picon face

No, unfortunately my issue still goes unsolved. I've re-checked my code and
the outgoing signal on the UART transmit pin, and both look like they should
work fine. I'm currently in the process of converting my code to 8-bit, as I
have an 8-bit demo board that uses a EUSART with very few peripherals
attached. I am hoping that I will be able to see some sort of signal
returned from the camera. You say you have an eval board, have you scoped
the board's transmit signal to the camera? If so, what are you getting? I am
sending a sync signal, followed by a 10 (signifies end of byte).

piecurus wrote:
{Quote hidden}

--
View this message in context: www.nabble.com/Issues-syncing-PIC24FJ128-with-C328-camera-module-tf4752514.html#a13838045
Sent from the PIC - [EE] mailing list archive at Nabble.com.

2007\11\20@101513 by nesl7998

picon face

I have tinkered with the baudrate a little. I've tried sending at 14400 and
9600 bps, and neither gave me results. The camera module says it has auto
baudrate detection, but I question the validity of it. I'm using an internal
clock. How did you get the camera to send data back? I haven't gotten as
much as a single bit from the unit.


piecurus wrote:
{Quote hidden}

--
View this message in context: www.nabble.com/Issues-syncing-PIC24FJ128-with-C328-camera-module-tf4752514.html#a13858814
Sent from the PIC - [EE] mailing list archive at Nabble.com.

More... (looser matching)
- Last day of these posts
- In 2007 , 2008 only
- Today
- New search...