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 - --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
