Subject:
|
Re: I2C device for the RCX
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Mon, 13 Jan 2003 20:52:13 GMT
|
Reply-To:
|
Dick Swan <{dickswa@sbcglobal.}saynotospam{net}>
|
Viewed:
|
1089 times
|
| |
|
|
"Bastiaan v.Kesteren" <b.van.kesteren53@zonnet.nl> wrote in message
news:H8nvnF.2rz@lugnet.com...
> snip
> At the maximum speed, whit a good (low) package lost, the program • takes
> 375ms, and has a package lost of 7. So the RCX has send 1 adress • package,
> 250 data-packages, and 7 adress and data packages(the lost packages)
A 3% error rates (7 out of 250 messages) is far too high. I would have
expected error rates under 1 in 10 million range. Either your
hardware/bus is extremely noisy or else you're experiencing some nasty
software side effects / bugs. the serial link I2C bus should be far
more reliable than your internet connection; how well would your ISP
connection perform if every 35th byte was in error?
> snip
> NQC max speed 27 bits/sec.
> BrickOS max speed 6360 bits/sec.
>
> snip
> ...the maximum speed of the I2C bus at normal speed is 100Kbits/sec. • i
> got here 6360bits/sec, So it could go a LOT faster, but therefore • the pulses
> must be much more stable.
You've achieved some good throughput but the RCX is more capable than
that. An I2C bus is internally used in the RCX to interface to the
LCD. I've measured its performance and RCX transfers data to the LCD
at 75000 bits per second on this I2C bus. I measured 16.77 seconds to
do 10,000 calls to the ROM routine that refreshes the complete LCD
(it's a 14 byte message including address headers, commands and data
bytes).
Your external I2C bus should be able to achieve similar rates; the
internal LCD I2C bus uses bits 5 and 6 (clock and data) of I/O Port 6
on the H8 CPU and the sensors 8 volt outputs are connected to bits 0,
1, and 2 on the same port.
The multiple use of Port 6 might explain one possible software bug.
The LCD handlers, the sensor handlers and now your software may all be
trying to simultaneously write to port 6 from different tasks with
different priorities. You could wrap access with a semaphore /
critical section to limit access to a single task at a time. I found
an easier way using BSET and BCLR instructions which only operate on a
single bit. For example, I replaced statement like
IOPort6DataRegister &= ~(p6Sensor0Output | p6Sensor1Output |
p6Sensor2Output);
with:
IOPort6DataRegister &= ~p6Sensor0Output;
IOPort6DataRegister &= ~p6Sensor1Output;
IOPort6DataRegister &= ~p6Sensor2Output;
The first statement loads Port 6 into a H8 register, ANDs the value
with a mask and then writes it back out to Port 6. Bug occurs when
there is a task swap or interrupt between the first and third
instruction. The second version results in three separate BSET
instructions and no race condition.
|
|
Message has 1 Reply:
 | | Re: I2C device for the RCX
|
| Dick Swan wrote: >I don't understand your references to clock pulses. The I2C protocol >is edge triggered with a data bit transferred as the clock signal >transitions from a LOW to HIGH value. Where do clock pulses come into >play? OK, as a (...) (22 years ago, 14-Jan-03, to lugnet.robotics)
|
Message is in Reply To:
| | Re: I2C device for the RCX
|
| Before starting the hacking,I did some tests whit this 'for-lus-delay', and I found the results better than expected. I found that this: for(long i=0;i<100000;i++); takes about 120ms, so one for lus takes 0.0012ms. I made a test program which first (...) (22 years ago, 13-Jan-03, to lugnet.robotics)
|
24 Messages in This Thread:
 
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
