To all PICLIST users:
I am sorry if these are a repetitive question, but i suscribe to
the PICLIST yesterday.=20
I need made and RS-485 multi-drop LAN, using severals modules based
on PIC's.
Could you please inform me about any books, papers, or any bibliografy on
RS-485 and books, papers, over communications protocol, asynchronous or
synchronous.
Many thanks in advance.
Dr. Eugenio Martin Cuenca
Dpto. de Biolog=EDa Animal y Ecolog=EDa
Facultad de Ciencias
Universdiad de Granada - Spain.
Email:spam_OUTemartinTakeThisOuTgoliat.ugr.es
Research Group of Chronobiology and Ecophysiology of Fishes
=20
> Could you please inform me about any books, papers, or any bibliografy on
> RS-485 and books, papers, over communications protocol, asynchronous or
> synchronous.
> Many thanks in advance.
>
We have a brief app note on RS-485 on our web site at http://www.bb-elec.com. Also, there are many good app notes in the back of
the National Semiconductor Interface data book.
-mike
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Mike Fahrion .....mfahrionKILLspam@spam@bb-elec.comhttp://www.bb-elec.com/
B&B Electronics Mfg Co ph.(815) 433-5100 ext.215 fax (815) 434-7094
707 Dayton Road PO Box 1040 Ottawa IL 61350
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Saludos, de otro miembro de esta lista en Espa=F1a. (Greetings, from=20
other list member at Spain).
> I need made and RS-485 multi-drop LAN, using severals modules based
>on PIC's.
>Could you please inform me about any books, papers, or any bibliografy on
>RS-485 and books, papers, over communications protocol, asynchronous or
>synchronous.
You can find a very good description and a lot of tips and tricks,=20
for the "phisical layer" of protocol (RS-485), in the following book
of Texas Instrument:
RS-422 and RS-485 Interface Circuits
Data transmision and Control Circuits
Aplication and Data Book (Year 92)
SLLAE01
Anybody has information about implementing RS-485 "network" protocol on a PIC 16C84 or 16C71?
I'm looking for software capable of handling half-duplex comms (single pair of RS-485 cable) between various devices (minimum 64). Speed is not important. I have already some ideas but I don't want to reinvent the wheel...
I don't think there's one real standard to use. The first think you've to
decide is what you want to send over. Pure binaire packets, or just ASCII
command to commercially bought measurement equipment. In the last case you
could take a look on the ADAM-4000 serie from Advantech. They have made all
kind of adressable device like AD, IO, timers, adressable RS232 ect.
If you want to go binairy it's another case. ADAM is total useless for this
transport :-(. Before the decision fell to buy the ADAM stuff I already
invented a protocol to implement. The 'problem' with (little) PIC in general
is that it doesn't have much ram. If you send a binaire packet, you have to
receive it totaly before you can analyse it. That would really restrict the
length of the packets.
So I thought of this:
Adress packet: length always 6 bytes
byte 1: device ID I
byte 2: device ID II
byte 3: number of bytes of data packet
byte 4: number of bytes of data packet
byte 5: checksum
byte 6: checksum
Data packet: length variable always even number
byte 1: Command to execute
byte 2: data
byte 3: data
| |
byte : status
byte : status
byte : checksum
byte : checksum
The idea behind the two packages is that if a device detects it's adressed
for him, it deletes the first package (except number if bytes) And has
memory free for the data package. If it's not adressed for him it does NOT
store the data-packet, just simply count down the number of bytes. In this
way also very large packets can be send to a computer or an other RAMfull
device.
Incase of binaire transportation to multiple devices there's always a change
that a header will be recognized in a data-packet. In this proposal the
chance is 256^-6. Hope I've got a bigger chance to win a lottery ;-)
Just an idea....
Edwin
Edwin Baaij (Electronic Engineer)
*********************************************************************
University of Amsterdam phone: +31-20-5256346
Van der Waals,- ZeemanInstitute fax: +31-20-5255877
Valckenierstraat 65-67 e-mail: baaijspam_OUTphys.uva.nl
1018 XE Amsterdam
*********************************************************************
Hi Eric,
The choice of protocol is really dependant on the application, and
how much effort you wish to expend.
My experience is that most of the "standard protocols" require a great
deal of effort to implement, and are generally hopelessly overblown in
complexity.
The time required to produce your own is probably less, and generally
will lead to a more efficient effective solution.
The downside of course is you lose the ability to use whatever diagnostic
tools and software that already exists for a given standard. Also you
need to consider whatever marketting advantage may be gained by being
able to claim "inter-working" with some standard network.
If you decide to roll-your own protocol here are some things to consider.
1. Master/Slave is easier than Peer-to-Peer. ( I like dictatorships!)
Has the subtle advantage of concentrating error recovery procedures
at the one end of the link.
2. A unique flag sequence is required if you want
your network to be data-transparent.
This can be acheived with a number of different methods.
1. Bit Stuffing (like HDLC)
2. Byte Stuffing.
3. Time slots.
4. Combinations of the above.
3. A mechanism for identifying corrupted packets. (at the Rx end)
1. Simple XOR checksum
2. CRC checksum
3. Hamming Codes (advantage of error correcting)
4. A mechanism for identifying bad transactions ( at the Tx end )
1. An ACK/NAK method. ( Rx end responds with either.)
2. TimeOut method ( Rx end doesn't respond with a time slot)
3. Packet numbering ( Rx end sends sequenced ACK/NAK's)
5. A recovery method for failed transactions.
1. Simple retry.
2. Alarm Handling
3. Defined behaviour for nodes that get disconnected from
the network. If nodes are able to appear and dissapear
from the network you might need some sort of "attach"
"detach" protocol.
Finally, don't forget that for HDX you should allow a turnaround
delay. (can be very short) Also don't flip back to receive after
transmission until tx shifting is complete.
>
>Anybody has information about implementing RS-485 "network" protocol on a
>PIC 16C84 or 16C71?
>
>I'm looking for software capable of handling half-duplex comms (single
>pair of RS-485 cable) between various devices (minimum 64). Speed is not
>important. I have already some ideas but I don't want to reinvent the
>wheel...
>
>Thanks in advance
>
>Eric.
>>[....]It is
>>intended to be a multi-drop system with each slave having a unique node
>>address and only responding when polled.
>Use RS-485 transceivers instead. RS-485 is designed to be
>multidrop.
>Linear Technology has a good range of devices.
I would strongly advise *against* using the Linear Technology
devices. I was unfortunate enough to substitute in an LTC490 for
a SN75179 TI driver. The LT parts would latch up in the field,
crowbarring the power supply and either destroying the board or
at least completely failing.
The Texas Instruments part (SN75179) was robust but power-hungry.
We finally went with the Maxim MAX490, which has the power-reduced
appetite of a CMOS device, without the latchup and failures of the
LT device.
LT maintained that it was our design at fault, not their parts,
even though everybody *else's* part worked just fine in our application.
And even though it was inside a metal cabinet, with only a foot of
wire between the transceiver and the other end. I've been a little
leery of LT ever since.... KILLspamforbesmKILLspampeak.orghttp://www.peak.org/~forbesm
Mark G. Forbes
"Outside of a dog, a book is a man's best friend.
Inside of a dog, it is too dark to read." - Groucho Marx
>I would strongly advise *against* using the Linear Technology
>devices. I was unfortunate enough to substitute in an LTC490 for
>a SN75179 TI driver. The LT parts would latch up in the field,
>crowbarring the power supply and either destroying the board or
>at least completely failing.
>
>LT maintained that it was our design at fault, not their parts,
>even though everybody *else's* part worked just fine in our application.
>And even though it was inside a metal cabinet, with only a foot of
>wire between the transceiver and the other end. I've been a little
>leery of LT ever since....
This divergence of experience happens suprisingly often.
I have used LT parts for many years, including the '490,
with no problems (excepting an unfortunate experience with
a switching capacitor chip).
I am consistently impressed by the quality, performance,
and reliability of LT parts, and recommend them to others
with confidence.
But all of us have experienced a design where supposedly
pin compatible products from different manufacturers gave
different results in the field.
.>I would strongly advise *against* using the Linear Technology
>devices. I was unfortunate enough to substitute in an LTC490 for
>a SN75179 TI driver. The LT parts would latch up in the field,
>crowbarring the power supply and either destroying the board or
>at least completely failing.
>Mark G. Forbes
I work for a company that uses 1000's of LTC485 each year without problem.
It is worth noting, however, that some LTC parts do have latch-up
conditions, but these are generally well documented. If the suggested
precautions are taken, the parts are reliable. A possible reevaluation of
your design will expose your violation of LTC's design rules.
I have been experiencing a similar possible latch-up problem with cheaper
charge-pumped RS232 level converters (such as ICL and AD). Any experiences?
>
> .>I would strongly advise *against* using the Linear Technology
> >devices. I was unfortunate enough to substitute in an LTC490 for
> >a SN75179 TI driver. The LT parts would latch up in the field,
> >crowbarring the power supply and either destroying the board or
> >at least completely failing.
> >Mark G. Forbes
>
> I work for a company that uses 1000's of LTC485 each year without problem.
> It is worth noting, however, that some LTC parts do have latch-up
> conditions, but these are generally well documented. If the suggested
> precautions are taken, the parts are reliable. A possible reevaluation of
> your design will expose your violation of LTC's design rules.
>
> I have been experiencing a similar possible latch-up problem with cheaper
> charge-pumped RS232 level converters (such as ICL and AD). Any experiences?
>
I have been using a Harris ICL232 & a National DS8921 to do
RS-232 to RS-422 conversion. It's been working fine for
weeks now and it's on a solderless breadboard. At around
$5 in parts it's an inexpensive converter.
>I have been experiencing a similar possible latch-up problem with cheaper
>charge-pumped RS232 level converters (such as ICL and AD). Any experiences?
>
Yer, the ICL232 is a dog of a thing and doesn't like to work at 57600 baud.
The standard MAX232 parts gave no problems.
I am working in the construction of a microcontroller module based in PIC
16C84 or Micromint PICStic, with RS-485 (75176) interface driver. Y need a
net RS-485 of several modules.
Could any help me, in the source code of the RS-485 driver for the Net,
in
Microchip assembler or PBASIC compiler ?.
The PC Host work with Visual BASIC Windows 3.0 professional.
Many thank for the help.
Prof, Eugenio Martin Cuenca
Dpto. de Biologia Animal
Facultad de Ciencias
Universidad de Granada
18071 - Granada - Spain
Does anyone have any experience/knowledge on implementing RS-485 using a
PIC16C6X? One of my questions regards the way each node is assigned a
unique address. I have done PIC projects using the CCS PCM "C"
compiler, but have never anything with communication.
Any help or suggestions that the members of this list can provide will
be greatly appreciated.
I'm not that familar with Serial communications. I'm trying to write code
for a pic to communicate RS-485 to other serial devices. I'm confused on
what the BRGH bit in the TXSTA register does. I know that it selects between
high and low speed. But what constitutes high speed 19.2K, 38.4K, etc. what
constitutes low speed 1200 baud, am I just really confused. Could somebody
please help.
Thanks
David Wong
> I'm not that familar with Serial communications. I'm trying to
> write code for a pic to communicate RS-485 to other serial devices.
> I'm confused on what the BRGH bit in the TXSTA register does. I
> know that it selects between high and low speed. But what
> constitutes high speed 19.2K, 38.4K, etc. what constitutes low speed
> 1200 baud, am I just really confused. Could somebody please help.
Avoid it if you can, by using crystals that will let you use BRGH = 0
AND have good bitrate accuracy.
Trolling the list provided the following snippet -
> > The following commonly available crystal frequencies give you 0%
> > error on the common baud rates : 1.8432MHz, 2.4576 MHz, 3.6864 MHz, 4.9152
MHz, 11.0592 MHz
You may get away with BRGH = 1, but MicroChip advises that errors may
occur with most of their chips, the 66,67,76,77 series excepted. I'd
say if you aren't familiar with serial comms, then try and avoid one
more potential problem.
MikeS
<mikesmith_oz@nosp*m.relaymail.net>
(remove the you know what before replying)
Has anyone out there used the 16C74a with an RS-485 2-wire network? If so,
how is it any different than using RS232 (except for levels, of course). Am
I required to use addressing? Would I decode the addressing in software or
hardware?
> Has anyone out there used the 16C74a with an RS-485 2-wire network? If
so,
> how is it any different than using RS232 (except for levels, of course).
Am
> I required to use addressing? Would I decode the addressing in software
or
> hardware?
Generally, 485 nets use addressing, either some type of polling scheme, or
something like slotted aloha. AFAIk, there is no chip that handles
addressing for you, all they are is level converters, and drivers. You can
use a uart to talk over 485, but the start and stop bits are rather
redundant.
485 is a standard for the hardware level. The protocol and data structure
are all up to you.
It only rules about how the electrical signal would exist on the wires,
nothing else, nothing related to addressing or something else.
RS232 is an unbalanced system, it uses Ground and a wire to carry the
signal. Any EMI (Electro Magnetic Interference) that "touch" the signal
wire (or ground) would be incorporated to the signal itself, and can
cause communication problems.
RS485 is a balanced system, there is no ground involved, except for the
cable shielding, but there is two wires for the signal (RS232 uses only
one). Each wire transport a 180¡ rotate signal. It means that if an
EMI touch the wires, it would generate a voltage with the same polarity
on both wires. The RS485 receiver chip simple looks for differential
signals, not signal with the same polarity (0¡), so it is automatically
eliminated, and the valid signal is transfered with much more
reliability than RS232. Again, the signal itself has no relation to
ground, only related to the other wire, inverted signal polarity.
How you would use the RS485 is another story. You can implement several
different protocols, using addressing, multi-drop or something else you
can invent by yourself. All of this can be done either in RS232 or
RS485, doesn't matter so much.
RS485 as you can see, is much more indicated for noisy and connections
with distances bigger than 2 to 3 meters. It requires a two conductors
shielded cable.
>
> Hello fellow bitheads!!!
>
> Has anyone out there used the 16C74a with an RS-485 2-wire network? If so,
> how is it any different than using RS232 (except for levels, of course). Am
> I required to use addressing? Would I decode the addressing in software or
> hardware?
>
> Thanx in advance,
>
> Jay Mielke
>
> spamBeGonejayspamBeGoneticon.net
> Has anyone out there used the 16C74a with an RS-485 2-wire network? If so,
> how is it any different than using RS232 (except for levels, of course).
Am
> I required to use addressing? Would I decode the addressing in software or
> hardware?
>
Most significantly, RS485 is half duplex ... you need to control the Rx/Tx
mode of the buffer chip as well as the actual Rx & Tx signals (ie: three pins
from the PIC).
As to addressing or whatever ... totally dependant on what software protocol
you decide to write; typically you would have a master/slave type where all
devices except one are receiving, unless they receive a request for data from
the one master device.
Hi,
one can use the SN75176 for level conversion. Keep in mind, that RS-485
is simplex, so you MUST handle the DI/DO bits also (fortunately they can
be tied bcus one of them is inverted).
Imre
> > Has anyone out there used the 16C74a with an RS-485 2-wire network? If
> so,
> > how is it any different than using RS232 (except for levels, of course).
> Am
> > I required to use addressing? Would I decode the addressing in software
> or
> > hardware?
>
>
> Generally, 485 nets use addressing, either some type of polling scheme, or
> something like slotted aloha. AFAIk, there is no chip that handles
> addressing for you, all they are is level converters, and drivers. You can
> use a uart to talk over 485, but the start and stop bits are rather
> redundant.
>
> 485 is a standard for the hardware level. The protocol and data structure
> are all up to you.
>
>
At 13:24 13/04/99 -0500, you wrote:
>Has anyone out there used the 16C74a with an RS-485 2-wire network? If so,
>how is it any different than using RS232 (except for levels, of course). Am
>I required to use addressing? Would I decode the addressing in software or
>hardware?
As others have said, 485 is just an electrical spec- how you sort out
sending real data and handling the bus is up to you! I'll give you a brief
description of a system I've just completed, which might be a place to start.
The system is a parallel to serial to parallel converter- we have some
equipment (DSP board) which needs a parallel port connection to a PC, but
the PC is on a boat and the DSP is on the sea bed, about 100m away- no good
for a parallel link...
The PIC reads data from the parallel port and sends it on the USART. The
RS-485 hardware is a MAX-485 chip, with the transmit and receive enable
pins tied together, and connected to a PIC pin, and the transmit and
receive data pins connected to RC7 & RC6. Each data byte is acknowledged
with an acknowledge byte, parity is not implemented for error checking, so
the parity bit is used as a data/status flag.
The driver is TX-enabled just before loading TXREG and RX-enabled once the
data has been sent.
The higher level protocols are already in the DSP, which makes things
easier, and avoids contention.
Hope that helps,
Nigel
--
Nigel Orr Research Associate O ______
Underwater Acoustics Group, o / o \_/(
Dept of Electrical and Electronic Engineering (_ < _ (
University of Newcastle Upon Tyne \______/ \(
I have designed an RS-485 capable device with PIC16F877's and MAX485CPA's. PIC16F877 has a built-in USART. I used CCS C PCM compiler for programming. My intent was to built an RS-485 network with these devices and interface them to a PC. Device is working well except RS-485 side.
The connections between PIC and MAX485 is as follows :
1.RX pin on PIC connects to RO pin on MAX485.
2.TX pin on PIC connects to DI pin on MAX485.
3.RE pin on MAX485 connects to GND.
4.DE pin is driven by an output from PIC.
5.A termination resistor of 220 Ohm is present between A and B pins of MAX485.
For the transmit of data, I am using built-in RS232 function of CCS C Compiler like, printf, putchar, etc.
I don't know what is wrong here. Any ideas are wellcome.
King Regards,
Ali GOKSU
Software Engineer
__________________________________________________________________
Make A Buck Or Two @ TheMail.com - Free Internet Email
Sign-up today at http://www.themail.com/ref.htm?ref=16449
Hi,
I know only SN75176 but I guess it is virtually identical. Here is what I
suspect:
do not tie RE to gnd. As RS-485 is a half-duplex device, this idea is
definitely bad. At that chip I mentioned one of RE and DE is inverted, so
it is a good practice connect them together and so control them. Such way,
the device will either receive, or transmit.
> Hi All,
>
> I have designed an RS-485 capable device with PIC16F877's and MAX485CPA's. PIC16F877 has a built-in USART. I used CCS C PCM compiler for programming. My intent was to built an RS-485 network with these devices and interface them to a PC. Device is working well except RS-485 side.
>
> The connections between PIC and MAX485 is as follows :
>
> 1.RX pin on PIC connects to RO pin on MAX485.
> 2.TX pin on PIC connects to DI pin on MAX485.
> 3.RE pin on MAX485 connects to GND.
> 4.DE pin is driven by an output from PIC.
> 5.A termination resistor of 220 Ohm is present between A and B pins of MAX485.
>
> For the transmit of data, I am using built-in RS232 function of CCS C Compiler like, printf, putchar, etc.
>
> I don't know what is wrong here. Any ideas are wellcome.
>
> King Regards,
>
> Ali GOKSU
> Software Engineer
> __________________________________________________________________
> Make A Buck Or Two @ TheMail.com - Free Internet Email
> Sign-up today at http://www.themail.com/ref.htm?ref=16449
>
>
> -----Original Message-----
> From: Dr. Imre Bartfai [TakeThisOuTrootEraseMEspam_OUTPROF.PMMF.HU]
>
> Hi,
> I know only SN75176 but I guess it is virtually identical.
> Here is what I
> suspect:
>
> do not tie RE to gnd. As RS-485 is a half-duplex device, this idea is
> definitely bad.
Not bad. It just means that you receive everything that you transmit.
You can either ignore this, or use it as a bus integrity check.
> At that chip I mentioned one of RE and DE is
> inverted, so
> it is a good practice connect them together and so control
> them. Such way,
> the device will either receive, or transmit.
>
>
> On Tue, 14 Dec 1999, Ali GOKSU wrote:
>
> > Hi All,
> >
> > I have designed an RS-485 capable device with PIC16F877's
> and MAX485CPA's. PIC16F877 has a built-in USART. I used CCS C
> PCM compiler for programming. My intent was to built an
> RS-485 network with these devices and interface them to a PC.
> Device is working well except RS-485 side.
> >
> > The connections between PIC and MAX485 is as follows :
> >
> > 1.RX pin on PIC connects to RO pin on MAX485.
> > 2.TX pin on PIC connects to DI pin on MAX485.
> > 3.RE pin on MAX485 connects to GND.
> > 4.DE pin is driven by an output from PIC.
> > 5.A termination resistor of 220 Ohm is present between A
> and B pins of MAX485.
> >
> > For the transmit of data, I am using built-in RS232
> function of CCS C Compiler like, printf, putchar, etc.
> >
> > I don't know what is wrong here. Any ideas are wellcome.
So does the "built-in RS232 functions of the CCS C Compiler" enable the
driver before transmit? I suspect not.
You need to turn on the driver, transmit all of your bits, and then turn
off the driver (to receive). This is more housework than the "typical"
RS232 routines do.
> > For the transmit of data, I am using built-in RS232
> function of CCS C Compiler like, printf, putchar, etc.
> >
> > I don't know what is wrong here. Any ideas are wellcome.
>So does the "built-in RS232 functions of the CCS C Compiler" enable the
>driver before transmit? I suspect not.
>You need to turn on the driver, transmit all of your bits, and then turn
>off the driver (to receive). This is more housework than the "typical"
>RS232 routines do.
The #USE RS232 directive in CCS C allows you to define a pin as an enable
output for use with RS-485.
An example would be:
#use rs232(baud=9600, xmit=PIN_B1, rcv=PIN_B2, enable=PIN_B3)
where PIN_B3 is set high during transmit.
I have not personally used the function, so I cannot verify that it actually
works as expected.
> >So does the "built-in RS232 functions of the CCS C Compiler"
> enable the
> >driver before transmit? I suspect not.
>
> >You need to turn on the driver, transmit all of your bits,
> and then turn
> >off the driver (to receive). This is more housework than the
> "typical"
> >RS232 routines do.
>
> The #USE RS232 directive in CCS C allows you to define a pin
> as an enable
> output for use with RS-485.
> An example would be:
> #use rs232(baud=9600, xmit=PIN_B1, rcv=PIN_B2, enable=PIN_B3)
> where PIN_B3 is set high during transmit.
> I have not personally used the function, so I cannot verify
> that it actually
> works as expected.
Formal: I stand corrected. Thank you for your information.
Informal: Coooool! This shows that someone at CCS has real-world
experience! ;-)
Also, in the pic there is a register that has a receive overflow bit.
You should have a routine to check this bit, if it is set, do to an
overflow(I think it's set) you'll need to read your rx register twice to
empty it and the clear the overflow bit. Your termination resistor
should be aprox 110 ohm at both ends of the cable. Also I think it would
be wise to put in 2 resistors for critical biasing (a aprox 600 ohm
between pin 5 and 7 and another between 6 and 8 of the max chip), alot
of people have said to me that they have had it working fine without
them but I am yet to be able to get my setup to work faultlessly without
them.
Regards
Stuart O'Reilly
>
> Hi,
> I know only SN75176 but I guess it is virtually identical. Here is what I
> suspect:
>
> do not tie RE to gnd. As RS-485 is a half-duplex device, this idea is
> definitely bad. At that chip I mentioned one of RE and DE is inverted, so
> it is a good practice connect them together and so control them. Such way,
> the device will either receive, or transmit.
>
> I hope this helps.
>
> Imre
>
> On Tue, 14 Dec 1999, Ali GOKSU wrote:
>
> > Hi All,
> >
> > I have designed an RS-485 capable device with PIC16F877's and MAX485CPA's. PIC16F877 has a built-in USART. I used CCS C PCM compiler for programming. My intent was to built an RS-485 network with these devices and interface them to a PC. Device is working well except RS-485 side.
> >
> > The connections between PIC and MAX485 is as follows :
> >
> > 1.RX pin on PIC connects to RO pin on MAX485.
> > 2.TX pin on PIC connects to DI pin on MAX485.
> > 3.RE pin on MAX485 connects to GND.
> > 4.DE pin is driven by an output from PIC.
> > 5.A termination resistor of 220 Ohm is present between A and B pins of MAX485.
> >
> > For the transmit of data, I am using built-in RS232 function of CCS C Compiler like, printf, putchar, etc.
> >
> > I don't know what is wrong here. Any ideas are wellcome.
> >
> > King Regards,
> >
> > Ali GOKSU
> > Software Engineer
> > __________________________________________________________________
> > Make A Buck Or Two @ TheMail.com - Free Internet Email
> > Sign-up today at http://www.themail.com/ref.htm?ref=16449
> >
> >
goliat.ugr.es
