Hello i seem to cant find an SPI library for LPS25HB and LSM6DS33. the common ons are i2c which is kind of weird that nobody made an SPI library of it yet
Any one know a link ?
Google on "LPS25HB" gives this:
Google on "LSM6DS33" gives this:
Where did You search?
Those libraries are i2c
i did find one results in your link that didnt show up in mine. LSM6DS33 from sparksfun
I know the principles of I2C since ages. It was created 40 years ago. SPI I don't know. What's the advantage using SPI and not I2C? A question from an SPI novice.
Wow i had to google that one, it would seem that SPI was also developed in the mid 80's.
well speaking from only what i know also. they both have their own advantages. For me the most important is speed, although i2c today have speed in MHZ but is really finicky to design that will work in that speed. SPI on the other hand can almost all handle speeds in MHZ range. For example the LSMds33 has a max of 10Mhz in SPI and 400kHz max on i2c.
As if you really need that speed (since several chips cant update their data that fast anyway, but its not uncommon that a chip can too) is up to you.
An advantage for i2c is you can basically put as very many devices on the bus given that you bus capacitance is within spec and your address register wont fill up. as for SPI you are burning a pin per spi device.
Really depends what the user needs,SDcards are run on SPI because it needs that speed. They are both good on their own right, only make sense they both stood well the test of time.
Thanks for the lesson. SPI calls for 3 I/O pins, if I'm right and I2C for 2.
Next question is; Does the controller manage to eat data at the SPI speed?
If not, the available speed will not be any good.
Using a Raspberry, You can eat data. Using an UNO.... not that much.
What's the main target for the proj?
I am using a due which run at 84 MHz (says Arduino). so yeah the microcontroller can eat the data of most SPI devices. Not as fast compared to Raspberry pi, but definitely better than an uno.
I was thinking of not using these devices because they are only an added feature, but since the the pads are already there might as well give it a shot.
Okey. You can read the data at high speed. What Do You intend to do with that data? Does the "output", receiver, swallow data at that speed? Else memory might get flooded….
The data will be used for computational reasons and for double checking, there is not really an output. But what i had in mind when i designed is, my usecase involves several interrupts ( 8 - 10) and what usually happens as far as i know how any timing related protocols are implemented is they disable interrupts during the data exchange process. My code tolerates a few misses here and there, but when it becomes several it kinda starts to affect the output a little. so i would like any transaction to be done as quickly as possible. What i was looking at is how quickly can i get the data rather than how many data i can get.
Well that was in theory, i still have no idea how it will perform in actual. I am still in the stage of gathering/creating the libraries needed for the whole thing to work
Your info about "interrupts" tells me nothing, only confuse me. Why 8 - 10 interrupts? Doing what? Needed for what reson?
You need to controll the amount of data handled by Your controller. Go for maximum throughput of 25% load of the controller, as a target. Then monitour the reality and see if You can push more data through.
It doesn't matter what Your data is used to, or used for. Is the data rate really needed? Driving fast is fun but not always neccesary.