Yahoo Groups archive
Thread
2005-06-06 by mirekwind
does anyone know why codevision refuses to create COF file even if such format is selected in project setup? Also "Errors occured during assembly" is displayed but .asm file is created without errors. thanks for any feedback
2005-06-07 by Dave VanHorn
Speed contest: Fast code desired, space is no object. Task: Make UP look like Down by rotating all the bits in a byte. Input in TEMP, output in TEMP2 or for bonus points, in TEMP, such that Input: 7,6,5,4,3,2,1,0 10101110 or AE Routine happens, then Output: 0,1,2,3,4,5,6,7 01110101 or 75 The obvious solution is to clear the output and set the bits with SBRC like this: ; ;************************************************************************************* ; ;Bit swap end for end. ; Untwist: push TEMP2 ; clr TEMP2 ; sbrc TEMP,0 ; sbr TEMP2,1<<7 ; sbrc TEMP,1 ; sbr TEMP2,1<<6 ; sbrc TEMP,2 ; sbr TEMP2,1<<5 ; sbrc TEMP,3 ; sbr TEMP2,1<<4 ; sbrc TEMP,4 ; sbr TEMP2,1<<3 ; sbrc TEMP,5 ; sbr TEMP2,1<<2 ; sbrc TEMP,6 ; sbr TEMP2,1<<1 ; sbrc TEMP,7 ; sbr TEMP2,1<<0 ; mov TEMP,TEMP2 ; pop TEMP2 ret ;
2005-06-07 by Richard Reeves
> Speed contest: Fast code desired, space is no object. Look-up table: fred: ldi zl, low(reverse*2) ldi zh, high(reverse*2) add zl, temp lpm temp,z ret .org $xx00 reverse: .db <insert 256 byte table> I think that's six cycles if it's not a subroutine. Richard --- "Iz dana u dan ona dolazi i odlazi u talasima" http://www.van-gogh.co.yu/
2005-06-07 by James Hatley
Hi Dave, How about ROL TEMP then ROR TEMP2 etc. enough to move number. Jim ----- Original Message ----- From: "Dave VanHorn" <dvanhorn@dvanhorn.org> To: <AVR-Chat@yahoogroups.com> Sent: Tuesday, June 07, 2005 1:35 PM Subject: [AVR-Chat] Challenge > > Speed contest: Fast code desired, space is no object. > > Task: Make UP look like Down by rotating all the bits in a byte. > > Input in TEMP, output in TEMP2 or for bonus points, in TEMP, such that > > Input: 7,6,5,4,3,2,1,0 10101110 or AE > > Routine happens, then > > Output: 0,1,2,3,4,5,6,7 01110101 or 75 > > The obvious solution is to clear the output and set the bits with > SBRC like this: > > ; > ;*************************************************************************** **********
> ; > ;Bit swap end for end. > ; > Untwist: > push TEMP2 ; > clr TEMP2 ; > > sbrc TEMP,0 ; > sbr TEMP2,1<<7 ; > > sbrc TEMP,1 ; > sbr TEMP2,1<<6 ; > > sbrc TEMP,2 ; > sbr TEMP2,1<<5 ; > > sbrc TEMP,3 ; > sbr TEMP2,1<<4 ; > > sbrc TEMP,4 ; > sbr TEMP2,1<<3 ; > > sbrc TEMP,5 ; > sbr TEMP2,1<<2 ; > > sbrc TEMP,6 ; > sbr TEMP2,1<<1 ; > > sbrc TEMP,7 ; > sbr TEMP2,1<<0 ; > > mov TEMP,TEMP2 ; > > pop TEMP2 > ret ; > > > > > > Yahoo! Groups Links > > > > > > > >
2005-06-07 by erikc
James Hatley wrote: > Hi Dave, > > How about ROL TEMP then ROR TEMP2 etc. enough to move number. > > Jim Use TEMP to index into an array, result either to TEMP or TEMP2. After all, space is no object. erikc
2005-06-07 by Richard Austin
Dave VanHorn wrote: > Speed contest: Fast code desired, space is no object. > > Task: Make UP look like Down by rotating all the bits in a byte. > > Input in TEMP, output in TEMP2 or for bonus points, in TEMP, such that > > Input: 7,6,5,4,3,2,1,0 10101110 or AE > > Routine happens, then > > Output: 0,1,2,3,4,5,6,7 01110101 or 75 > > The obvious solution is to clear the output and set the bits with > SBRC like this: > > ; > ;************************************************************************************* > ; > ;Bit swap end for end. > ; > Untwist: > push TEMP2 ; > clr TEMP2 ; > > sbrc TEMP,0 ; > sbr TEMP2,1<<7 ; > > sbrc TEMP,1 ; > sbr TEMP2,1<<6 ; > > sbrc TEMP,2 ; > sbr TEMP2,1<<5 ; > > sbrc TEMP,3 ; > sbr TEMP2,1<<4 ; > > sbrc TEMP,4 ; > sbr TEMP2,1<<3 ; > > sbrc TEMP,5 ; > sbr TEMP2,1<<2 ; > > sbrc TEMP,6 ; > sbr TEMP2,1<<1 ; > > sbrc TEMP,7 ; > sbr TEMP2,1<<0 ; > > mov TEMP,TEMP2 ; > > pop TEMP2 > ret ; > > > > > > Yahoo! Groups Links > > > > > > > > > Solution 1 Cross wire port A to Port B (or any other port combination. Output byte on one port and read back on another. Solution 2 Use a look up table and index the answer by the question byte. 256 bytes + the load register with answer. Don't think you can can quicker than these.
2005-06-07 by Dave VanHorn
At 03:45 PM 6/7/2005, Richard Reeves wrote: > > > Speed contest: Fast code desired, space is no object. >Look-up table: > >fred: > ldi zl, low(reverse*2) > ldi zh, high(reverse*2) > add zl, temp > lpm temp,z > ret We have to add another instruction, unless as you specified, the table is positioned on a boundary. That wasn't completely clear, but it does get there.
2005-06-07 by Dave VanHorn
>
>Solution 1
>
>Cross wire port A to Port B (or any other port combination. Output byte
>on one port and read back on another.
I like it! :)
Interestingly enough, it's not THAT much faster than the table, but
down here it counts.
I'm pretty sure this table is right.
reverse: ; 0 1 2 3 4 5 6 7 8 9 A B C D E F
.db
$00,$80,$40,$C0,$20,$A0,$60,$E0,$10,$90,$50,$D0,$30,$B0,$70,$F0 ;$0X
.db
$08,$88,$48,$C8,$28,$A8,$68,$E8,$18,$98,$58,$D8,$38,$B8,$78,$F8 ;$1X
.db
$04,$84,$44,$C4,$24,$A4,$64,$E4,$14,$94,$54,$D4,$34,$B4,$74,$F4 ;$2X
.db
$0C,$8C,$4C,$CC,$2C,$AC,$6C,$EC,$1C,$9C,$5C,$DC,$3C,$BC,$7C,$FC ;$3X
.db
$02,$82,$42,$C2,$22,$A2,$62,$E2,$12,$92,$52,$D2,$32,$B2,$72,$F2 ;$4X
.db
$0A,$8A,$4A,$CA,$2A,$AA,$6A,$EA,$1A,$9A,$5A,$DA,$3A,$BA,$7A,$FA ;$5X
.db
$06,$86,$46,$C6,$26,$A6,$66,$E6,$16,$96,$56,$D6,$36,$B6,$76,$F6 ;$6X
.db
$0E,$8E,$4E,$CE,$2E,$AE,$6E,$EE,$1E,$9E,$5E,$DE,$3E,$BE,$7E,$FE ;$7X
.db
$01,$81,$41,$C1,$21,$A1,$61,$E1,$11,$91,$51,$D1,$31,$B1,$71,$F1 ;$8X
.db
$09,$89,$49,$C9,$29,$A9,$69,$E9,$19,$99,$59,$D9,$39,$B9,$79,$F9 ;$9X
.db
$05,$85,$45,$C5,$25,$A5,$65,$E5,$15,$95,$55,$D5,$35,$B5,$75,$F5 ;$AX
.db
$0D,$8D,$4D,$CD,$2D,$AD,$6D,$ED,$1D,$9D,$5D,$DD,$3D,$BD,$7D,$FD ;$BX
.db
$03,$83,$43,$C3,$23,$A3,$63,$E3,$13,$93,$53,$D3,$33,$B3,$73,$F3 ;$CX
.db
$0B,$8B,$4B,$CB,$2B,$AB,$6B,$EB,$1B,$9B,$5B,$DB,$3B,$BB,$7B,$FB ;$DX
.db
$07,$87,$47,$C7,$27,$A7,$67,$E7,$17,$97,$57,$D7,$37,$B7,$77,$F7 ;$EX
.db
$0F,$8F,$4F,$CF,$2F,$AF,$6F,$EF,$1F,$9F,$5F,$DF,$3F,$BF,$7F,$FF ;$FX2005-06-08 by Dave Hylands
> I'm pretty sure this table is right. And what I often do is write a little C program which I compile on my PC that I use to generate source code for tables like this (or CRC lookups etc). I typically include the C program #if 0'd out in my source file that uses it as a way of documenting how the table was actually created. If you don't want to use 256 bytes for the lookup table, you could also do a pair of (or a single) 16 byte lookup table which flipped 4 bits. Now you have a pretty wide execution time/space tradeoff and you can picks what's appropriate for your project. -- Dave Hylands Vancouver, BC, Canada http://www.DaveHylands.com/
2005-06-08 by Dave VanHorn
At 07:15 PM 6/7/2005, Dave Hylands wrote: > > I'm pretty sure this table is right. > >And what I often do is write a little C program which I compile on my >PC that I use to generate source code for tables like this (or CRC >lookups etc). > >I typically include the C program #if 0'd out in my source file that >uses it as a way of documenting how the table was actually created. A good idea! >If you don't want to use 256 bytes for the lookup table, you could >also do a pair of (or a single) 16 byte lookup table which flipped 4 >bits. Now you have a pretty wide execution time/space tradeoff and you >can picks what's appropriate for your project. I don't really need it, I was just musing about it. We have rotate and swap instructions, but not "flip" (or whatever you'd call it.)
2005-06-08 by Bernd Felsche
On Wednesday 08 June 2005 08:37, Dave VanHorn wrote: > At 07:15 PM 6/7/2005, Dave Hylands wrote: > > > I'm pretty sure this table is right. > >And what I often do is write a little C program which I compile on my > >PC that I use to generate source code for tables like this (or CRC > >lookups etc). > > > >I typically include the C program #if 0'd out in my source file that > >uses it as a way of documenting how the table was actually created. > > A good idea! > > >If you don't want to use 256 bytes for the lookup table, you could > >also do a pair of (or a single) 16 byte lookup table which flipped 4 > >bits. Now you have a pretty wide execution time/space tradeoff and you > >can picks what's appropriate for your project. > I don't really need it, I was just musing about it. > We have rotate and swap instructions, but not "flip" (or whatever > you'd call it.) You do... but despite my being able to rake in the millions by patenting the bleeding obvious in the USA, it's called an exclusive-or with a 1 for all bits you want to flip. :-) -- /"\ Bernd Felsche - Innovative Reckoning, Perth, Western Australia \ / ASCII ribbon campaign | I'm a .signature virus! X against HTML mail | Copy me into your ~/.signature / \ and postings | to help me spread!
2005-06-08 by Jeffrey Engel
Use a table with all the bits "pre-swapped"? Jeff Engel --- Dave VanHorn <dvanhorn@dvanhorn.org> wrote: > > Speed contest: Fast code desired, space is no > object. > > Task: Make UP look like Down by rotating all the > bits in a byte. > > Input in TEMP, output in TEMP2 or for bonus points, > in TEMP, such that > > Input: 7,6,5,4,3,2,1,0 10101110 or AE > > Routine happens, then > > Output: 0,1,2,3,4,5,6,7 01110101 or 75 > > The obvious solution is to clear the output and set > the bits with > SBRC like this: > > ; > ;************************************************************************************* > ; > ;Bit swap end for end. > ; > Untwist: > push TEMP2 ; > clr TEMP2 ; > > sbrc TEMP,0 ; > sbr TEMP2,1<<7 ; > > sbrc TEMP,1 ; > sbr TEMP2,1<<6 ; > > sbrc TEMP,2 ; > sbr TEMP2,1<<5 ; > > sbrc TEMP,3 ; > sbr TEMP2,1<<4 ; > > sbrc TEMP,4 ; > sbr TEMP2,1<<3 ; > > sbrc TEMP,5 ; > sbr TEMP2,1<<2 ; > > sbrc TEMP,6 ; > sbr TEMP2,1<<1 ; > > sbrc TEMP,7 ; > sbr TEMP2,1<<0 ; > > mov TEMP,TEMP2 ; > > pop TEMP2 > ret ; > > > > > > Yahoo! Groups Links > > > AVR-Chat-unsubscribe@yahoogroups.com > > > > > > Happiness is - positive intake manifold pressure. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
2005-06-08 by Peter Gargano
Bernd Felsche wrote: >>We have rotate and swap instructions, but not "flip" ... > > You do ... it's called an > exclusive-or with a 1 for all bits you want to flip. :-) Arrh, thart be magic and secret information Bernd - not to be carelessly disseminated to the heathen masses! P.
2005-06-08 by Paul Maddox
Dave,
> Speed contest: Fast code desired, space is no object.
> Task: Make UP look like Down by rotating all the bits in a byte.
> Input in TEMP, output in TEMP2 or for bonus points, in TEMP, such that
you want quick? and space isn't a problem?
use a Look Up Table, and use LPM
simply copy the value from the TEMP register to R30, dump the table location
into R31 (and Left shift it, or just keep a value thats correct to avoid
this step) and the move r0 to Temp2
.EQU TABLE_LOC =$02
REVERSE:
LDI R31,TABLE_LOC
MOV R30,TEMP
LPM
MOV TEMP2,R0
.ORG $0100
REVERSE_TABLE:
.db 0xFF,0xFE,0xFD, etc, etc, etc
not sure the code is 100% correct, but you get the idea.
Paul2005-06-08 by Dave VanHorn
Then we have an even shorter variant possible: >REVERSE: > LDI R31,TABLE_LOC > MOV R30,TEMP > LPM TEMP But, I maybe should have put the table option out as "obvious". Ok, what if I say "no tables"?
2005-06-08 by Paul Maddox
Dave, > Then we have an even shorter variant possible: > But, I maybe should have put the table option out as "obvious". > Ok, what if I say "no tables"? what are you? a sadist? I guess this isn't a 'real world' application, but, more of a question of "I wonder how you'd do this?" Paul
2005-06-08 by Dave VanHorn
At 08:45 AM 6/8/2005, Paul Maddox wrote: >Dave, > > > Then we have an even shorter variant possible: > > But, I maybe should have put the table option out as "obvious". > > Ok, what if I say "no tables"? > >what are you? a sadist? >I guess this isn't a 'real world' application, but, more of a question of "I >wonder how you'd do this?" I think I said that :) Interestingly, with this latest version, we are approaching the hardware based solution with two instructions and eight wires, as far as speed.
2005-06-08 by Dave VanHorn
> >You do... but despite my being able to rake in the millions by >patenting the bleeding obvious in the USA, it's called an >exclusive-or with a 1 for all bits you want to flip. :-) I'm not talking about inversion, I'm talking about reversal, where the data that was in bit 7 ends up in 0, 6 ends up in 1, and so on, till 0 ends up in 7.
2005-06-08 by Paul Maddox
Hi, > I'm not talking about inversion, I'm talking about reversal, where > the data that was in bit 7 ends up in 0, 6 ends up in 1, and so on, > till 0 ends up in 7. I just wanted to say, I had to do this before, when a the guy who did the PCB for a project made a mistake and reversed all the bits on a port and no-one noticed until the code didn't work properly.. As the board was already assembled and hardwired (SMD) we had to use the 'soft' approach and a LUT was used. Paul
2005-06-08 by Dave VanHorn
> >I just wanted to say, I had to do this before, when a the guy who did the >PCB for a project made a mistake and reversed all the bits on a port and >no-one noticed until the code didn't work properly.. >As the board was already assembled and hardwired (SMD) we had to use the >'soft' approach and a LUT was used. I had one once where the board maker flipped the layers. He put the solder layer on the top, and the component layer on the bottom. Fortunately, DIP chips aren't THAT hard to bend the pins the other way.. Rewiring the keyboard was a bit of a pain. Excrement Occurs, and it's often up to us to deal with it somehow. This challenge is proving more interesting than I thought it would, already.
2005-06-08 by Bernd Felsche
On Wednesday 08 June 2005 21:49, Dave VanHorn wrote: > >You do... but despite my being able to rake in the millions by > >patenting the bleeding obvious in the USA, it's called an > >exclusive-or with a 1 for all bits you want to flip. :-) > I'm not talking about inversion, I'm talking about reversal, where > the data that was in bit 7 ends up in 0, 6 ends up in 1, and so on, > till 0 ends up in 7. Sorry... If you actually want things that actually work you have to ask *after* my second coffee in the morning. :-) Cross-wired ports is an obvious solution for speed. Very hard to beat in terms of cycles because it's "external microcode". -- /"\ Bernd Felsche - Innovative Reckoning, Perth, Western Australia \ / ASCII ribbon campaign | I'm a .signature virus! X against HTML mail | Copy me into your ~/.signature / \ and postings | to help me spread!
2005-06-08 by alwelch93021
--- In AVR-Chat@yahoogroups.com, "mirekwind" <interinar@a...> wrote: > does anyone know why codevision refuses to create COF file even if such > format is selected in project setup? Also "Errors occured during > assembly" is displayed but .asm file is created without errors. > thanks for any feedback My guess is you have an error in the sources and most likely you have used an inline assembly instruction. I had this problem a while back and you will not see an error in the C compiling but I think you can find the error in the list file. If you do not resolve it you can zip up your sources and send to Codevision and they will reply with an answer as to what the problem is. Al Welch
2005-06-08 by Peter Harrison
Paul Maddox wrote: > Dave, > > >>Then we have an even shorter variant possible: >>But, I maybe should have put the table option out as "obvious". >>Ok, what if I say "no tables"? > > > what are you? a sadist? > I guess this isn't a 'real world' application, but, more of a question of "I > wonder how you'd do this?" > > Paul > > This is indeed a real world application. Some Fast Fourier Transforms require bit reversal to put all the coefficients back in their rightful places. There is a fairly classic solution described on this page: http://netghost.narod.ru/gff/graphics/book/ch06_04.htm It does not look fast but, as far as I recall, it is. Oh, well, assuming you want a portable solution in C... Pete Harrison
2005-06-08 by John Samperi
At 11:49 PM 8/06/2005, you wrote:
>it's called an
> >exclusive-or with a 1 for all bits you want to flip. :-)
>
>I'm not talking about inversion, I'm talking about reversal, where
>the data that was in bit 7 ends up in 0, 6 ends up in 1, and so on,
>till 0 ends up in 7.
Thank goodness....I was awake all night trying to figure out
the above answer....it seems the wires were crossed.....
which is not too bad as a solution..... :-| Heeelp I'm
going crazier....
Regards
John Samperi
******************************************************
Ampertronics Pty. Ltd.
11 Brokenwood Place Baulkham Hills, NSW 2153 AUSTRALIA
Tel. (02) 9674-6495 Fax (02) 9674-8745
Email: samperi@ampertronics.com.au
Website http://www.ampertronics.com.au
* Electronic Design * Custom Products * Contract Assembly
******************************************************2005-06-09 by wbounce
I am trying to diagnose a problem I am having with the devantech
compass. I have 3 SRF08 sonars and a cmp03 compass connected to my
MavricII board (M128). Using winavr 3.4.1. I am using a set I2C routines
from Brian Dean's sample programs. I use the same routines to ping the
sonar as I do to read the compass so I am fairly certain they are not
the problem. Because I am pinging all 3 sonars at once, I moved my
reading of the compass to before I do the ping and after I have read the
ranges. I list the compass reading routines bearing16 calls
cmps03_get_word. The ErrorState is consistently being set to -30 which
means a failed start condition. Yet as soon as it returned from
bearing16 it calls the sonar ping which calls the same call but it
succeeds. I have checked the connects to the compass. But after ooking
at the code writing this email up it has to be something other than
that. First 1st thought was bad connection which is usually the problem
when one of the sonars stop working but at least with a sonar it has a
led that flashes when it pings so I can tell it is working. How can I
tell the compass is working? And is there anything in this code that
would cause the I2c to fail?
tempbearing = bearing16();
if ( tempbearing > -1)
{
CurrentBearing = tempbearing;
}
else
{
ErrorState = (int8_t)tempbearing;
printf_P(PSTR("CError %i"),ErrorState);
}
printf_P(PSTR("pg "));
srf08_ping(ALLDEVICES, RANGE_US); /* initiate a ping, distance
in cm */
int16_t bearing16(void)
{
uint16_t d;
int8_t rc;
printf_P(PSTR("Be "));
rc = cmps03_get_word(0x60, 2, &d);
if (rc < 0) {
ErrorState = rc;
return (int16_t )rc;
}
return d;
}
int8_t cmps03_get_word(uint8_t device, uint8_t addr, uint16_t * value)
{
uint8_t v1, v2;
/* start condition */
if (i2c_start(0x08, 0))
return -30;
/* address slave device, write */
if (i2c_sla_rw(device, 0, TW_MT_SLA_ACK, 0))
return -31;
/* write register address */
if (i2c_data_tx(addr, TW_MT_DATA_ACK, 0))
return -32;
/* repeated start condition */
if (i2c_start(0x10, 0))
return -33;
/* address slave device, read */
if (i2c_sla_rw(device, 1, TW_MR_SLA_ACK, 0))
return -34;
/* read data byte 1 */
if (i2c_data_rx(&v1, I2C_ACK, TW_MR_DATA_ACK, 0))
return -35;
/* read data byte 2 */
if (i2c_data_rx(&v2, I2C_NACK, TW_MR_DATA_NACK, 0))
return -36;
if (i2c_stop())
return -37;
*value = (v1 << 8) | v2 ;
return 0;
}
int8_t srf08_ping(uint8_t device, uint8_t cmd)
{
/* start condition */
if (i2c_start(0x08, 0))
return -1;
/* address slave device, write */
if (i2c_sla_rw(device, 0, TW_MT_SLA_ACK, 0))
return -2;
/* write address */
if (i2c_data_tx(0x00, TW_MT_DATA_ACK, 0))
return -3;
/* write command */
if (i2c_data_tx(cmd, TW_MT_DATA_ACK, 0))
return -4;
if (i2c_stop())
return -5;
return 0;
}2005-06-09 by mirekwind
Al, moving codevision to c:\cvavr fixes the problems. The path cannot have embedded spaces. Installing it to c:\Program Files\cvavr on Windows XP causes this problem as "Program Files" contains embedded space. Thanks --- In AVR-Chat@yahoogroups.com, "alwelch93021" <alwelch@a...> wrote:
> --- In AVR-Chat@yahoogroups.com, "mirekwind" <interinar@a...> wrote: > > does anyone know why codevision refuses to create COF file even if > such > > format is selected in project setup? Also "Errors occured during > > assembly" is displayed but .asm file is created without errors. > > thanks for any feedback > > My guess is you have an error in the sources and most likely you have > used an inline assembly instruction. I had this problem a while back > and you will not see an error in the C compiling but I think you can > find the error in the list file. > > If you do not resolve it you can zip up your sources and send to > Codevision and they will reply with an answer as to what the problem > is. > > Al Welch
2005-06-09 by Joel Kolstad
--- In AVR-Chat@yahoogroups.com, Peter Harrison <peter_harrison@n...> wrote: > There is a fairly classic solution described on this page: > http://netghost.narod.ru/gff/graphics/book/ch06_04.htm > It does not look fast but, as far as I recall, it is. It appears to require 6 shifts, six ANDs, and 5 ORs... seems unlikely it would be faster than the "straightforward" implementation? It looks like a case of someone trying to be clever after they learned why a quicksort is better than something like a bubble sort (what he does is swap bits 0/1, 2/3, 4/5, 6/7... then 0-1/2-3, 4-5/6-7, and finally 0- 3/4-7). The problem is that with only 8 bits there's not any speedup yet that I can see -- just as smart general purpose sorting routines will revert to something like a bubble sort of lists of less than, say, 10 items! ---Joel Kolstad
2005-06-09 by Dave VanHorn
> >It appears to require 6 shifts, six ANDs, and 5 ORs... seems unlikely >it would be faster than the "straightforward" implementation? It looks >like a case of someone trying to be clever after they learned why a >quicksort is better than something like a bubble sort (what he does is >swap bits 0/1, 2/3, 4/5, 6/7... then 0-1/2-3, 4-5/6-7, and finally 0- >3/4-7). The problem is that with only 8 bits there's not any speedup >yet that I can see -- just as smart general purpose sorting routines >will revert to something like a bubble sort of lists of less than, say, >10 items! Unless someone pops up from left field here with a new solution, I'm going to say that we have a couple of nice solutions now, and call this one "done". The table lookup is, somewhat surprisingly efficient, other than on code space, especially when the table can be located on an even page. Interestingly enough, I think it executes in the equivalent of one instruction on the PIC. VBG! The external loopback is fun, if you have the pins available. That's the point of challenges like this, to encourage "out of the box" thinking and explore ideas. So, anyone want to propose a new little problem?
2005-06-09 by Ralph Hilton
On Thu, 09 Jun 2005 11:21:50 -0500 you wrote: > >> >>It appears to require 6 shifts, six ANDs, and 5 ORs... seems unlikely >>it would be faster than the "straightforward" implementation? It looks >>like a case of someone trying to be clever after they learned why a >>quicksort is better than something like a bubble sort (what he does is >>swap bits 0/1, 2/3, 4/5, 6/7... then 0-1/2-3, 4-5/6-7, and finally 0- >>3/4-7). The problem is that with only 8 bits there's not any speedup >>yet that I can see -- just as smart general purpose sorting routines >>will revert to something like a bubble sort of lists of less than, say, >>10 items! > >Unless someone pops up from left field here with a new solution, I'm >going to say that we have a couple of nice solutions now, and call >this one "done". > >The table lookup is, somewhat surprisingly efficient, other than on >code space, especially when the table can be located on an even page. >Interestingly enough, I think it executes in the equivalent of one >instruction on the PIC. VBG! > >The external loopback is fun, if you have the pins available. > >That's the point of challenges like this, to encourage "out of the >box" thinking and explore ideas. > > > >So, anyone want to propose a new little problem? This one is known but can prove a puzzler if one doesn't know it. How do you swap the contents of 2 registers without using any other registers or stack? -- Ralph Hilton http://www.ralphhilton.org C-Meter: http://www.cmeter.org FZAOINT http://www.fzaoint.net
2005-06-09 by Dave VanHorn
> >This one is known but can prove a puzzler if one doesn't know it. > >How do you swap the contents of 2 registers without using any other >registers or >stack? Hmm. This one makes my head spin :)
2005-06-09 by James Hatley
Roll through carry. Jim ----- Original Message ----- From: "Ralph Hilton" <ralph@ralphhilton.org> To: <AVR-Chat@yahoogroups.com> Sent: Thursday, June 09, 2005 9:35 AM Subject: Re: [AVR-Chat] Re: Challenge > On Thu, 09 Jun 2005 11:21:50 -0500 you wrote: > > > > >> > >>It appears to require 6 shifts, six ANDs, and 5 ORs... seems unlikely > >>it would be faster than the "straightforward" implementation? It looks > >>like a case of someone trying to be clever after they learned why a > >>quicksort is better than something like a bubble sort (what he does is > >>swap bits 0/1, 2/3, 4/5, 6/7... then 0-1/2-3, 4-5/6-7, and finally 0- > >>3/4-7). The problem is that with only 8 bits there's not any speedup > >>yet that I can see -- just as smart general purpose sorting routines > >>will revert to something like a bubble sort of lists of less than, say, > >>10 items! > > > >Unless someone pops up from left field here with a new solution, I'm > >going to say that we have a couple of nice solutions now, and call > >this one "done". > > > >The table lookup is, somewhat surprisingly efficient, other than on > >code space, especially when the table can be located on an even page. > >Interestingly enough, I think it executes in the equivalent of one > >instruction on the PIC. VBG! > > > >The external loopback is fun, if you have the pins available. > > > >That's the point of challenges like this, to encourage "out of the > >box" thinking and explore ideas. > > > > > > > >So, anyone want to propose a new little problem? > > This one is known but can prove a puzzler if one doesn't know it. > > How do you swap the contents of 2 registers without using any other registers or
> stack? > -- > Ralph Hilton > http://www.ralphhilton.org > C-Meter: http://www.cmeter.org > FZAOINT http://www.fzaoint.net > > > > Yahoo! Groups Links > > > > > > >
2005-06-09 by Ralph Hilton
On Thu, 9 Jun 2005 09:50:38 -0700 you wrote: >Roll through carry. > >Jim ok. I should have said using no other storage, flags included. >----- Original Message ----- >From: "Ralph Hilton" <ralph@ralphhilton.org> >To: <AVR-Chat@yahoogroups.com> >Sent: Thursday, June 09, 2005 9:35 AM >Subject: Re: [AVR-Chat] Re: Challenge > > >> On Thu, 09 Jun 2005 11:21:50 -0500 you wrote: >> >> > >> >> >> >>It appears to require 6 shifts, six ANDs, and 5 ORs... seems unlikely >> >>it would be faster than the "straightforward" implementation? It looks >> >>like a case of someone trying to be clever after they learned why a >> >>quicksort is better than something like a bubble sort (what he does is >> >>swap bits 0/1, 2/3, 4/5, 6/7... then 0-1/2-3, 4-5/6-7, and finally 0- >> >>3/4-7). The problem is that with only 8 bits there's not any speedup >> >>yet that I can see -- just as smart general purpose sorting routines >> >>will revert to something like a bubble sort of lists of less than, say, >> >>10 items! >> > >> >Unless someone pops up from left field here with a new solution, I'm >> >going to say that we have a couple of nice solutions now, and call >> >this one "done". >> > >> >The table lookup is, somewhat surprisingly efficient, other than on >> >code space, especially when the table can be located on an even page. >> >Interestingly enough, I think it executes in the equivalent of one >> >instruction on the PIC. VBG! >> > >> >The external loopback is fun, if you have the pins available. >> > >> >That's the point of challenges like this, to encourage "out of the >> >box" thinking and explore ideas. >> > >> > >> > >> >So, anyone want to propose a new little problem? >> >> This one is known but can prove a puzzler if one doesn't know it. >> >> How do you swap the contents of 2 registers without using any other >registers or >> stack? -- Ralph Hilton http://www.ralphhilton.org C-Meter: http://www.cmeter.org FZAOINT http://www.fzaoint.net
2005-06-09 by Mark Jordan
On 9 Jun 2005 at 18:35, Ralph Hilton wrote: > This one is known but can prove a puzzler if one doesn't know it. > > How do you swap the contents of 2 registers without using any other > registers or stack? Using Carry? (ROR or ROL 8 times)
2005-06-09 by Ralph Hilton
On Thu, 09 Jun 2005 14:23:54 -0300 you wrote: >On 9 Jun 2005 at 18:35, Ralph Hilton wrote: > >> This one is known but can prove a puzzler if one doesn't know it. >> >> How do you swap the contents of 2 registers without using any other >> registers or stack? > > Using Carry? (ROR or ROL 8 times) Without carry < 8 instructions :-) -- Ralph Hilton http://www.ralphhilton.org C-Meter: http://www.cmeter.org FZAOINT http://www.fzaoint.net
2005-06-09 by Zack Widup
I could argue that you're using another register for that! :-) (I have used that on rare occasions though). Zack
On Thu, 9 Jun 2005, James Hatley wrote: > Roll through carry. > > Jim > > > > > This one is known but can prove a puzzler if one doesn't know it. > > > > How do you swap the contents of 2 registers without using any other > registers or > > stack? > > -- > > Ralph Hilton
2005-06-09 by wg0z@aol.com
A = A XOR B B = B XOR A A = A XOR B
-----Original Message----- From: Zack Widup <w9sz@prairienet.org> To: AVR-Chat@yahoogroups.com Sent: Thu, 9 Jun 2005 12:45:19 -0500 (CDT) Subject: Re: [AVR-Chat] Re: Challenge I could argue that you're using another register for that! :-) (I have used that on rare occasions though). Zack On Thu, 9 Jun 2005, James Hatley wrote: > Roll through carry. > > Jim > > > > > This one is known but can prove a puzzler if one doesn't know it. > > > > How do you swap the contents of 2 registers without using any other > registers or > > stack? > > -- > > Ralph Hilton Yahoo! Groups Links
2005-06-09 by arhodes19044
I have not checked your code yet, but.....
Pinging all 3 sonars at the same time? It sounds (pun intended) to
me as if interference will occur between sensors.
If you are not running the sensors at max firing frequency, then it
probably would be best to:
ping Sensor-1
read Sensor-3
after 70 ms from #1, Ping Sensor-2
read Sensor-1
after 70ms from #2, Ping Sensor-3
read Sensor-2
after 70ms from #3, repeat from the top....
you can add a compass reading in there somewhere.
-Tony
--- In AVR-Chat@yahoogroups.com, "wbounce" <wbounce@s...> wrote:
> I am trying to diagnose a problem I am having with the devantech
> compass. I have 3 SRF08 sonars and a cmp03 compass connected to my
> MavricII board (M128). Using winavr 3.4.1. I am using a set I2C
routines
> from Brian Dean's sample programs. I use the same routines to ping
the
> sonar as I do to read the compass so I am fairly certain they are
not
> the problem. Because I am pinging all 3 sonars at once, I moved my
> reading of the compass to before I do the ping and after I have
read the
> ranges. I list the compass reading routines bearing16 calls
> cmps03_get_word. The ErrorState is consistently being set to -30
which
> means a failed start condition. Yet as soon as it returned from
> bearing16 it calls the sonar ping which calls the same call but it
> succeeds. I have checked the connects to the compass. But after
ooking
> at the code writing this email up it has to be something other than
> that. First 1st thought was bad connection which is usually the
problem
> when one of the sonars stop working but at least with a sonar it
has a
> led that flashes when it pings so I can tell it is working. How
can I
> tell the compass is working? And is there anything in this code
that
> would cause the I2c to fail?
>
>
> tempbearing = bearing16();
> if ( tempbearing > -1)
> {
> CurrentBearing = tempbearing;
> }
> else
> {
> ErrorState = (int8_t)tempbearing;
> printf_P(PSTR("CError %i"),ErrorState);
> }
>
> printf_P(PSTR("pg "));
> srf08_ping(ALLDEVICES, RANGE_US); /* initiate a ping,
distance
> in cm */
>
>
> int16_t bearing16(void)
> {
> uint16_t d;
> int8_t rc;
> printf_P(PSTR("Be "));
> rc = cmps03_get_word(0x60, 2, &d);
> if (rc < 0) {
> ErrorState = rc;
> return (int16_t )rc;
> }
>
> return d;
> }
>
> int8_t cmps03_get_word(uint8_t device, uint8_t addr, uint16_t *
value)> {
> uint8_t v1, v2;
>
> /* start condition */
> if (i2c_start(0x08, 0))
> return -30;
>
> /* address slave device, write */
> if (i2c_sla_rw(device, 0, TW_MT_SLA_ACK, 0))
> return -31;
>
> /* write register address */
> if (i2c_data_tx(addr, TW_MT_DATA_ACK, 0))
> return -32;
>
> /* repeated start condition */
> if (i2c_start(0x10, 0))
> return -33;
>
> /* address slave device, read */
> if (i2c_sla_rw(device, 1, TW_MR_SLA_ACK, 0))
> return -34;
>
> /* read data byte 1 */
> if (i2c_data_rx(&v1, I2C_ACK, TW_MR_DATA_ACK, 0))
> return -35;
>
> /* read data byte 2 */
> if (i2c_data_rx(&v2, I2C_NACK, TW_MR_DATA_NACK, 0))
> return -36;
>
> if (i2c_stop())
> return -37;
>
> *value = (v1 << 8) | v2 ;
>
> return 0;
> }
>
>
> int8_t srf08_ping(uint8_t device, uint8_t cmd)
> {
> /* start condition */
> if (i2c_start(0x08, 0))
> return -1;
>
> /* address slave device, write */
> if (i2c_sla_rw(device, 0, TW_MT_SLA_ACK, 0))
> return -2;
>
> /* write address */
> if (i2c_data_tx(0x00, TW_MT_DATA_ACK, 0))
> return -3;
>
> /* write command */
> if (i2c_data_tx(cmd, TW_MT_DATA_ACK, 0))
> return -4;
>
> if (i2c_stop())
> return -5;
>
> return 0;
> }2005-06-09 by Ralph Hilton
On Thu, 09 Jun 2005 14:11:32 -0400 wg0z@aol.com wrote: >A = A XOR B >B = B XOR A >A = A XOR B You got it. Your turn to post a puzzle :-) >> > This one is known but can prove a puzzler if one doesn't know it. >> > >> > How do you swap the contents of 2 registers without using any other >> registers or >> > stack? >> > -- -- Ralph Hilton http://www.ralphhilton.org C-Meter: http://www.cmeter.org FZAOINT http://www.fzaoint.net
2005-06-09 by Andreas Stemmer
> How do you swap the contents of 2 registers without using any other > registers or > stack? How about this one? A = A + B B = A - B A = A - B but I don't know how to do the second step in assembler... Another solution: eor r1, r2 eor r1, r2 eor r1, r2 should work... but I can't prove it Andreas -- Andreas Stemmer <groovingandi@gmx.de>
2005-06-09 by Andreas Stemmer
Andreas Stemmer wrote: > Another solution: > > eor r1, r2 > eor r1, r2 > eor r1, r2 > > should work... but I can't prove it Arghhh, ten minutes too late and wrong as well eor r1, r2 eor r2, r1 eor r1, r2 of course! -- Andreas Stemmer <groovingandi@gmx.de>
2005-06-09 by James Hatley
Good Job! Jeff ... wg0z ... I wouldn't have thought of that. Jim ( k7tt )
----- Original Message ----- From: wg0z@aol.com To: AVR-Chat@yahoogroups.com Sent: Thursday, June 09, 2005 11:11 AM Subject: Re: [AVR-Chat] Re: Challenge A = A XOR B B = B XOR A A = A XOR B -----Original Message----- From: Zack Widup <w9sz@prairienet.org> To: AVR-Chat@yahoogroups.com Sent: Thu, 9 Jun 2005 12:45:19 -0500 (CDT) Subject: Re: [AVR-Chat] Re: Challenge I could argue that you're using another register for that! :-) (I have used that on rare occasions though). Zack On Thu, 9 Jun 2005, James Hatley wrote: > Roll through carry. > > Jim > > > > > This one is known but can prove a puzzler if one doesn't know it. > > > > How do you swap the contents of 2 registers without using any other > registers or > > stack? > > -- > > Ralph Hilton Yahoo! Groups Links Yahoo! Groups Links To visit your group on the web, go to: http://groups.yahoo.com/group/AVR-Chat/ To unsubscribe from this group, send an email to: AVR-Chat-unsubscribe@yahoogroups.com Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
2005-06-09 by Dave VanHorn
At 01:34 PM 6/9/2005, James Hatley wrote: >Good Job! Jeff ... wg0z ... I wouldn't have thought of that. Indeed! I don't see a lot of this sort of thing anymore, here, or on the piclist. Used to be, several years ago.. Thing is, now we need to collect these useful bits somewhere, so they don't get lost.
2005-06-09 by Alexandre Guimaraes
I completely agree with you..... How to organize it ?? Where to put it ?? It is a real shame to have this kind of knowledge being lost with time !! New programmers do not even now how to mask flags in bits !! What about a sister list in Yahoo to keep just the "knowledge bits" ?? Best regards, Alexandre Guimaraes ----- Original Message -----
From: "Dave VanHorn" <dvanhorn@dvanhorn.org> To: <AVR-Chat@yahoogroups.com>; <AVR-Chat@yahoogroups.com> Sent: Thursday, June 09, 2005 3:41 PM Subject: Re: [AVR-Chat] Re: Challenge > At 01:34 PM 6/9/2005, James Hatley wrote: >>Good Job! Jeff ... wg0z ... I wouldn't have thought of that. > > Indeed! > > I don't see a lot of this sort of thing anymore, here, or on the piclist. > Used to be, several years ago.. > > Thing is, now we need to collect these useful bits somewhere, so they > don't get lost. > > > > > Yahoo! Groups Links > > > > > >
2005-06-09 by Zack Widup
When you learn assembler for a particular device I've always likened it to "learning how to think like that device". Each one has little tricks you can use to shorten or speed up a program. They are all different. I remember tricks I used with a Z-80 that don't work on a PIC or AVR (or don't need to because the architecture is so different). Zack
On Thu, 9 Jun 2005, Alexandre Guimaraes wrote: > I completely agree with you..... How to organize it ?? Where to put it > ?? It is a real shame to have this kind of knowledge being lost with time !! > New programmers do not even now how to mask flags in bits !! What about a > sister list in Yahoo to keep just the "knowledge bits" ?? > > Best regards, > Alexandre Guimaraes >
2005-06-09 by Peter Harrison
Dave VanHorn wrote: > At 01:34 PM 6/9/2005, James Hatley wrote: > >>Good Job! Jeff ... wg0z ... I wouldn't have thought of that. > > > Indeed! > > I don't see a lot of this sort of thing anymore, here, or on the piclist. > Used to be, several years ago.. > OK - how about another classic problem. Again, fine when you know but worth looking for a solution. Efficient code for counting the ones in an 8 or 16 bit value - say for a majority vote or some such. Pete Harrison
2005-06-09 by Dave VanHorn
> >OK - how about another classic problem. Again, fine when you know but >worth looking for a solution. Efficient code for counting the ones in an >8 or 16 bit value - say for a majority vote or some such. Ah, bit count, like for parity. I've hit that before.
2005-06-10 by Kathy Quinlan
Alexandre Guimaraes wrote: > I completely agree with you..... How to organize it ?? Where to put it > ?? It is a real shame to have this kind of knowledge being lost with time !! > New programmers do not even now how to mask flags in bits !! What about a > sister list in Yahoo to keep just the "knowledge bits" ?? > > Best regards, > Alexandre Guimaraes We have space here on Yahoo, or I can make space available on my server :) Regards, Kat.
2005-06-10 by Peter Gargano
Kathy Quinlan wrote: > We have space here on Yahoo, or I can make space available on my server :) Atmel, or someone closely associated with them (AVR freaks???) should be the people someone asks for space. Don't underestimate the works required to get any information into a coherent and useful format. I don't spend enough time programming AVR at the moment to know what existing resources are available, but I suggest augmenting an existing info repository rather than a new web site/page. Has anyone checked that the basis of what's being proposed doesn't already exist? Is there an AVR-web-ring? JM$02 P.
2005-06-10 by Kathy Quinlan
Peter Gargano wrote: > Kathy Quinlan wrote: > >>We have space here on Yahoo, or I can make space available on my server :) > > > Atmel, or someone closely associated with them (AVR freaks???) should > be the people someone asks for space. > > Don't underestimate the works required to get any information into a > coherent and useful format. > > I don't spend enough time programming AVR at the moment to know what > existing resources are available, but I suggest augmenting an existing > info repository rather than a new web site/page. Has anyone checked > that the basis of what's being proposed doesn't already exist? > > Is there an AVR-web-ring? > > JM$02 > > P. Yes there is an AVR web-ring, and I am a member, as are a fair few people on this list. I know exactly what it takes to get data ready for online use, as I run my own servers, and webhost for a few clients ( mainly non profit orgs) Regards, Kat.
2005-06-10 by Paul Maddox
All, > I completely agree with you..... How to organize it ?? Where to put it > ?? It is a real shame to have this kind of knowledge being lost with time > !! > New programmers do not even now how to mask flags in bits !! What about a > sister list in Yahoo to keep just the "knowledge bits" ?? if someone is willing to spend the time, I'm happy to provide space and a subdomain of my server (Www.Synth.Net), I don't have the time to do the webpage and update it, but I can supply the space/bandwidth. Paul
2005-06-10 by erikc
Paul Maddox wrote:
> All,
>
>
>> I completely agree with you..... How to organize it ?? Where to put it
>>?? It is a real shame to have this kind of knowledge being lost with time
>>!!
>>New programmers do not even now how to mask flags in bits !! What about a
>>sister list in Yahoo to keep just the "knowledge bits" ??
>
>
> if someone is willing to spend the time, I'm happy to provide space and a
> subdomain of my server (Www.Synth.Net), I don't have the time to do the
> webpage and update it, but I can supply the space/bandwidth.
>
> Paul
I'd like to contribute this bit of code, even though it is not mine.
I got it from here
http://www.dattalo.com/technical/software/pic/debounce.html
a couple of years ago and have used it ever since:
It is an algorithm for debouncing all the inputs on a port
simultaneously. No loops or branches, just inline code. The routine is
expected to be called periodically, as by a timer interrupt.
Although the original code is for the PIC, there is an explanation of
the logic written in C which I repeat here with some small changes for
clarity.
static unsigned // global variables
clock_A, // counter LSB
clock_B, // counter MSB
temp, // temporary location
delta; // temporary variable
debounced_state; // the result you will read
void debounce(unsigned new_sample)
// new_sample read from port once per call
{
delta = new_sample ^ debounced_state; //Find all of the changes
clock_A ^= clock_B; //Increment the counters
clock_B = ~clock_B;
clock_A &= delta; //Reset the counters if no changes
clock_B &= delta; //were detected.
temp = (clock_A | clock_B);
debounced_state = temp;
//debounced_state &= (clock_A | clock_B);
//Preserve the state of those bits that are being filtered
// and simultaneously
//clear the states of those bits that are already filtered.
debounced_state |= (~temp & new_sample)
//debounced_state |= (~(clock_A | clock_B) & new_sample);
//Re-write the bits that are already filtered.
}
All I can say is that whoever originally came up with this little gem
has to be some kind of genius.
--
erikc2005-06-11 by wbounce
Thanks for the reply. As far as pinging all sonars I did that my other bot with 5 sonars with no problem. Then I would read them one after the other with no problem. I had to do that because the I2C bus was inaccessible during the ping. The sonar docs says "the SRF08 will not respond to any I2C activity whilst ranging. Therefore if you try to read from the SRF08 you will get 355 while ranging because the I2C data line is pulled high if nothing is driving it. And as soon as the ranging the SRF08 will respond." I tried to fire them 1 after another and the 1st one would ping correctly but then the rest would return invalid address. Therefore I could not have done your ping sensor1 and read sensor3. I have decided to 1st find out if the compass will work by itself with nothing else ie no motor, sonars, gps, or wheel encoders. Just read the compass and display the value. If that works I will add each piece back in. If that doesn't then the compass is bad.
-----Original Message-----
From: AVR-Chat@yahoogroups.com [mailto:AVR-Chat@yahoogroups.com] On
Behalf Of arhodes19044
Sent: Thursday, June 09, 2005 4:15 PM
To: AVR-Chat@yahoogroups.com
Subject: [AVR-Chat] Re: I2C devantech cmp03 problems.
I have not checked your code yet, but.....
Pinging all 3 sonars at the same time? It sounds (pun intended) to
me as if interference will occur between sensors.
If you are not running the sensors at max firing frequency, then it
probably would be best to:
ping Sensor-1
read Sensor-3
after 70 ms from #1, Ping Sensor-2
read Sensor-1
after 70ms from #2, Ping Sensor-3
read Sensor-2
after 70ms from #3, repeat from the top....
you can add a compass reading in there somewhere.
-Tony
--- In AVR-Chat@yahoogroups.com, "wbounce" <wbounce@s...> wrote:
> I am trying to diagnose a problem I am having with the devantech
> compass. I have 3 SRF08 sonars and a cmp03 compass connected to my
> MavricII board (M128). Using winavr 3.4.1. I am using a set I2C
routines
> from Brian Dean's sample programs. I use the same routines to ping
the
> sonar as I do to read the compass so I am fairly certain they are
not
> the problem. Because I am pinging all 3 sonars at once, I moved my
> reading of the compass to before I do the ping and after I have
read the
> ranges. I list the compass reading routines bearing16 calls
> cmps03_get_word. The ErrorState is consistently being set to -30
which
> means a failed start condition. Yet as soon as it returned from
> bearing16 it calls the sonar ping which calls the same call but it
> succeeds. I have checked the connects to the compass. But after
ooking
> at the code writing this email up it has to be something other than
> that. First 1st thought was bad connection which is usually the
problem
> when one of the sonars stop working but at least with a sonar it
has a
> led that flashes when it pings so I can tell it is working. How
can I
> tell the compass is working? And is there anything in this code
that
> would cause the I2c to fail?
>
>
> tempbearing = bearing16();
> if ( tempbearing > -1)
> {
> CurrentBearing = tempbearing;
> }
> else
> {
> ErrorState = (int8_t)tempbearing;
> printf_P(PSTR("CError %i"),ErrorState);
> }
>
> printf_P(PSTR("pg "));
> srf08_ping(ALLDEVICES, RANGE_US); /* initiate a ping,
distance
> in cm */
>
>
> int16_t bearing16(void)
> {
> uint16_t d;
> int8_t rc;
> printf_P(PSTR("Be "));
> rc = cmps03_get_word(0x60, 2, &d);
> if (rc < 0) {
> ErrorState = rc;
> return (int16_t )rc;
> }
>
> return d;
> }
>
> int8_t cmps03_get_word(uint8_t device, uint8_t addr, uint16_t *
value)
> {
> uint8_t v1, v2;
>
> /* start condition */
> if (i2c_start(0x08, 0))
> return -30;
>
> /* address slave device, write */
> if (i2c_sla_rw(device, 0, TW_MT_SLA_ACK, 0))
> return -31;
>
> /* write register address */
> if (i2c_data_tx(addr, TW_MT_DATA_ACK, 0))
> return -32;
>
> /* repeated start condition */
> if (i2c_start(0x10, 0))
> return -33;
>
> /* address slave device, read */
> if (i2c_sla_rw(device, 1, TW_MR_SLA_ACK, 0))
> return -34;
>
> /* read data byte 1 */
> if (i2c_data_rx(&v1, I2C_ACK, TW_MR_DATA_ACK, 0))
> return -35;
>
> /* read data byte 2 */
> if (i2c_data_rx(&v2, I2C_NACK, TW_MR_DATA_NACK, 0))
> return -36;
>
> if (i2c_stop())
> return -37;
>
> *value = (v1 << 8) | v2 ;
>
> return 0;
> }
>
>
> int8_t srf08_ping(uint8_t device, uint8_t cmd)
> {
> /* start condition */
> if (i2c_start(0x08, 0))
> return -1;
>
> /* address slave device, write */
> if (i2c_sla_rw(device, 0, TW_MT_SLA_ACK, 0))
> return -2;
>
> /* write address */
> if (i2c_data_tx(0x00, TW_MT_DATA_ACK, 0))
> return -3;
>
> /* write command */
> if (i2c_data_tx(cmd, TW_MT_DATA_ACK, 0))
> return -4;
>
> if (i2c_stop())
> return -5;
>
> return 0;
> }
Yahoo! Groups Links2005-06-11 by wbounce
The compass checks out ok. It works fine alone. As soon as I let it run through the ping and range code the compass code throws errors. Need to check each part (ping and read the range) separately to see which is causing the problem. But that will have to be tomorrow. I am getting bleary eyed.
-----Original Message-----
From: AVR-Chat@yahoogroups.com [mailto:AVR-Chat@yahoogroups.com] On
Behalf Of wbounce
Sent: Friday, June 10, 2005 11:32 PM
To: AVR-Chat@yahoogroups.com
Subject: RE: [AVR-Chat] Re: I2C devantech cmp03 problems.
Thanks for the reply.
As far as pinging all sonars I did that my other bot with 5 sonars with
no problem. Then I would read them one after the other with no problem.
I had to do that because the I2C bus was inaccessible during the ping.
The sonar docs says
"the SRF08 will not respond to any I2C activity whilst ranging.
Therefore if you try to read from the SRF08 you will get 355 while
ranging because the I2C data line is pulled high if nothing is driving
it. And as soon as the ranging the SRF08 will respond."
I tried to fire them 1 after another and the 1st one would ping
correctly but then the rest would return invalid address.
Therefore I could not have done your ping sensor1 and read sensor3.
I have decided to 1st find out if the compass will work by itself with
nothing else ie no motor, sonars, gps, or wheel encoders. Just read the
compass and display the value. If that works I will add each piece back
in. If that doesn't then the compass is bad.
-----Original Message-----
From: AVR-Chat@yahoogroups.com [mailto:AVR-Chat@yahoogroups.com] On
Behalf Of arhodes19044
Sent: Thursday, June 09, 2005 4:15 PM
To: AVR-Chat@yahoogroups.com
Subject: [AVR-Chat] Re: I2C devantech cmp03 problems.
I have not checked your code yet, but.....
Pinging all 3 sonars at the same time? It sounds (pun intended) to
me as if interference will occur between sensors.
If you are not running the sensors at max firing frequency, then it
probably would be best to:
ping Sensor-1
read Sensor-3
after 70 ms from #1, Ping Sensor-2
read Sensor-1
after 70ms from #2, Ping Sensor-3
read Sensor-2
after 70ms from #3, repeat from the top....
you can add a compass reading in there somewhere.
-Tony
--- In AVR-Chat@yahoogroups.com, "wbounce" <wbounce@s...> wrote:
> I am trying to diagnose a problem I am having with the devantech
> compass. I have 3 SRF08 sonars and a cmp03 compass connected to my
> MavricII board (M128). Using winavr 3.4.1. I am using a set I2C
routines
> from Brian Dean's sample programs. I use the same routines to ping
the
> sonar as I do to read the compass so I am fairly certain they are
not
> the problem. Because I am pinging all 3 sonars at once, I moved my
> reading of the compass to before I do the ping and after I have
read the
> ranges. I list the compass reading routines bearing16 calls
> cmps03_get_word. The ErrorState is consistently being set to -30
which
> means a failed start condition. Yet as soon as it returned from
> bearing16 it calls the sonar ping which calls the same call but it
> succeeds. I have checked the connects to the compass. But after
ooking
> at the code writing this email up it has to be something other than
> that. First 1st thought was bad connection which is usually the
problem
> when one of the sonars stop working but at least with a sonar it
has a
> led that flashes when it pings so I can tell it is working. How
can I
> tell the compass is working? And is there anything in this code
that
> would cause the I2c to fail?
>
>
> tempbearing = bearing16();
> if ( tempbearing > -1)
> {
> CurrentBearing = tempbearing;
> }
> else
> {
> ErrorState = (int8_t)tempbearing;
> printf_P(PSTR("CError %i"),ErrorState);
> }
>
> printf_P(PSTR("pg "));
> srf08_ping(ALLDEVICES, RANGE_US); /* initiate a ping,
distance
> in cm */
>
>
> int16_t bearing16(void)
> {
> uint16_t d;
> int8_t rc;
> printf_P(PSTR("Be "));
> rc = cmps03_get_word(0x60, 2, &d);
> if (rc < 0) {
> ErrorState = rc;
> return (int16_t )rc;
> }
>
> return d;
> }
>
> int8_t cmps03_get_word(uint8_t device, uint8_t addr, uint16_t *
value)
> {
> uint8_t v1, v2;
>
> /* start condition */
> if (i2c_start(0x08, 0))
> return -30;
>
> /* address slave device, write */
> if (i2c_sla_rw(device, 0, TW_MT_SLA_ACK, 0))
> return -31;
>
> /* write register address */
> if (i2c_data_tx(addr, TW_MT_DATA_ACK, 0))
> return -32;
>
> /* repeated start condition */
> if (i2c_start(0x10, 0))
> return -33;
>
> /* address slave device, read */
> if (i2c_sla_rw(device, 1, TW_MR_SLA_ACK, 0))
> return -34;
>
> /* read data byte 1 */
> if (i2c_data_rx(&v1, I2C_ACK, TW_MR_DATA_ACK, 0))
> return -35;
>
> /* read data byte 2 */
> if (i2c_data_rx(&v2, I2C_NACK, TW_MR_DATA_NACK, 0))
> return -36;
>
> if (i2c_stop())
> return -37;
>
> *value = (v1 << 8) | v2 ;
>
> return 0;
> }
>
>
> int8_t srf08_ping(uint8_t device, uint8_t cmd)
> {
> /* start condition */
> if (i2c_start(0x08, 0))
> return -1;
>
> /* address slave device, write */
> if (i2c_sla_rw(device, 0, TW_MT_SLA_ACK, 0))
> return -2;
>
> /* write address */
> if (i2c_data_tx(0x00, TW_MT_DATA_ACK, 0))
> return -3;
>
> /* write command */
> if (i2c_data_tx(cmd, TW_MT_DATA_ACK, 0))
> return -4;
>
> if (i2c_stop())
> return -5;
>
> return 0;
> }
Yahoo! Groups Links
Yahoo! Groups Links2005-06-16 by Dave VanHorn
At 08:37 AM 6/8/2005, Dave VanHorn wrote: >Then we have an even shorter variant possible: > > > > >REVERSE: > > LDI R31,TABLE_LOC > > MOV R30,TEMP > > LPM TEMP Guess what... Isn't it obvious that this DOES NOT WORK? Z needs to be loaded with the address *2, so we actually end up with: mov ZL,TEMP ldi ZH,high(table) lsl ZL rol ZH lpm TEMP And this does not take into account that the table might be located high enough to require the ELPM instruction! So can the real answer be simplified?
2005-06-16 by Paul Maddox
Dave, >> >REVERSE: >> > LDI R31,TABLE_LOC >> > MOV R30,TEMP >> > LPM TEMP > > Guess what... > > Isn't it obvious that this DOES NOT WORK? It works in my code and as I said in the mail... the table needs to be on a page boundry and that TABLE_LOC should be double the value of its location. Assuming the table doesn't move, we don't need to claculate it each time, and assumign speed was an issue and memory was no object (as originally stated) then the table could be placed on a page boundry. for example if the table is at 0x0200, use .EQU TABLE_LOC = $04 Paul
2005-06-16 by Dave VanHorn
At 03:20 AM 6/16/2005, Paul Maddox wrote: >Dave, > > >> >REVERSE: > >> > LDI R31,TABLE_LOC > >> > MOV R30,TEMP > >> > LPM TEMP > > > > Guess what... > > > > Isn't it obvious that this DOES NOT WORK? > >It works in my code and as I said in the mail... >the table needs to be on a page boundry and that TABLE_LOC should be double >the value of its location. >Assuming the table doesn't move, we don't need to claculate it each time, >and assumign speed was an issue and memory was no object (as originally >stated) then the table could be placed on a page boundry. >for example if the table is at 0x0200, use .EQU TABLE_LOC = $04 Fine, so ldi R31,high(Table_Loc*2) as above, but what about the low byte? If the low byte has the MSB set on entry, then that needs to get into the LSB of the high byte, no? Worse, if you're in a M128 and putting the table near the end of the code space, because the MSB of the high byte needs to be put in bit 0 of the RAMPZ register for the ELPM instruction.
2005-06-16 by Paul Maddox
Dave, > Fine, so ldi R31,high(Table_Loc*2) as above, but what about the low byte? > If the low byte has the MSB set on entry, then that needs to get into > the LSB of the high byte, no? Not for me, at least not on the MEGA32 I'm running it on. It seems to run fine > Worse, if you're in a M128 and putting the table near the end of the > code space, because the MSB of the high byte needs to be put in bit 0 > of the RAMPZ register for the ELPM instruction. yeah, fair point, but as most of the AVRs don't have 128K of memory it shouldn't be an issue. Paul
2005-06-16 by Dave VanHorn
At 09:37 AM 6/16/2005, Paul Maddox wrote: >Dave, > > > Fine, so ldi R31,high(Table_Loc*2) as above, but what about the low byte? > > If the low byte has the MSB set on entry, then that needs to get into > > the LSB of the high byte, no? > >Not for me, at least not on the MEGA32 I'm running it on. >It seems to run fine Thinking about that again, I understand why it works now, the high byte needs to position the table on the low page, IOW XXXXXXXX0 Then we get a 256 byte table from XX00 to XXFF, where XX is XXXXXXX0 in binary. I was thinking that it was a 256 WORD table, which it isn't. >yeah, fair point, but as most of the AVRs don't have 128K of memory it >shouldn't be an issue. So, the added proviso that it has to reside in the bottom 64k to work with the simple instruction set. If not, and you try to make it freely relocatable, you end up with a lot more cycles.
2005-06-16 by Paul Maddox
Dave, > I was thinking that it was a 256 WORD table, which it isn't. ahh, fair point then. > So, the added proviso that it has to reside in the bottom 64k to work > with the simple instruction set. well, the dvice wasn't stated.. given the fact that the preffered soloution was some hard wired soloution, also implies that the device wasn't already soldered into a PCB and insdie an existing product. > If not, and you try to make it freely relocatable, you end up with a > lot more cycles. as I say, code space wasn't an issue, in which case, all I'd say is that the table *MUST* reside in the lower 64K :-) Perhaps a good example of why poorly defined problems lead to confusing results :-) Paul
2005-06-16 by Dave VanHorn
At 09:59 AM 6/16/2005, Paul Maddox wrote: >Dave, > > > I was thinking that it was a 256 WORD table, which it isn't. > >ahh, fair point then. > > > So, the added proviso that it has to reside in the bottom 64k to work > > with the simple instruction set. > >well, the dvice wasn't stated.. >given the fact that the preffered soloution was some hard wired soloution, >also implies that the device wasn't already soldered into a PCB and insdie >an existing product. I wouldn't say that was the preferred solution, but just the fastest one. >Perhaps a good example of why poorly defined problems lead to >confusing results :-) Well, we just need to understand the limitations and compromises of these tricky approaches to problems.