How to specify offset into SPI device

[Thomas Doerfler]

Robert,

Robert S. Grimes schrieb:
> Thomas Doerfler wrote:
>> wow, you made a long way :-) Sorry for not answering, you were still on
>> my "TODO" List.
>>   
> No problem - the problem with lists is they tend to grow faster than we 
> can prune them!

Yes, this leaves LOT of stuff over for future generations to dig out 
again :-)

> 
>> The RTEMS I/O system will pack the offset required into the "args"
>> structure passed to the memory driver.
>>
>> So the write call just has to use the elements of arg.
>>   
> Yes, I saw this in the SPI EPROM driver.  But how do I tell the RTEMS 
> I/O system what the offset is?  I added another printk to the fram read 
> and write routines, and I get messages like these:
> 
>   Write 12 bytes to 0
>   Write 13 bytes to 0
> 
> when I ran:
> 
>    write(fd, buffer1, 12);
>    write(fd, buffer2, 13);
> 
> As you might surmise, this indicates that the length information (i.e. 
> 12 and 13 in these examples) makes it into the fram driver, but the 
> offset is always 0.  I'm clearly missing something here...

I guess, that you do not (yet) advance the rwargs->bytes_moved element? 
Without looking at the RTEMS I/O code, I guess that it learns from that 
parameter, how far you have actually written to the file/device.

> I looked at your code, and it's a great improvement!  I only wrote mine 
> because it was almost trivial to adapt the existing driver, and I needed 
> something I could understand to "drive" my SPI driver development.  I 
> will almost certainly end up with yours, though, once you get it into 
> the tree.

Fee free to use it as is now :-)

wkr,
Thomas.

> 
> Thanks again!
> -Bob
>> wkr,
>> Thomas.
>>
>>
>>
>>
>>
>> Robert S. Grimes schrieb:
>> | Okay, I've got most of this figured out.  This code works, in that it
>> | invokes the correct driver calls:
>> |
>> |   int fd = open("/dev/spi.fram", O_RDWR);
>> |   printf("open returned %d\n", fd);
>> |   if (fd >= 0) {
>> |     char buffer[32];
>> |     char rbuffer[32];
>> |
>> |     strcpy(buffer,  "Hello world");
>> |     strcpy(rbuffer, "Uh, oh.....");
>> |     printf("ioctl returned %d\n", ioctl(fd, SEEK_SET, 0x200));
>> |     printf("write returned %d\n", write(fd, buffer, 4));
>> |     printf("ioctl returned %d\n", ioctl(fd, SEEK_SET, 0x200));
>> |     printf("read returned %d\n", read(fd, rbuffer, 4));
>> |     printf("rbuffer = [%s]\n", rbuffer);
>> |     close(fd);
>> |   }
>> |
>> | This gives the following output:
>> |
>> |   open returned 4
>> |   ioctl returned -1
>> |     fram write
>> |     bsp_spi_send_start_dummy: Implement me!
>> |     bsp_spi_sel_addr: Implement me!
>> |     bsp_spi_send_stop: Implement me!
>> |     bsp_spi_send_start_dummy: Implement me!
>> |     bsp_spi_sel_addr: Implement me!
>> |     bsp_spi_send_stop: Implement me!
>> |   write returned 4
>> |   ioctl returned -1
>> |     fram read
>> |     bsp_spi_send_start_dummy: Implement me!
>> |     bsp_spi_sel_addr: Implement me!
>> |     bsp_spi_send_stop: Implement me!
>> |   read returned 0
>> |   rbuffer = [Uh, oh.....]
>> |
>> | The lines starting with "fram" or "bsp_spi_XXX" are debugging outputs
>> | from the drivers I'm working on.  So, everything is set up to actually
>> | access the device!  Yes!
>> |
>> | The next question is this: how do I specify the offset into the FRAM?  I
>> | guessed it's in an ioctl call, as suggested in libi2c.h, but as you can
>> | see, that doesn't work.  Stepping through, it seems ioctl is not
>> | implemented for the libi2c driver.
>> |
>> | So, I do I specify the offset into the FRAM device???
>> |
>> | Thanks,
>> | -Bob
>>   
> 
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.com
> http://rtems.rtems.org/mailman/listinfo/rtems-users


-- 
--------------------------------------------
embedded brains GmbH
Thomas Doerfler           Obere Lagerstr. 30
D-82178 Puchheim          Germany
Tel. : +49-89-18 90 80 79-2
Fax  : +49-89-18 90 80 79-9
email: Thomas.Doerfler at embedded-brains.de
PGP public key available on request

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.