 | | | | | |
In lugnet.robotics.rcx.legos, Carl Troein wrote:
> Another thing: We should have a good asm implementation of the Power
> Functions protocol. I've ordered the Emerald Night collection so soon
> I'll have some power functions parts and a reason to control them
> with BrickOS. Hopefully that will lead to something.
I've recently mucked about with the Power Functions protocol, and got a proof of
concept running on the RCX using brickOS. The main problem is that it's quite
timing sensitive, so this code only worked reliably with interrupts disabled
(looking at the oscilloscope).
The sample code is at http://www.algonet.se/~yann/powerfunctions.c
The timing requirements are probably more lax in reality (PF protocol spec cites
ranges like 316-526us for a 0 bit), but my code was thrown off by whole periods
(of the 38kHz modulation signal) as other interrupts occurred.
| | | | | | | | | | | | | | | |
| |
|
Hello Yann,
2010/6/15 Yann Vernier <yann@algonet.se>:
>
> I've recently mucked about with the Power Functions protocol, and got a proof of
> concept running on the RCX using brickOS. The main problem is that it's quite
> timing sensitive, so this code only worked reliably with interrupts disabled
> (looking at the oscilloscope).
>
> The sample code is at http://www.algonet.se/~yann/powerfunctions.c
>
> The timing requirements are probably more lax in reality (PF protocol spec cites
> ranges like 316-526us for a 0 bit), but my code was thrown off by whole periods
> (of the 38kHz modulation signal) as other interrupts occurred.
I really would prefer to see the interrupt code running to disabling
all interrupts for several milliseconds, loosing several ticks and
disabling all sensors during this time.
Did you apply one of my performance patches to brickOS? IIRC, the
current release of brickOS still has a busy waiting loop in the sensor
interrupt, which explains why you get corrupt timings. The patches
are at
http://hoenicke.ath.cx/rcx/brickOS.html
You can also use my simulator brickemu to get some statistics about
maximal run-time of interrupts. It shouldn't be too difficult to add
debugging output to the 8-bit timer to get cycle exact information of
when the registers are set. You can also debug your code with
brickemu by adding printf in your code.
It looks hard to get the interrupts fast enough, though. According to
my statistics, the timer interrupt in bibo can take up to 1031 cycles,
i.e 65 us, which is still more than the period of your timer. On
average it runs in only half the time, so you should not loose so many
cycles that your signal is distorted beyond recognition.
Regards,
Jochen
| | | | | | | | | | | | | | | | | |
| |
|
Re: Power Functions:
There is an older thread on the topic of Power Functions at [
http://news.lugnet.com/general/?n=54443&t=i&v=a ] which includes links to
some BrickOS-based code for Power Functions. Be sure to follow the thread
to the end, as some of the links mentioned earlier on no longer work. The
current working link is [ http://www.bong69.com/pages/software.php ] (scroll
to the bottom of that page). Note that this code also disables/enables
interrupts.
Re: Interrupts
The LDCC patch, which Mark Riley wrote to output DCC waveforms over the
motor outputs, also disables interrupts, as DCC requires very precise
timings. Since creating the rollup release noted earlier [
http://news.lugnet.com/robotics/rcx/legos/?n=4057 ], which is itself based
on Jochen's Bibo release, I haven't tried running LDCC without disabling the
interrupts, but based on Jochen's description, I'll have to give that a try.
As a side note, LDCC has also been integrated into pbForth [
http://news.lugnet.com/robotics/rcx/?n=2297 ].
LDCC Links
* http://news.lugnet.com/org/ca/rtltoronto/?n=14996
* http://home.surewest.net/markril/lego/dcc/
Cheers,
Matthew
| | | | | | |
