| View previous topic :: View next topic |
| Author |
Message |
AKA TENDO
Joined: 25 Jan 2023
Posts: 47
|
|
 Posted: Sat Jan 28, 2023 3:55 pm |
 |
|
| 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
|
|
| Posted: Sat Jan 28, 2023 4:06 pm |
|
|
| 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: 19529
|
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9232
Location: Greensville,Ontario
|
|
| Posted: Sun Jan 29, 2023 8:34 am |
|
|
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
|
|
| Posted: Sun Jan 29, 2023 9:47 am |
|
|
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
|
|
| Posted: Sun Jan 29, 2023 10:08 am |
|
|
| 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: 480
Location: Montenegro
|
|
| Posted: Sun Jan 29, 2023 10:40 am |
|
|
| 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
|
|
| Posted: Sun Jan 29, 2023 10:47 am |
|
|
| 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: 480
Location: Montenegro
|
|
| Posted: Sun Jan 29, 2023 10:52 am |
|
|
| That would be nice :-). Yes, that is why. |
|
|
AKA TENDO
Joined: 25 Jan 2023
Posts: 47
|
|
| Posted: Sun Jan 29, 2023 11:25 am |
|
|
| 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: 480
Location: Montenegro
|
|
| Posted: Sun Jan 29, 2023 11:45 am |
|
|
| 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
|
|
| Posted: Sun Jan 29, 2023 12:06 pm |
|
|
| 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: 9232
Location: Greensville,Ontario
|
|
| Posted: Sun Jan 29, 2023 2:25 pm |
|
|
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
|
|
| Posted: Sun Jan 29, 2023 2:59 pm |
|
|
| 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: 9232
Location: Greensville,Ontario
|
|
| Posted: Sun Jan 29, 2023 3:14 pm |
|
|
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. |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
