CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to support@ccsinfo.com

receiving data on pic16F from an accelerometer MPU6050
Goto page Previous  1, 2, 3, 4, 5, 6  Next
 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
AKA TENDO



Joined: 25 Jan 2023
Posts: 47

View user's profile Send private message

PostPosted: Sat Jan 28, 2023 3:55 pm     Reply with quote

temtronic wrote:
Please remember that the delay_ms(2000) does NOTHING with respect to getting the raw sensor data or any 'mathematics' the PIC is asked to do.

You'll probably see that the CCS coding for ATAN is already optimized, same as the other 'trig' functions. You can compare their code to some Microchip Application Notes' on the subject.

As we've stated though to get faster and more accurate response, use scaled integers.

BTW using 3 actuators instead of 4 for the 'level a plank' is easier.


Ttelmah told that there is something in code library about atant functions and it allows to be more optimized. So i want to check and see exatcly what my mathematic functions do.
AKA TENDO



Joined: 25 Jan 2023
Posts: 47

View user's profile Send private message

PostPosted: Sat Jan 28, 2023 4:06 pm     Reply with quote

PrinceNai wrote:
Sorry, I over complicated my previous post. One sensor, two actuators would do. I have a question, since you have to use four actuators: how will you know that the plank sits on all four? With three points there is no other way, but with four...


Yes, i see the problem but i don't really know what will happen, i can't wait to do the tests, honestly im sacred because like you said im wondering if my code will do the job, and if there is some problems i won't have much time to do the corrections.
Ttelmah



Joined: 11 Mar 2010
Posts: 19462

View user's profile Send private message

PostPosted: Sun Jan 29, 2023 8:01 am     Reply with quote

The fast approximations are here:
[url]
http://www.ccsinfo.com/forum/viewtopic.php?t=56264
[/url]

I suspect tinyurl, who got them going, was working with something like
your accelerometer.
temtronic



Joined: 01 Jul 2010
Posts: 9205
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Sun Jan 29, 2023 8:34 am     Reply with quote

One potential problem could be that you're doing 'math' inside the 'read MPU6050' I2C code as posted in the 1st page.

It's not a good idea to do this ,unless you KNOW whatever code you insert can execute faster and NOT affect the I2C transfer of data.
AKA TENDO



Joined: 25 Jan 2023
Posts: 47

View user's profile Send private message

PostPosted: Sun Jan 29, 2023 9:47 am     Reply with quote

Ttelmah wrote:
The fast approximations are here:
[url]
http://www.ccsinfo.com/forum/viewtopic.php?t=56264
[/url]

I suspect tinyurl, who got them going, was working with something like
your accelerometer.


Thank you, i've seen the link , it could helps me i will try a few things tomorrow.
AKA TENDO



Joined: 25 Jan 2023
Posts: 47

View user's profile Send private message

PostPosted: Sun Jan 29, 2023 10:08 am     Reply with quote

temtronic wrote:
One potential problem could be that you're doing 'math' inside the 'read MPU6050' I2C code as posted in the 1st page.

It's not a good idea to do this ,unless you KNOW whatever code you insert can execute faster and NOT affect the I2C transfer of data.


okay but i don't understand what do you mean, where should i do math then?

By the way im currently using the code from PCM Programmer now but anyway, you can talk about my own code it will help me to improve myself because i feel that i am close to the goal with my code as well even if i could do it more properly i guess ^^'
PrinceNai



Joined: 31 Oct 2016
Posts: 471
Location: Montenegro

View user's profile Send private message

PostPosted: Sun Jan 29, 2023 10:40 am     Reply with quote

What he means is that you shouldn't do anything while the transfer is in the progress. You need to read everything you need from the sensor, store it somewhere and than do the math on those stored variables, when you have all the time in the world to do it.
AKA TENDO



Joined: 25 Jan 2023
Posts: 47

View user's profile Send private message

PostPosted: Sun Jan 29, 2023 10:47 am     Reply with quote

PrinceNai wrote:
What he means is that you shouldn't do anything while the transfer is in the progress. You need to read everything you need from the sensor, store it somewhere and than do the math on those stored variables, when you have all the time in the world to do it.


OKAYYYY, this why PCM in his code has separated "read the values", "getting the values" and "do the maths on the values" am i right?

This could solve my problem on my code then.
PrinceNai



Joined: 31 Oct 2016
Posts: 471
Location: Montenegro

View user's profile Send private message

PostPosted: Sun Jan 29, 2023 10:52 am     Reply with quote

That would be nice :-). Yes, that is why.
AKA TENDO



Joined: 25 Jan 2023
Posts: 47

View user's profile Send private message

PostPosted: Sun Jan 29, 2023 11:25 am     Reply with quote

PrinceNai wrote:
That would be nice :-). Yes, that is why.



Ok thank you. I didn't know that, so when we do like i did the PIC doesn't have time to do both things that i ask him to do? Is this the only problem with this way to code?
PrinceNai



Joined: 31 Oct 2016
Posts: 471
Location: Montenegro

View user's profile Send private message

PostPosted: Sun Jan 29, 2023 11:45 am     Reply with quote

As Mr. Temtronic said, it is a potential problem. It might be, but then again it might not. But it is best to avoid even the possibility something can interfere with your transfers. Imagine a situation where you have to receive more than one byte. You get the first one and start doing whatever you do with it. If that operation takes a long time in processor terms, you might lose the second byte, because the third one is already in. You get a huge bonus doing it separately. If the data you receive isn't correct or what was expected, you KNOW it isn't because PIC was doing something else at that moment.
AKA TENDO



Joined: 25 Jan 2023
Posts: 47

View user's profile Send private message

PostPosted: Sun Jan 29, 2023 12:06 pm     Reply with quote

PrinceNai wrote:
As Mr. Temtronic said, it is a potential problem. It might be, but then again it might not. But it is best to avoid even the possibility something can interfere with your transfers. Imagine a situation where you have to receive more than one byte. You get the first one and start doing whatever you do with it. If that operation takes a long time in processor terms, you might lose the second byte, because the third one is already in. You get a huge bonus doing it separately. If the data you receive isn't correct or what was expected, you KNOW it isn't because PIC was doing something else at that moment.


Understood, first i will finish my project and after i will try to correct my code.
But i noticed something since i have the code that is not mine. You can use i2c burst even if you don't use the FIFO Buffer?
temtronic



Joined: 01 Jul 2010
Posts: 9205
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Sun Jan 29, 2023 2:25 pm     Reply with quote

re:
Quote:
You can use i2c burst even if you don't use the FIFO Buffer

in a word ... NO
From the quick read I've done.... I2C burst mode allows the host to access several bytes of the FIFO buffer within the MPU6050.

To do that YOU have to cut code to setup, request and receive the data from the FIFO buffer. Since the FIFO buffer is 1024 bytes and the 877 PIC only has 368, there's no easy way to use this feature.

Can it be done ? YES, but you'll need to use a PIC with at least 2KB of RAM.

Scanning over the MPU6050 specs, it is more than fast enough to level the 'plank' in realtime even if you used RC servos at the 4 corners. You don't even need 'fancy' math (trig functions) to accomplish the task.
AKA TENDO



Joined: 25 Jan 2023
Posts: 47

View user's profile Send private message

PostPosted: Sun Jan 29, 2023 2:59 pm     Reply with quote

temtronic wrote:
re:
Quote:
You can use i2c burst even if you don't use the FIFO Buffer

in a word ... NO
From the quick read I've done.... I2C burst mode allows the host to access several bytes of the FIFO buffer within the MPU6050.

To do that YOU have to cut code to setup, request and receive the data from the FIFO buffer. Since the FIFO buffer is 1024 bytes and the 877 PIC only has 368, there's no easy way to use this feature.

Can it be done ? YES, but you'll need to use a PIC with at least 2KB of RAM.

Scanning over the MPU6050 specs, it is more than fast enough to level the 'plank' in realtime even if you used RC servos at the 4 corners. You don't even need 'fancy' math (trig functions) to accomplish the task.



Okay so it might be my problem then. Because i receive data but sometimed i've got same data value on 2 axes, so you think that my pic isn't fast enough right?

Can i still try to separate my functions as we said in precious posts?
temtronic



Joined: 01 Jul 2010
Posts: 9205
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Sun Jan 29, 2023 3:14 pm     Reply with quote

No, that PIC is more than fast enough ! I ran 3DOF helicopters in realtime over the internet a decade ago,using servos and encoders,so it IS capable of your project.

Please post your current program so we can see what you're doing.
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Goto page Previous  1, 2, 3, 4, 5, 6  Next
Page 4 of 6

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group