I2C and SPI on the P2

iseries

I have several devices that do not work on the P2 that work just fine on the P1.

For example the DS1302 works fine on the P1 and not on the P2.

I have the BME680 that works fine on the P1 and not on the P2.

The problem is that these devices were not designed to work at the P2 speeds and the drivers were not designed to allow for them. Face it the P1could not go fast enough.

I think now we need new drivers that address the speed issue.

The I2C spec shows there are 4 different clock speed available, 100kb/s, 400kb/s, 1mb/s, and 3.4mb/s. SPI does not show a speed but there are limits.

So we need drivers that will allow for different speeds as an input option. In the case of SPI maybe a divider value to allow for lower clock speeds.

Mike

Ariba

Is it not obvious that you need I2C and SPI drivers made for P2, if you use a P2?

There are already drivers for such protocols in the Github-Obex, mainly made by JonnyMac:
https://github.com/parallaxinc/propeller/tree/master/libraries/community/p2/Protocol

As you see they let you define the clock speed as a parameter of the start methode.

VonSzarvas

ModEdit: Thread title improved for search friendliness and positivity.

Wuerfel_21

You get the exact same problem running old Spin drivers through flexspin on P1 - old code is written with the inherent slowness of Spin1 in mind. The shortest wait possible in Spin1 IIRC is "waitcnt(381+cnt)", so it is somewhat of a necessity to do it that way.

Peter Jakacki

Last I checked I2C and SPI work splendidly on the P2. If something doesn't work it is not a matter of hardware, but that of software.

I've noticed too much of this "porting" from P1 to P2 but the P2 does things differently. We never had the problem with the P1 because we just wrote software to suit the P1. None of this porting nonsense. Same goes for the P2.

EDIT: just checked the DS1302 datasheet and boy is it a slow device for the SPI bus. It specifies 2MHZ max on the SPI bus. You can bit-bash in Spin and you might still have to add a delay.

My I2C drivers can be set to different bus speeds to suit and I scan at 100kHz to catch any slow old devices, work with most at 400kHz, and talk to my UB3 micro at up to 3MHz or more.
Here's part of my boot report that scans the hardware.

HARDWARE
  PCB           P2      (P2D2)
  CLOCK IN      20.000000MHZ
DEVICES 
  SD CARD       63 GB  SANDISK   SD SC64G REV$80 #35190404 DATE:2018/10
  SPI FLASH     16MB WINBOND $EF40_1800 #4837448895114529879
  USB           Silicon Labs EFM8UB3 uPORT SERIAL WATCHDOG UB3_2.5.8B 0005
I2C DEVICES
  $36           P2D2 UB USB+SUPPORT  UUID:669BAD5834DEE811A8D742B1A51F80DA
  $A4           RV-3028 RTC  2021/01/21 WED 22:29:31
  $C4           Si5351A CLOCK GEN
STATS           1 RESETS  Temp= 38.94'C   Vdd=1.826V
-------------------------------------------------------------------------------
TAQOZ# .CLK --- 340MHz ok

JonnyMac

So we need drivers that will allow for different speeds as an input option. In the case of SPI maybe a divider value to allow for lower clock speeds.

Like Peter, I've written I2C and SPI drivers for the P2 that both allow the app to set the bus speed. Mine drivers use Inline PASM2 (for precision) wrapped in Spin2 methods.

dgately

There's an update of the P1 DS1302_FULL driver to P2, on the propeller github repository (not actually an I2C device, though?):

https://github.com/parallaxinc/propeller/tree/master/libraries/community/p2/All/DS1302_full

dgately