Accelerometer | ADC | ADXL | Adxl20 | AVR | BasicStamp | BX-35 | BX28 | BX35 | COM3 | Compiler | Downloader | EEPROM | Electromagnet | GetADC | GP2D1 | GPS | I2C | IDE | Keypad | LCD | LCD+ | MIDI | Motors | Multitasking | Netmedia | Networking | PCB | PID | PlaySound | PWM | Relays | RTC | Servo | ShiftOut | SitePlayer | SPI | Stack | Timer | USB

So I was thinking about the battery powered clock thing but I had
another idea.

I cracked this up in Java today and it is very simple. String formattedDate = new
SimpleDateFormat("dd-MM-yy-hh-mm-ss").format(new Date());

This one liner will format the date very sweetly. It is then just a
case of making the appropriate calls under bx to set the clock and
periodically syncronize with the local system time using the above
code. If you have a time server installed your time will be very
faithful too.





(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

--- In basicx@basi..., "c04203420" <c04203420@y...> wrote:
>
> So I was thinking about the battery powered clock thing but I had
> another idea.
>
> I cracked this up in Java today and it is very simple. As long as you can live with the "Potential System Resource
Conflict" as listed on Page 28 of the Operating System Reference, it
should be fine.

It seems to me that the RS-232 ports interrupt the clock's tick and may
cause a bit of a slow down. If you can live with that, it is fine




(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

--- In basicx@basi..., "G. Kramer Herzog" <hwanghetw@y...>
wrote:
> It seems to me that the RS-232 ports interrupt the clock's tick
> and may cause a bit of a slow down.

I'm not sure I understand exactly what you're saying. It is true
that serial I/O (on either Com1 or Com3) will consume CPU cycles
and, thus, will slow down the execution of your program. However,
serial I/O does not interfere with RTC accuracy.

There are System Library routines whose use can interfere with RTC
accuracy if the duration of the operation is too long. I believe
that that is what the table to which you referred is intended to
indicate.

Don




(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

> I'm not sure I understand exactly what you're saying.

Maybe you can eventually explain it better to me as you have more
confidence in using the internal RTC with a COM port. I opted for
the additional outboard clock rather than to try to fully understand
the BX-24 RTC integration within the system. I came to belive that
all time-domain functions may conflict with one timer. [there are 3
timers in the microcontroller though]

The BX-24 has its own hardware USART, so I guess that the main com
port COM1 could be okay and autonomous, but I suspect that the others
might share the same timer [apparently TIMER0]. I really cannot be
sure, because this is far beyond the documentation provided by
NetMedia. {There is a tendency for NetMedia documents to issue
warnings [which are helpful], but not to eventually follow up with
the reason behind the warning [which leaves me on my own to find a
satisfactory answer}.

> It is true
> that serial I/O (on either Com1 or Com3) will consume CPU cycles
> and, thus, will slow down the execution of your program. However,
> serial I/O does not interfere with RTC accuracy.
>
I believe it is not about 'consuming CPU cycles' as much as
interfering with the timer's interupt at rollover. This may happen
when an incoming or outgoing message comes at the wrong time - like
just before roll-over.

> There are System Library routines whose use can interfere with RTC
> accuracy if the duration of the operation is too long. I believe
> that that is what the table to which you referred is intended to
> indicate.

Please note that I am not now merely looking at the Table on the
bottom of Page 28 [which refers to conflicts within the same task].
On a second reading, the text above the table appears to be a
separate and more genralize warning, independent of what the table
discusses. Page 29 continues to discuss two or more tasks as being
unpredictable.

As Tom Becker pointed out, there indeed has been a lot of discussion
on the RTC in the past. I have tried to read that, the hardware
documentation and several other sites, but I cannot get to a
conclusive, precise explaination.

The Amtel hardware design intended to have a second clock crystal
attached to the microprocessor and use TIMER2 as a dedicated timer
for the RTC as an independent function, but that seems to not be the
way the BX-24 was built.





(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

--- In basicx@basi..., "G. Kramer Herzog" <hwanghetw@y...>
wrote:
> Maybe you can eventually explain it better to me ...

The BX-24 RTC is implemented using Timer0. The timer is programmed
to generate an interrupt at 2KHz. This is the tick rate, equivalent
to a tick interval of 1.9531 milliseconds. Every time the CPU
receives the Timer0 interrupt, it increments the value at
Register.RTCTick. If that value exceeds 44,236,799 (the number of
seconds in a day), it rolls the value over to zero and increments
the value at Register.RTCDay. That's all there really is to the RTC.

Now, what can go wrong? Well, the RTC will lose time if interrupts
are disabled for more than slightly less than two tick intervals. I
say "slightly less than" because the AVR hardware will queue up
interrupts that occur when interrupts are disabled and then respond
to them once interrupts are re-enabled. So if interrupts are
disabled just after one tick but re-enabled, say, one and a half
tick times later the CPU will get the Timer0 interrupt (albeit late)
and then get another one a half tick time later. However, if two or
more tick periods elapse while interrupts are disabled, the CPU will
respond when interrupts are re-enabled but it will have missed all
but one of the ticks and the RTC values will be inaccurate.

Other resources that will be affected if interrupts are disabled
include Com1 and Com3 with the latter being more "sensitive" than
the former. Since Com1 is the hardware UART it is affected less by
interrupts being disabled because once it begins to transmit or
receive a character it will complete that character even if
interrupts are disabled. As long as interrupts remain disabled,
however, it won't begin to transmit the next available character.
Moreover, it may or may not be able to begin receiving another
character depending on the hardware design. Some UARTs have a
buffer to hold one received character and another register for the
character currently being received. In any case, if interrupts are
disabled long enough, and the sender continues sending, you will
eventually miss one or more transmitted characters. Moreover, the
UART may get "out of sync" with the transmitted data stream - it
depends on the design of the UART.

For Com3, since it is an interrupt-driven software UART, interrupts
cannot be disable for longer than about 1/3 to 1/2 of a bit time
without causing transmit or receive problems. Of course, if no
characters are in the process of being sent or received then there
will be no ill effect of having interrupts disabled for long periods
of time. Note that just because the Com3 output queue is empty
doesn't mean that transmission of the last character has been
completed. There may be a status bit in the queue data structure
that indicates that a transmission is in progress - it would be good
if there were. Similarly, it is difficult to know whether or not a
character is in the process of being received. I belive that Com3
uses Timer2 to generate the timing interrupts for the software
UART. Any other attempted use of Timer2 will conflict with use of
Com3.

The next question, then, is what might cause interrupts to be
disabled for "long" periods? The answer is in the descriptions of
the various functions but it also appears on page 28 of the
Operating System Reference Manual. My understanding of this is that
the Pin I/O Group, DACPin/PutDAC, InputCapture and OutputCapture all
disable interrupts for some period of time. As such, using them may
interfere with the operation of the RTC, Com1 and Com3. Also, all
of the routines in these groups conflict with each other because
they all ostensibly need to use Timer1. As far as I can surmise
there are no other conflicts (ignoring Network calls for the BX-01).

Don



(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )