Greetings,
I'm in the middle of trying to make some code to do RS232 reception
and have a question. My idea is to have an interrupt on the start
bit, then load the timer with some value and wait for it to time out
and generate another interrupt at which time I can check the data
line again to get the bit in. Then reset the timer with another
value.. etc... Is it possible to have one interrupt more or less
inside another interrupt? If so is there anything special that needs
to be done?
Thanks for your time!
James
I don't think you can do this on a PIC because there is only one
interrupt vector. You could do this on a Motorola (for example), but
even then, I wouldn't recomend it. Getting interrupted from an interrupt
can cause all kinds of problems (stack, endless loops, memory
corruption, etc). Recursive interrupt functions are a nightmare.
Having said that, in your application, maybe you could start the
interrupt the way you suggest, then load your timer, and poll the timer
status flag to see if it has expired.
Brad Stevenson, CET
The DPL Group - Telecom Techniques
506-635-1055 or 1-800-561-8880 http://www.dpl.ca
James & Ili wrote:
> My idea is to have an interrupt on the start
> bit, then load the timer with some value and wait for it to time out
> and generate another interrupt at which time I can check the data
> line again to get the bit in. Then reset the timer with another
> value.. etc... Is it possible to have one interrupt more or less
> inside another interrupt? If so is there anything special that needs
> to be done?
Strange... I am taking the same approach for the same problem...
I don't think that you have to worry about an interrupt inside an
interrupt.
Just try to do this:
1. set the interrupt on the start bit and wait (do your main task)
2. when you receive the interrupt on pin change disable it, set the
timer interrupt to expire in the middle of the first bit and return to
your main
3. when the timer expire, sample the bit value, set the timer interrupt
for the next bit and, again, return from interrupt
4. repeat step 3 for each bit you expect
5. goto step 1
As you can see you don't have an int in a int but just a sequence of
interrupt one after the other.
Good luck
Marco
----
Marco DI LEO email: spam_OUTm.dileoTakeThisOuTsistinf.it
Sistemi Informativi S.p.A. tel: +39 6 50292 300
V. Elio Vittorini, 129 fax: +39 6 5015991
I-00144 Roma
Italy
> Greetings,
> I'm in the middle of trying to make some code to do RS232 reception
> and have a question. My idea is to have an interrupt on the start
> bit, then load the timer with some value and wait for it to time out
> and generate another interrupt at which time I can check the data
> line again to get the bit in. Then reset the timer with another
> value.. etc... Is it possible to have one interrupt more or less
> inside another interrupt? If so is there anything special that needs
> to be done?
> Thanks for your time!
> James
>
The normal way to do interrupt driven RS232 reception is to have a
periodical interrupt running at 2 or 3 times the baud rate. The
interrupt samples the RX line and as soon as the start bit is
detected the interrupt changes the period to 1.25 resp. 4/3 of the
baud period. The interrupt can now sample the first databit and
change the period to the baud rate, and sample the rest of the
databits. After the last databit is sampled, change back to 2 or 3
times the baud rate and wait for the next databit.
In a message dated 98-03-12 13:18:02 EST, you write:
You certainly can do this on a PIC! At the start of the interupt routine you
simply check the INTCON reg to see what generated the interupt and jump
accordingly.
Then Motorolla parts have different kinds of interupts, thus the different
vectors. One vector for an IRQ and another for the NMI another for SWI etc.
It still won't tell you what device generated the interupt, You have to resort
to polling the devices inside the interupt routine.
Dave Duley
<<
I don't think you can do this on a PIC because there is only one
interrupt vector. You could do this on a Motorola (for example), but
even then, I wouldn't recomend it. Getting interrupted from an interrupt
can cause all kinds of problems (stack, endless loops, memory
corruption, etc). Recursive interrupt functions are a nightmare.
Having said that, in your application, maybe you could start the
interrupt the way you suggest, then load your timer, and poll the timer
status flag to see if it has expired.
Brad Stevenson, CET
The DPL Group - Telecom Techniques
506-635-1055 or 1-800-561-8880 http://www.dpl.ca >>
> In a message dated 98-03-12 13:18:02 EST, you write:
>
> You certainly can do this on a PIC! At the start of the interupt
> routine you
> simply check the INTCON reg to see what generated the interupt and
> jump
> accordingly.
> Well, you have to do this, regardless of whether it's in interrupt
> inside an interrupt or not. What I was trying to say was that it is
> this very fact that makes it hard to handle recursive interrupts on a
> pic. Example: Your in an isr routine, you get interrupted, and you
> vector to the same physical spot in the code you were already at. That
> can get snakey with a limited stack if your not careful. You may be
> able to do this on a pic be re-enabling the global interrupt bit. In
> my opinion theres always a better programming solution than doing
> recursive interrupts.
>
> Then Motorolla parts have different kinds of interupts, thus the
> different
> vectors. One vector for an IRQ and another for the NMI another for
> SWI etc.
> It still won't tell you what device generated the interupt, You have
> to resort
> to polling the devices inside the interupt routine.
> The very fact that you vectored to a certain location (in a Motorola
> device) tells you what generated the interrupt.
>
> Dave Duley
>
>
> Brad Stevenson, CET
> The DPL Group - Telecom Techniques
> 506-635-1055 or 1-800-561-8880
> http://www.dpl.ca
>
> From: DREITEK <.....DREITEKKILLspam@spam@AOL.COM>
> In a message dated 98-03-12 13:18:02 EST, you write:
>
> You certainly can do this on a PIC! At the start of the interupt routine you
> simply check the INTCON reg to see what generated the interupt and jump
> accordingly.
>
> Then Motorolla parts have different kinds of interupts, thus the different
> vectors. One vector for an IRQ and another for the NMI another for SWI etc.
> It still won't tell you what device generated the interupt, You have to resort
> to polling the devices inside the interupt routine.
>
> Dave Duley
>
The difference between Motorola (at least the 68000-series) and PIC
is that a Motorola processor has different priorities on the
interrupts. One interrupt can interrupt another so to speak. On a PIC
only one interrupt at a time is allowed to execute. If an interrupt
is triggered when the PIC is already in the interrupt service routine
the PIC waits for the retfie instruction before this interrupt is
processed. There is a way around this of you enable the global
interrupt bit at the beginning of the ISR, but this leads to code
that is very hard to debug and there can be effects which are hard to
predict.
On Thu, 12 Mar 1998 13:47:06 -0400 "Stevenson, Brad" <STEVENSBKILLspamDPL.CA>
writes:
>I don't think you can do this on a PIC because there is only one
>interrupt vector. You could do this on a Motorola (for example), but
>even then, I wouldn't recomend it. Getting interrupted from an
>interrupt
>can cause all kinds of problems (stack, endless loops, memory
>corruption, etc). Recursive interrupt functions are a nightmare.
I agree that interrupts interrupting interrupts should be
discouraged. I don't think there's a problem with the single vector
though. When an interrupt is generated, you just poll the various
devices that are capable of generating the interrupt, then go deal with
it. The multiple vector interrupt mechanisms just save you from having
to do the polling. I recall a trick of using a binary encoder that is
"dropped on the bus" when the interrupt vector address is called on
single interrupt processors. The encoder then provided a number that the
processor "thought" was the interrupt vector, so it jumped to it. At
that address was a JMP instruction to the ISR.
Seems to me that the real problem with nested interrupts on the
PIC is lack of stack space for return adddresses and the lack of stack
access for data. You have to save registers when the interrupt is called
(if the interrupt uses those registers). With the PIC, these are
typically stored in fixed RAM locations. A second interrupt would
overwrite the first entries, messing up the return from the first
interrupt.
My early programming was on the 6800 or 6802 (in fact, I spent
the morning modifying 6802 code to deal with year 2000). It had two
interrupts: IRQ and NMI. Both pushed all registers on the stack. It was
interesting to me when the 6809 came out. It had a "fast IRQ" that, as I
recall, pushed only the flags and the return address. It was up to the
user to push anything else on the stack. Always seemed to me that the
number of cycles necessary to get the push instruction and actually do
the push for even a couple registers would be more than just
automatically pushing them all. Never ended up doing any 6809 stuff
though.
So... yes, you can do nested interrupts on the PIC by enabling
the GIE flag inside the ISR. But... it's gonna be rough!
Harold
_____________________________________________________________________
You don't need to buy Internet access to use free Internet e-mail.
Get completely free e-mail from Juno at http://www.juno.com
Or call Juno at (800) 654-JUNO [654-5866]
Danjel,
This sounds like a great solution.
If I understand you, then you would use the timer to generate the
interrupt
and just change the value that's loaded in the timer depending on the
mode you're in
i.e. at 9600 baud
Wait for start bit mode. clear timer ( set to 256 counts)
check pin when timer overflows and triggers interrupt
Sample signal mode. set timer to 152
check pin when timer overflows
I will try to implement it now.
Thanks a bunch !!!
P.S. Is there anything I need to do when I put a value into the
timer? I know I need to
clear the interrupt flag before exiting the ISR.
> > and generate another interrupt at which time I can check the data
> > line again to get the bit in. Then reset the timer with another
> > value.. etc... Is it possible to have one interrupt more or less
> > inside another interrupt? If so is there anything special that
> > needs
> > to be done?
> > Thanks for your time!
> > James
> >
>
> The normal way to do interrupt driven RS232 reception is to have a
> periodical interrupt running at 2 or 3 times the baud rate. The
> interrupt samples the RX line and as soon as the start bit is
> detected the interrupt changes the period to 1.25 resp. 4/3 of the
> baud period. The interrupt can now sample the first databit and
> change the period to the baud rate, and sample the rest of the
> databits. After the last databit is sampled, change back to 2 or 3
> times the baud rate and wait for the next databit.
>
> Regards,
> Danjel McGougan.
> James & Ili wrote:
> > My idea is to have an interrupt on the start
> > bit, then load the timer with some value and wait for it to time
> > out
> > and generate another interrupt at which time I can check the data
> > line again to get the bit in. Then reset the timer with another
> > value.. etc... Is it possible to have one interrupt more or less
> > inside another interrupt? If so is there anything special that
> > needs
> > to be done?
>
> Strange... I am taking the same approach for the same problem...
> I don't think that you have to worry about an interrupt inside an
> interrupt.
> Just try to do this:
> 1. set the interrupt on the start bit and wait (do your main task)
> 2. when you receive the interrupt on pin change disable it, set the
> timer interrupt to expire in the middle of the first bit and return
> to
> your main
> 3. when the timer expire, sample the bit value, set the timer
> interrupt
> for the next bit and, again, return from interrupt
> 4. repeat step 3 for each bit you expect
> 5. goto step 1
>
> As you can see you don't have an int in a int but just a sequence
> of
> interrupt one after the other.
>
> Good luck
> Marco
>
> ----
> Marco DI LEO email: m.dileospam_OUTsistinf.it
> Sistemi Informativi S.p.A. tel: +39 6 50292 300
> V. Elio Vittorini, 129 fax: +39 6 5015991
> I-00144 Roma
> Italy
An interrupt simply clears INTCON,GIE. If you code in PIC assembler, you
could try setting the bit inside the interrupt. Then another interrupt
could be generated, but it would just go back to your interrupt vector.
Setting a flag to keep track of "interrupt depth" and branching to
appropriate interrupt routine might theoretically work, but I think it
would be poor practice. I like Marco's general idea better.
> James
>
> On Thursday, March 12, 1998 11:52 AM, Marco DI LEO
> [SMTP:RemoveMEm.dileoTakeThisOuTSISTINF.IT] wrote:
> > James & Ili wrote:
> > > My idea is to have an interrupt on the start
> > > bit, then load the timer with some value and wait for it to time
> > > out
> > > and generate another interrupt at which time I can check the data
> > > line again to get the bit in. Then reset the timer with another
> > > value.. etc... Is it possible to have one interrupt more or less
> > > inside another interrupt? If so is there anything special that
> > > needs
> > > to be done?
> >
> > Strange... I am taking the same approach for the same problem...
> > I don't think that you have to worry about an interrupt inside an
> > interrupt.
> > Just try to do this:
> > 1. set the interrupt on the start bit and wait (do your main task)
> > 2. when you receive the interrupt on pin change disable it, set the
> > timer interrupt to expire in the middle of the first bit and return
> > to
> > your main
> > 3. when the timer expire, sample the bit value, set the timer
> > interrupt
> > for the next bit and, again, return from interrupt
> > 4. repeat step 3 for each bit you expect
> > 5. goto step 1
> >
> > As you can see you don't have an int in a int but just a sequence
> > of
> > interrupt one after the other.
> >
> > Good luck
> > Marco
> >
> > ----
> > Marco DI LEO email: spamBeGonem.dileospamBeGonesistinf.it
> > Sistemi Informativi S.p.A. tel: +39 6 50292 300
> > V. Elio Vittorini, 129 fax: +39 6 5015991
> > I-00144 Roma
> > Italy
In a message dated 98-03-12 17:01:32 EST, you write:
<<
The difference between Motorola (at least the 68000-series) and PIC
is that a Motorola processor has different priorities on the
interrupts. One interrupt can interrupt another so to speak. On a PIC
only one interrupt at a time is allowed to execute. If an interrupt
is triggered when the PIC is already in the interrupt service routine
the PIC waits for the retfie instruction before this interrupt is
processed. There is a way around this of you enable the global
interrupt bit at the beginning of the ISR, but this leads to code
that is very hard to debug and there can be effects which are hard to
predict.
Danjel McGougan >>
Perhaps so, but the question was weather it could be done, not if it should be
done!!
On Thu, 12 Mar 1998 17:24:33 -0600 James & Ili <TakeThisOuTjandiEraseMEspam_OUTMPSI.NET> writes:
>Danjel,
> This sounds like a great solution.
> If I understand you, then you would use the timer to generate
>the
>interrupt
>and just change the value that's loaded in the timer depending on the
>mode you're in
>i.e. at 9600 baud
>Wait for start bit mode. clear timer ( set to 256 counts)
>check pin when timer overflows and triggers interrupt
>
>Sample signal mode. set timer to 152
>check pin when timer overflows
>I will try to implement it now.
>
> Thanks a bunch !!!
>P.S. Is there anything I need to do when I put a value into the
>timer?
Remember the timer counts *up*, so the value you write should be 256-N
where N is the number of counts you want before the next interrupt. You
need to be sure the TOIF flag is clear after writing the timer and before
enabling the timer interrupt. Also, writing the timer stops it for 2 PIC
instruction cycles and resets the prescaler (if enabled). For
consistent, exact timing, always write the timer at the same point in
(same number of cycles into) the ISR.
Putting a debug feature into your ISR that pulses a pin right after a
sample of the data line is taken can be very helpful. Observed on a dual
trace scope, the sample pulses should occur very near the center of the
incoming data bits.
_____________________________________________________________________
You don't need to buy Internet access to use free Internet e-mail.
Get completely free e-mail from Juno at http://www.juno.com
Or call Juno at (800) 654-JUNO [654-5866]
James & Ili wrote:
>
> Marco,
> Did you read the post by Danjel ? It looks like a simpler way to go.
> James
It appear to be the same approach except for the start bit detection.
The Danjel method detect the start bit "[using] a periodical interrupt
running at 2 or 3 times the baud rate" in witch you "samples the RX
line".
I just try to detect the start bit using an interrupt on the start bit
edge.
The rest of both methods is essentially the same.
There are pros and cons in both approaches:
Danjel method pros: you can use any pin as RX line because you sample it
using a bit test instruction. cons: if there is no traffic on the line
you still have 3 int per bit time interrupting you main task.
My method pros: your main task is only interrupted when a transmission
occur. If transmission are rare you can save lot of compute power. cons:
you have to use specific pin for the RX line. On the 16C84 you can
choose between the RB0/INT and RA4/T0CK1. Use the latter setting the
counter to external clock, no prescaler and preload it to 0xFF. At the
the first edge the counter roll to 0x00 thus generating an int. The
RB0/INT method is easier but the RA4/T0CK1 saves you an interrupt source
because you only use the timer/counter for bit timing/start bit
detection, having the RB0/INT free for other purposes.
The choice of the method used to detect the start bit depends completely
on your application and on the timing of your main task.
Marco
----
Marco DI LEO email: RemoveMEm.dileoTakeThisOuTsistinf.it
Sistemi Informativi S.p.A. tel: +39 6 50292 300
V. Elio Vittorini, 129 fax: +39 6 5015991
I-00144 Roma
Italy
Marco,
I can see the advantages of your method, that was my original idea.
Use interrupts to detect incoming pulse then switch to timer overflow
interrupts to sample data stream. My problem is I would be tied to a
special pin and the configuration that I am using won't allow that.
So I used Danjel's method. I wrapped it up last night about midnight.
Good news is it works great, bad news is it takes up lots of
processor cycles. Fortunately in this application I have plenty to
spare. The PIC is only taking data in, and sending it to a DAC via
I2C protocol. I think it would be pretty easy to modify the code to
work either way.
James
> There are pros and cons in both approaches:
> Danjel method pros: you can use any pin as RX line because you
> sample it
> using a bit test instruction. cons: if there is no traffic on the
> line
> you still have 3 int per bit time interrupting you main task.
> My method pros: your main task is only interrupted when a
> transmission
> occur. If transmission are rare you can save lot of compute power.
> cons:
> you have to use specific pin for the RX line. On the 16C84 you can
> choose between the RB0/INT and RA4/T0CK1. Use the latter setting
> the
> counter to external clock, no prescaler and preload it to 0xFF. At
> the
> the first edge the counter roll to 0x00 thus generating an int. The
> RB0/INT method is easier but the RA4/T0CK1 saves you an interrupt
> source
> because you only use the timer/counter for bit timing/start bit
> detection, having the RB0/INT free for other purposes.
>
> The choice of the method used to detect the start bit depends
> completely
> on your application and on the timing of your main task.
At 11:39 AM 3/12/98 -0600, you wrote:
>Greetings,
> I'm in the middle of trying to make some code to do RS232 reception
>and have a question. My idea is to have an interrupt on the start
>bit, then load the timer with some value and wait for it to time out
>and generate another interrupt at which time I can check the data
>line again to get the bit in. Then reset the timer with another
>value.. etc... Is it possible to have one interrupt more or less
>inside another interrupt? If so is there anything special that needs
>to be done?
> Thanks for your time!
>James
>
>
James:
Do yourself a favor: use interupts only as a last resort. They can be real
tricky sometimes.
> The normal way to do interrupt driven RS232 reception is to have a
> periodical interrupt running at 2 or 3 times the baud rate.
> The interrupt samples the RX line and as soon as the start bit is
> detected the interrupt changes the period to 1.25 or 4/3 respectively,
> of the baud period.
Not quite right! For 3X sampling, it stays at three times, for 2X it
changes to four times the bit-rate until it has verified the *start*
bit, then swaps to the actual bit-rate for the data bits *and stop*.
This sets the sample time within the middle third (or half) of each
data bit, and suppresses false starts. Note that when a false start is
found, or a stop is received, it is ready to sample again 1/3 or ¸ bit
time later, so a false start will not cause a true start to be missed,
and a too-high bit-rate causing short stop bits can be tolerated.
If you were really picky, you could use an interrupt-on-change to
detect the start bit, and use timer interrupts thereafter. This is
obviously what James originally intended, but there is absolutely no
requirement for nested interrupts here.
The timer is pre-loaded and its IRQ is cleared so that it *cannot*
interrupt again for a pre-set interval, much more than enough to ensure
that the current interrupt service completes. Next, the timer IRQ is
enabled; superfluous if the current interrupt is a time-out of course,
and then the IRQ routine exits.
When however the stop bit has been checked, the timer IRQ can be
disabled in favour of the interrupt-on-change. If the latter trips
immediately (during the current interrupt service), then its interrupt
will follow the interrupt return. Due care has to be taken as has been
discussed before, with interrupt-on-change functions, so perhaps I
should have spoken about the RB0/INT pin instead.
The reason for using an interrupt to detect the initial start bit is
simply efficiency; no data = no interrupts at all. OTOH, a continuous
3X bitrate interrupt polling the port for start bits is simpler to code,
and suits continuous *or multiple* data streams.
If the latter, there is in fact no alteration of the timer increment
for which a suitable crystal is usually chosen. Data (and stop) bits
are read each three interrupts using a counter, but alternate data
streams may be sampled on different interrupts. Note previous
references in the PICLIST to "vertical counters" for this purpose; four
or eight ports may be serviced very efficiently.
DREITEK wrote:
>
> In a message dated 98-03-13 18:42:55 EST, you write:
>
> <<
> James:
>
> Do yourself a favor: use interupts only as a last resort. They can be real
> tricky sometimes.
>
> >>
> Hello!
> I would disagree with this statement. If used properly interupts can simplify
> code remarkably.
It really depends on how you view things, I too like using interrupts. I
had
considered polling a pain. But I've learned when they're useful and when
they're
a pain. The RS232 example is a border line case, but I think that if the
interrupts come too fast for interrupt driven code, what chance do they
have
with polled code? There is a place for each.
BTW I live in an interrupt driven world and ... excuse me a minute...
At 08:43 AM 3/14/98 -0500, you wrote:
>DREITEK wrote:
>>
>> In a message dated 98-03-13 18:42:55 EST, you write:
>>
>> <<
>> James:
>>
>> Do yourself a favor: use interupts only as a last resort. They can be real
>> tricky sometimes.
>>
>> >>
>
>> Hello!
>> I would disagree with this statement. If used properly interupts can
simplify {Quote hidden}
>> code remarkably.
>
>It really depends on how you view things, I too like using interrupts. I
>had
>considered polling a pain. But I've learned when they're useful and when
>they're
>a pain. The RS232 example is a border line case, but I think that if the
>interrupts come too fast for interrupt driven code, what chance do they
>have
>with polled code? There is a place for each.
>
>BTW I live in an interrupt driven world and ... excuse me a minute...
>
>;-}
>
>--
>Neil Cherry http://home.att.net/~ncherryRemoveMEncherryEraseMEEraseMEworldnet.att.net
>
>
I would like to make a small wager. I bet that James and Ilis' first
"working" iteration will not involve interupts. It won't be "simple" code,
or "compact" code. But it will "work".
Any takers?
John
At 18:47 1998-03-13 EST, you wrote:
>In a message dated 98-03-13 18:42:55 EST, you write:
>
><<
> James:
>
> Do yourself a favor: use interupts only as a last resort. They can be real
> tricky sometimes.
>
> >>
>Hello!
>I would disagree with this statement. If used properly interupts can
simplify
>code remarkably.
>
>Dave Duley
>
Right: *base* your programs on interrupts to make life easier.
/Morgan
/ Morgan Olsson, MORGANS REGLERTEKNIK, SE-277 35 KIVIK, Sweden \
\ RemoveMEmrtspam_OUTKILLspaminame.com, ph: +46 (0)414 70741; fax +46 (0)414 70331 /
Microchip Application Note AN555 gives the code and a detailed account of
interfacing RS232 to a 16CXX chip using the RA4/T0CKI method suggested
below; ie preload 0xFF to detect start, check in initial interrrupt that
start was not noise, then reprogram the timer to interrupt at half or
quarter bit times to decode the byte.
> James & Ili wrote:
> >
> > Marco,
> > Did you read the post by Danjel ? It looks like a simpler way to go.
> > James
>
> It appear to be the same approach except for the start bit detection.
>
> The Danjel method detect the start bit "[using] a periodical interrupt
> running at 2 or 3 times the baud rate" in witch you "samples the RX
> line".
> I just try to detect the start bit using an interrupt on the start bit
> edge.
> The rest of both methods is essentially the same.
>
> There are pros and cons in both approaches:
> Danjel method pros: you can use any pin as RX line because you sample it
> using a bit test instruction. cons: if there is no traffic on the line
> you still have 3 int per bit time interrupting you main task.
> My method pros: your main task is only interrupted when a transmission
> occur. If transmission are rare you can save lot of compute power. cons:
> you have to use specific pin for the RX line. On the 16C84 you can
> choose between the RB0/INT and RA4/T0CK1. Use the latter setting the
> counter to external clock, no prescaler and preload it to 0xFF. At the
> the first edge the counter roll to 0x00 thus generating an int. The
> RB0/INT method is easier but the RA4/T0CK1 saves you an interrupt source
> because you only use the timer/counter for bit timing/start bit
> detection, having the RB0/INT free for other purposes.
>
> The choice of the method used to detect the start bit depends completely
> on your application and on the timing of your main task.
>
> Marco
>
> ----
> Marco DI LEO email: RemoveMEm.dileoTakeThisOuTspamsistinf.it
> Sistemi Informativi S.p.A. tel: +39 6 50292 300
> V. Elio Vittorini, 129 fax: +39 6 5015991
> I-00144 Roma
> Italy
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Ron Kreymborg Computer Systems Manager
Monash University CRC for Southern Hemisphere Meteorology
Wellington Road
Clayton, VIC 3168 Phone : 061-3-9905-9671
Australia Fax : 061-3-9905-9689
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
sistinf.it
