Make the hardware I2C port available same as HSERIN / HSEROUT.
Printable View
Make the hardware I2C port available same as HSERIN / HSEROUT.
Explain a bit more...doesn't make a lot of sense...Quote:
Originally Posted by garryp4
We are in the PBP wish list section... ;)
garryp4 want to have new statements (HI2CREAD/WRITE) that use the Hardware MSSP module instead of using I2CREAD/WRITE. Something like SERIN/HSERIN PWM/HPWM
Huh...missed that entirely...Quote:
Originally Posted by mister_e
Yes, I2C/HI2C...good idea...
I was a bit dissapointed to find out that the I2C speed with the I2CREAD/WRITE commands are much slower that what the offered hardware is capable of. To get to this speed requires the use of writing some ASM code, which why we use PBP in the first place. I could really use this speed. The PIC supports it but PBP don't. However, I have found what PBP does support to be easy and work the first time every time.
The software commands are fairly fast...but I don't know what you are considering to be fast. At 40mhz, I can generally erase a 32k eeprom byte-by-byte in about 4 seconds or so. No, not fast by any stretch, but as you state, easy to do.Quote:
Originally Posted by garryp4
Please please please implement hardware I2C for devices that support it! The I2CWrtite I'm using is sucking up TONS of code space, is slow as death, and is making me nuts!
Andy
.... oops sorry....
Which device you need to talk to?
Quote:
Originally Posted by mister_e
Quote:
Originally Posted by Andy Baker
What do you think of "@ hi2cwrite / hi2cread" type command?Quote:
Originally Posted by mister_e
Is that even possible? Can't pass many variables that way. They'd have to be preset. You'd have to have a number of different versions to handle the different 'item' possibilities...
Unless...you hijacked the original i2cread/i2cwrite commands with a flag set somewhere...hmmmmm
In theory it's possible... on the down side, i'm not sure Microchip always use the same naming convention between all their PICs... not surprised at all if not. But yes ... possible.
Some "HiJack" method? Possible too... 'till now the user will need to manually modify the PBP library :eek:
HI2CREAD and HI2CWRITE? Why stop there? What about ...
SPI Master
SPI Slave
I2C Master
I2C Multi-Master
I2C Slave
If you want to support the SSP modules, you should support the Whole Module.
And both kinds ... SSP/MSSP.
<br>
Yup, i agree, AND for ALL supported PIC in the list. Here comes the fun to check with >500 datasheets ;)
Don't forget the errata sheets that go with each datasheet. :eek:Quote:
Originally Posted by mister_e
Seems to be a lot of SSP issues in the errata.
You'd think they'd have that down by now.
<br>
And once you're done...
Q:Sir... why it's not working on a ABC but works on a XYZ which are pin2pin compatible
A:Which Silicon version do you have, it's working here with x, y, z version
Q:Silicone version? WTF? I use a JDM programmer, Vista, everything is properly wired with "crocodile jumpers"
....
PDS has everything running on Hardware MSSP PBP developers please implement them!!! acting like Motorola "One hit wonder" mongersQuote:
Originally Posted by mister_e
I'm among the group that wants HI2CREAD/HI2WRITE. The WRITE isn't so important, but the HI2CREAD would certainly make an interrupt-driven slave much easier.
I should add that my previous statement assumes that SLAVE modes were added to the HI2CREAD/HI2CWRITE commands.
And to make things easier - why not just concentrate on 18F parts? There isn't much of a cost differential anymore.
ye, i have to asemble mmc/sd card reader--> i2c writer with high bandwith...
this is not posible with soft i2c, there is some intention to use hw_i2c with
pbp (i saw example on the inet (try to google)) but if pbp put keyword like
hserout, this should be best option, on other hand, if some magican like
Darrel Taylor or other good hardcoderz write some how-to or entire macro
for as halfprogramerz, so we can eassy implement hi2c(400Khz or faster) in
our projects...