MSSP modules

edmunds

Senior Member
Dear all,

Would it be possible to re-route HSPI pins away from I2C pins on 40X2 via FSRs?

As I understand (and forgive me, if I'm wrong), the underlying pic has two 'independent' synchronous serial port modules that can be routed to 'any' pins. For some reason (probably good firmware reasons) we are limited to one or the other hardware function, because the pins of both interfaces overlap (we are only given access to one of the modules?), but maybe it could be worked around to get both, hspi and hi2c to operate simultaneously. The fact the pins are colliding can be worked around, but the workarounds take so much processor time and additional board space it kind of defeats the purpose. There is shiftout/shiftin, of course, but then I2C is faster in fast mode. Or so I think...


Thank you for your time,

Edmunds
 

inglewoodpete

Senior Member
Dear all,

Would it be possible to re-route HSPI pins away from I2C pins on 40X2 via FSRs?

As I understand (and forgive me, if I'm wrong), the underlying pic has two 'independent' synchronous serial port modules that can be routed to 'any' pins. For some reason (probably good firmware reasons) we are limited to one or the other hardware function, because the pins of both interfaces overlap (we are only given access to one of the modules?), but maybe it could be worked around to get both, hspi and hi2c to operate simultaneously. The fact the pins are colliding can be worked around, but the workarounds take so much processor time and additional board space it kind of defeats the purpose. There is shiftout/shiftin, of course, but then I2C is faster in fast mode. Or so I think...
The 28X2 and 40X2 (or should I say PIC18F25(45)K22) both have two hardware synchronous serial modules. The inputs and outputs cannot be 'steered' as you suggest. It may be possible to enable the second module in the chip by doing some PokeSFRs in the right registers. I've never tried it - when I've needed to do that sort of stuff, I've used the raw PIC and MPLAB "C".

You need to do some serious reading of the PIC18F25/45K22 data sheets. There is a lot of fancy stuff in that there silicon!
 

Goeytex

Senior Member
While the PIC18F45K22 does indeed have 2 MSSP peripherals, the second module is is not available for use in the Picaxe implementation of the chip. Even if you can peek/pokefsr the appropriate registers, you will have to write a support library to use the 2nd module. The performance would be less than optimal.

Peripheral pins cannot be mapped/reassigned on an 18F45K22. The only 18F series of PIC chips that supports Peripheral Pin Select module is the 18FxxK40 series. The PPS module allows most peripheral inputs and outputs to be mapped/assigned to any pin (within certain boundaries).

If you need to use two MSSP modules on a single chip, you will need something other than a Picaxe. Another option might be to to use two 28X2 chips instead of 1 40X2.
 

edmunds

Senior Member
Thank for the answers. This was expected. I hope this goes onto wish list for RevEd from some future versions - being able to use both, HSPI and HI2C interfaces in a single implementation. For now, I will either have to use HI2C for everything or handle the pin switching externally.

Edmunds
 

edmunds

Senior Member

hippy

Technical Support
Staff member
I hope this goes onto wish list for RevEd from some future versions - being able to use both, HSPI and HI2C interfaces in a single implementation.
I think that's already there under 'having commands for every on-chip peripheral'. Whether that happens and to what extent will be a matter to be decided when a new range is introduced.

In general few people need I2C and SPI together and fewer need both to be high-speed. That would require some changes to firmware and testing so, whether it offers a useful feature which is worth the cost, will play a part in deciding if that is catered for. The additional capability would likely only become available for 28 and 40-pin devices so, while not entirely adverse to having different capabilities for different PICAXE chips, that would play a part in decision making.

Utilising the second HI2C channel is probably difficult using PEEKSFR and POKESFR but accessing the second HSPI channel should be fairly easy, and not much slower than the provided HSPI. Initialising, inputting and outputting via the second HSPI channel can be wrapped in macros making it very easy to use in a program which currently needs to do that.

My feeling is that this is likely to be considered enough and any provision of access to the second HSPI channel would merely be turning those macros into commands. There could therefore be new commands but they would not provide for much more than what can already be done today using those macros.
 

edmunds

Senior Member
I take back my feature request after Stuart's response. I don't need it simple to do, I'm happy with there being a way. I fully understand this would add complexity and likely introduce compromises in some other areas and all of this for the benefit of very few users in the education market.

Thanks @hippy,

Edmunds
 

srnet

Senior Member
Although the comparisons I did were for an SPI memory, the same principals should work for any SPI device. The PEEKSFR and POKESFR PICAXE commands are after all the equivalent of what the PIC is doing at the machine code level when it talks to SPI.
 
Top