Ned Konz wrote:
>
> Hi folks,
>
> I'm a new user of the wonderful Inline modules. I've shied away from XS and
> SWIG in the past after some frustration with each, but am happy to say that I
> got my first Inline-using module together in two hours!
Wow. The world-famous Ned Konz is using little old Inline! I'm honored.
Were not you the same guy who rode all over the place with lots of
computing devices attatched to your recumbant steed? Nice to meet you.
I can't actually say I've followed your story as a fanatic, but there is
a relation. I raced rode bikes as a CAT2 in the Seattle area for the
last 6 years. I've done many a six hour training in the Stanwood area.
(I'm now in retirement, rolling in all the cash that us CPAN authors
rake in.) Do you happen to know local crazy people like Dan Woods or
Glen Bunselmeyer? Guys that, like you I assume, get into riding 600K at
a go.
> Great documentation, great module!
Thank you.
> A newbie question:
>
> I have a couple of functions that I'm calling that are defined (in
> linux/i2c-dev.h) as (bodies elided):
>
> extern inline __s32 i2c_smbus_read_block_data(int file, __u8 command, __u8
> *values) { ... }
> extern inline __s32 i2c_smbus_write_block_data(int file, __u8 command, __u8
> length, __u8 *values) { ... }
>
> These eventually call an ioctl() call which does a synchronous SMBus transfer
> and returns a success code.
>
> I set CCFLAGS to -O2 so that the inlined functions will work right. This is
> working fine for other, simpler functions.
>
> But I'm not sure about how to handle returning a character string. The above
> routines return -1 on error. read_block_data returns the number of bytes read
> if successful.
>
> What I was hoping to do in _readBlockData is to use the "output" argument as
> a data buffer in which to write data (like the buffer argument to sysread()
> for instance).
>
I'm right in the middle of trying to resolve the remaining issues for
getting the uber-release 0.40 out to CPAN, otherwise I'd cook you up
some examples. But that's why I wrote the Inline::C-Cookbook; so you
could help yourself. I'll try to comment here:
> I tried this, but I don't know if it's right (the call won't return more than
> 32 characters):
>
> int _readBlockData(int file, int command, SV* output)
> {
> char buf[ 32 ];
> int retval = i2c_smbus_read_block_data(file, command, buf);
> if (retval == -1)
> return retval;
> sv_setpvn(output, buf, retval); /* retval is # of bytes read */
> return retval;
> }
I usually discourage the modification of input parameters in favor of
returning multiple values on the Perl stack. But I have a question for
you. "Does it work?" If so, it seems reasonable. If not, it may be
getting messed up by the transparent typemapping. Sorry to be
wishywashy, but I'm just strapped for time right now.
If it works, I'll probably add it as an example in the Cookbook, with
credit to you of course.
> And then I'm doing this on the write side:
>
> int _writeBlockData(int file, int command, SV* value)
> {
> STRLEN len;
> char *buf = SvPV(value, len);
> return i2c_smbus_write_block_data(file, command, len, buf);
> }
>
> Do these look like the right way to do the job?
Again, seems reasonable if it works.
Cheers, Brian
PS I noticed you said that you are writing a *module* with Inline.
You'll be very interested in the changes being rolled out with 0.40. If
you're brand new to the mailing list, you may wish to review the last 10
days correspondence in the archives:
http://www.mail-archive.com/[email protected]/
PPS If you ever ride up to Vancouver BC, I'd be glad to buy you a
beverage of your choice :)
--
perl -le 'use Inline C=>q{SV*JAxH(char*x){return newSVpvf
("Just Another %s Hacker",x);}};print JAxH+Perl'
