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!
> 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 still did not submit the SPI memory driver, but I have packed it
> together and attached to this mail, maybe it is of some use to you! You
> can either get some info about hte interfacing, or (which should work
> aswell) simply write adapt the modules to you FRAM.
>
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.
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
>