Interest in Building an Assembly SPI Driver for the SCL3300

Hello, I am wondering if anyone is interested in building an assembly SPI driver for the SCL 3300 accelerometer to interface with the propeller 1. It is full duplex and I haven't been able to find anything on the forums or the OBEX where someone has implemented a full duplex SPI interface in assembly. If someone has some code or knows of an object already on the obex they think I could modify to work I would love to be pointed in the proper direction. I am currently using my own SPIN SPI driver, but it is very slow 19.2KHz, the datasheet states that the chip prefers 2-4MHZ for lowest noise, which from what I understand should be achievable using assembly. It would be great to get my reading speed up.

If there is not anything publicly available, I would be glad to pay someone to do it as my assembly level programming skills are very poor to nonexistent.

Thanks,

Jonathan

Comments

  • Why don't you post your Spin driver for others to look at and possibly convert? Like you, I have done full-duplex SPI with Spin, but not with assembly. Still, without using clock tricks that some have employed, it may not be very difficult, especially if it didn't require operating in all SPI modes.
  • localrogerlocalroger Posts: 3,362
    edited 2020-02-17 - 19:18:46
    The ENC28J60 ethernet driver uses a PASM SPI engine. I recently converted it to Spin for the P2, which is almost as fast in FastSpin as PASM in the P1. Editing to attach the file.driver_enc28j60_UDP.spin
  • You could compile your SpinSPI driver with fastspin for P1 and look at the created assembly file.

    Mike
  • Peter JakackiPeter Jakacki Posts: 8,980
    edited 2020-02-17 - 23:54:58
    That device maxs out at 8MHz and doesn't need full duplex SPI (although you can) and it is very rare that any device does. I use simple bitbash routines in Tachyon for optimised read or write that run over 4MHz although the block routines run at sysclk/2.

    Why does SPI have to be reinvented every time for every device? Surely just one for reading a byte and one for writing, and then some block routines. My write routines also support 16/24/32 bit write as well and any access always asserts the chip select automatically.

    All my code uses these basic routines, even the SD card and for me bolting in a new device is a piece of cake.
  • Thank you everybody for your input and advice!
    I am now currently working with someone on this.
    You all have some excellent suggestions, and I appreciate the help.

Sign In or Register to comment.