Subject:
|
Re: tweaking around dlcd_show( )
|
Newsgroups:
|
lugnet.robotics.rcx.legos
|
Date:
|
Mon, 27 Aug 2001 03:18:35 GMT
|
Viewed:
|
1744 times
|
| |
|
|
In lugnet.robotics.rcx.legos, Martin Scragg writes:
> In lugnet.robotics.rcx.legos, Ross Crawford writes:
> > In lugnet.robotics.rcx.legos, Martin Scragg writes:
> > > In lugnet.robotics.rcx.legos, Alexandre Bec writes:
> > > > I tried to use the "real" value 0xef46,0x4 instead of the define • LCD_4_BOTL
> > > > dlcd_show(0xef46,0x4); and I got obviously the same error.
> > >
> > > This should work, unless the preprocesor has done something funny to it, or
> > > is expected to do something funny to it.
> >
> > Nope - bit_set(0xef46,0x4) will work, but not dlcd_show(0xef46,0x4), as it
> > needs only 1 parameter.
> Since writing this, I have set up a LegOs build environment, so had a play
> with it. It doesn't seem very useful the way it is written. See my bit
> about it below.
I agree it's a bit bodgy. The one advantage is you only need to pass a single
#define when calling it directly (OK not a huge advantage, but if you look at
the values in the #defines, you'll see why it was done that way). But to avoid
the pitfalls of function pointers, I'd probably use a single function, pass it
a single parameter, and have it do a simple switch statement.
> > > > When trying at least to use directly the bit_set function with
> > > > bit_set (0xef46,0x4); it works,
> > > > but if I put these items in an array and invoking bit_set with
> > > > bit_set(progressPattern[ i ][0], progressPattern[ i ][1] );
> > > > I obtain a
> > > > "inconsistent operand constraints in an `asm' " because my array certainly
> > > > does not contain the right type of data for such a low-level operation. • (how
> > > > can we fit a single bit in an array ?)
> > > You would need to define the elements as a structure, and then have an array
> > > of that structure.
> >
> > Choosing the types of the struct elements is the problem - these are passed • to
> > the h8's bset instruction. First, I tried void* & char, but the compiler • didn't
> > like it. Then I tried everything else, and nothing worked. When I get a • chance
> > I'll try & find a h8 guru & see if we can work it out. It may be the • assembler
> > directives (after the ":") but I don't know enough about those.
>
> I had a bit of a go doing this as well, and since I didn't know what the asm
> statement was wanting as paramters, had a hard job convincing it to work.
>
>
>
> In reality, I would rewrite the macros, as they seem a little "dodgy" to me.
> I think that 'dlcd_show' should take the 2 parameters, that way you can use
> it with variables. The way it is now, it can only really be used with the
> defines. Also when I normally write macros, I enclose the parameters passed
> in parentheses. e.g.
>
> do_stuff(a, b) ((a) + (b))
>
> This way you don't end up with problems in the macro if you pass it values
> like this:
>
> do_stuff(5, 7 + 9)
>
> Without the parenteses, this would totaly break the above macro.
Yeah, all the macros should probably be checked for stuff like that.
ROSCO
|
|
Message is in Reply To:
 | | Re: tweaking around dlcd_show( )
|
| (...) Since writing this, I have set up a LegOs build environment, so had a play with it. It doesn't seem very useful the way it is written. See my bit about it below. (...) I had a bit of a go doing this as well, and since I didn't know what the (...) (23 years ago, 27-Aug-01, to lugnet.robotics.rcx.legos)
|
10 Messages in This Thread:
  
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
