Matt, I suspect that in order to insure that the SPI switch mode actually works reliably, you will need a complete 'init' anyway, so let's not write a new function. We'd have to check the errata for several different chips, etc.
I put the 'aliasing' stuff at the very top of the file, because I hope that it will be temporary -- and we can remove it when the aliasing gets done in the chip files. I put the constants just in front of the function, in hopes they would be noticed. I guess I need to re-think that... If you don't mind, send me your proposed changes, and I'll do the svn commits, OK? William On Sep 3, 10:19 pm, mattschinkel <[email protected]> wrote: > Ah, now I see the constants you added, this helps. Can we put them at > the top of the file so we can see them? > > Should we add a spi_mode_switch procedure like this? > > procedure spi_mode_switch(byte in spi_mode) is > if spi_mode == SPI_MODE_00 then > SSPCON_CKP = 0 > SSPSTAT_CKE = 1 > elsif spi_mode == SPI_MODE_01 then > SSPCON_CKP = 0 > SSPSTAT_CKE = 0 > elsif spi_mode == SPI_MODE_10 then > SSPCON_CKP = 1 > SSPSTAT_CKE = 1 > else > SSPCON_CKP = 1 > SSPSTAT_CKE = 0 > end if > end procedure > > yes, I could just use the spi_init procedure to do the same, but this > way my code looks cleaner and I am not setting these vars again for no > reason: > SSPCON = 0 > SSPSTAT_SMP = 0 > SSPCON_SSPM = spi_rate > SSPCON_SSPEN = 1 > > SPI is ment to be used with multiple devices on the same bus by using > a chip select pin, but some devices will use different spi modes. The > circuit I am planning to build may use up to 3 devices via spi. > > It seems that there are a lot of high data rate applications for spi > > may I modify it myself and add some usage notes as well? > > Matt. > > On Sep 3, 7:16 am, William <[email protected]> wrote: > > > > > Matt, > > > Thanks for testing! But did you notice the 'nice' constants I added > > for use in calling the function, like SPI_MODE_00 ? > > > William > > > On Sep 3, 8:07 am, mattschinkel <[email protected]> wrote: > > > > Thanks william, I have tested mode 1,1 on 16f877,16f877a,18f452 and it > > > works great. Good work! > > > > spi_init(0b11,1) -- mode 1,1, clock = Fosc/16 > > > > I was able to test rates fosc/16 & fosc /64, the others do not work, > > > they may be to fast for my breadboard > > > > I think the note: "-- TODO: only tested in Master mode 00" can be > > > removed > > > > and some other notes could be added, such as: > > > > small explanation of the modes. sample edge, etc. to make it easy for > > > new users of this lib. > > > explanation of the rates > > > > I can make something up if you like. > > > > later on, I may like a spi_mode_switch() procedure, as I may have more > > > then one device connected to the pic's spi port using different modes. > > > > Matt. > > > > On Sep 2, 8:24 pm, William <[email protected]> wrote: > > > > > Matt, > > > > > Please note the updated spi library, and please test on your hardware > > > > and report back your results. I hope this will be a good fit for you. > > > > > Thank you to the i2c folks for providing a scheme to handle the 18F > > > > parts. > > > > > William > > > > > On Sep 2, 5:05 pm, mattschinkel <[email protected]> wrote: > > > > > > lets just stick to something simple for now to have a decent (maybe > > > > > not perfect) lib > > > > > > if target_cpu == PIC_14 then... > > > > > > On Sep 2, 11:15 am, William <[email protected]> wrote: > > > > > > > Hi Rob, > > > > > > > If I understand what you're saying, you basically agree that the > > > > > > 'right' place for such aliasing is in the 18F device files, to > > > > > > provide > > > > > > a sort of 'legacy' MSSP mode. > > > > > > > I don't think I want to get into such deep waters just yet. I > > > > > > suspect > > > > > > if I procrastinate, you won't be able to resist doing it yourself. > > > > > > :-) > > > > > > > William > > > > > > > On Sep 2, 4:38 am, Rob Hamerling <[email protected]> wrote: > > > > > > > > Hi William, > > > > > > > > William wrote: > > > > > > > > The more I think about it, perhaps the best place to truly > > > > > > > > 'resolve' > > > > > > > > the issues is in the device files themselves -- there is > > > > > > > > already A/D > > > > > > > > stuff and PORT I/O stuff, why not some aliases to help with MSSP > > > > > > > > issues? > > > > > > > > > Time to sleep on that one... > > > > > > > > In my view the aliases for registers as done in some libraries > > > > > > > are sort > > > > > > > of temporary fixes (or 'tricks'). For example in pwm_hardware.jal > > > > > > > the > > > > > > > ECCPxCON registers are aliased as CCPxCON. So Extended CCP > > > > > > > modules are > > > > > > > handled as classic CCP modules and thus those libraries support > > > > > > > only a > > > > > > > subset of the possibilities of the extended CCP modules. That is > > > > > > > fine > > > > > > > for 'simple' PWM work, and good that simple PWM can be used with > > > > > > > extended CCP modules. > > > > > > > However these libs do not support the 'extended' PWM facilities. > > > > > > > Eventually an epwm_hardware library might be needed. > > > > > > > > Now back to MSSP: You'll have to make a design for the > > > > > > > restructuring of > > > > > > > device files w.r.t. the MSSP modules (register names and/or > > > > > > > aliases). > > > > > > > That may cause you headaches, but also bring you everlasting fame! > > > > > > > Looking forward! > > > > > > > > Regards, Rob. > > > > > > > > -- > > > > > > > Rob Hamerling, Vianen, NL (http://www.robh.nl/)-Hidequotedtext- > > > > > > > - Show quoted text -- Hide quoted text - > > > > > - Show quoted text -- Hide quoted text - > > > - Show quoted text - --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "jallib" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/jallib?hl=en -~----------~----~----~----~------~----~------~--~---
