New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AP_Notify: Support for OLED display by Alexey Kozin #5135

Closed
wants to merge 3 commits into
base: master
from

Conversation

@dipspb
Contributor

dipspb commented Nov 4, 2016

#5082 (review)

It seems github refused to accept rebased commits that were included in #5082
So I have to create new branch and submit this new PR to provide all commits squashed to a single one with "git rebase -i HEAD~18".

@magicrub

This comment has been minimized.

Show comment
Hide comment
@magicrub

magicrub Nov 4, 2016

Contributor

The github app is junk, I recommend sourcetree. What you need to do is force push after the rebase -i

Contributor

magicrub commented Nov 4, 2016

The github app is junk, I recommend sourcetree. What you need to do is force push after the rebase -i

@dipspb

This comment has been minimized.

Show comment
Hide comment
@dipspb

dipspb Nov 4, 2016

Contributor

@magicrub Thank you, Tom. I didn't mean github app. I mean github site. When I pushed rebased commits to the same branch it doesn't complain anything. But it seems nothing has been changed on side of github repo. It still have all old commits as not rebased. Then I attempted to repeat push with force option and still have no luck. Then I created new branch.

Contributor

dipspb commented Nov 4, 2016

@magicrub Thank you, Tom. I didn't mean github app. I mean github site. When I pushed rebased commits to the same branch it doesn't complain anything. But it seems nothing has been changed on side of github repo. It still have all old commits as not rebased. Then I attempted to repeat push with force option and still have no luck. Then I created new branch.

@dipspb

This comment has been minimized.

Show comment
Hide comment
@dipspb

dipspb Nov 4, 2016

Contributor

Minor fix added as separate commit e289523 into this PR because we have just discovered issue in hardware test and fixed it.

Contributor

dipspb commented Nov 4, 2016

Minor fix added as separate commit e289523 into this PR because we have just discovered issue in hardware test and fixed it.

@magicrub

This comment has been minimized.

Show comment
Hide comment
@magicrub

magicrub Nov 4, 2016

Contributor

@dipspb your changes were in effect on the other PR

Contributor

magicrub commented Nov 4, 2016

@dipspb your changes were in effect on the other PR

@dipspb

This comment has been minimized.

Show comment
Hide comment
@dipspb

dipspb Nov 4, 2016

Contributor

@magicrub Not quite sure I've got your point. What do you mean?

Contributor

dipspb commented Nov 4, 2016

@magicrub Not quite sure I've got your point. What do you mean?

@magicrub

This comment has been minimized.

Show comment
Hide comment
@magicrub

magicrub Nov 4, 2016

Contributor

@dipspb I mean the updates to the branch are on that PR. Everything was fine. Changing to a new PR was unnecessary. However, since you're making a new branch and a new PR it would have been nice to rebase onto master while you were at it but that's OK, there's no merge conflicts so it happens auto-magically

Contributor

magicrub commented Nov 4, 2016

@dipspb I mean the updates to the branch are on that PR. Everything was fine. Changing to a new PR was unnecessary. However, since you're making a new branch and a new PR it would have been nice to rebase onto master while you were at it but that's OK, there's no merge conflicts so it happens auto-magically

@magicrub

This comment has been minimized.

Show comment
Hide comment
@magicrub

magicrub Nov 4, 2016

Contributor

I hate to be the one bringing the bad news, but you've squashed your commits too much. In a PR like this we'd really like to see the commits done to the vehicle be in a separate commit.

Contributor

magicrub commented Nov 4, 2016

I hate to be the one bringing the bad news, but you've squashed your commits too much. In a PR like this we'd really like to see the commits done to the vehicle be in a separate commit.

@magicrub

This comment has been minimized.

Show comment
Hide comment
@magicrub

magicrub Nov 4, 2016

Contributor

If you aren't able to do that then maybe the one merging it can

Contributor

magicrub commented Nov 4, 2016

If you aren't able to do that then maybe the one merging it can

@dipspb

This comment has been minimized.

Show comment
Hide comment
@dipspb

dipspb Nov 4, 2016

Contributor

@magicrub I remastered my commits in accordance with recommendations from @mirkix #5082 (comment) and following "submitting patches" document http://ardupilot.org/dev/docs/submitting-patches-back-to-master.html

And I have not a minor advice on what commits should be left separate. Nobody warned me and so on..

So my three questions at this moment:

  1. How would I guess it?
  2. Where I can read plain and clear document the covers issue you have just mentioned?
  3. What I need to do?

Thank you very much in advance

p.s. The person who is merging, it's me.

Contributor

dipspb commented Nov 4, 2016

@magicrub I remastered my commits in accordance with recommendations from @mirkix #5082 (comment) and following "submitting patches" document http://ardupilot.org/dev/docs/submitting-patches-back-to-master.html

And I have not a minor advice on what commits should be left separate. Nobody warned me and so on..

So my three questions at this moment:

  1. How would I guess it?
  2. Where I can read plain and clear document the covers issue you have just mentioned?
  3. What I need to do?

Thank you very much in advance

p.s. The person who is merging, it's me.

@OXINARF

This comment has been minimized.

Show comment
Hide comment
@OXINARF

OXINARF Nov 4, 2016

Member

@dipspb It is written there:

"Commits should be small, and do just one thing. If a change touches multiple libraries then there should be a separate commit per library, and a separate commit per vehicle directory. This is true even if it means that intermediate commits break the build."

Along with:

Commit messages should be of the form:

Subsystem: brief description

Longer description...

Anyway, there are previous comments I made in the previous PR that still haven't been addressed. Also, it has been found by Tridge that this driver (along with others) are doing I2C transactions in the main thread and although that looks to be fine in Linux it is a no-no for Pixhawk. That needs to be fixed before this can go in.

P.S.: You are not merging, you are proposing a change in the form of a pull request. Someone from the team will merge this to master.

Member

OXINARF commented Nov 4, 2016

@dipspb It is written there:

"Commits should be small, and do just one thing. If a change touches multiple libraries then there should be a separate commit per library, and a separate commit per vehicle directory. This is true even if it means that intermediate commits break the build."

Along with:

Commit messages should be of the form:

Subsystem: brief description

Longer description...

Anyway, there are previous comments I made in the previous PR that still haven't been addressed. Also, it has been found by Tridge that this driver (along with others) are doing I2C transactions in the main thread and although that looks to be fine in Linux it is a no-no for Pixhawk. That needs to be fixed before this can go in.

P.S.: You are not merging, you are proposing a change in the form of a pull request. Someone from the team will merge this to master.

@dipspb

This comment has been minimized.

Show comment
Hide comment
@dipspb

dipspb Nov 4, 2016

Contributor

@OXINARF thank you. Will redo. So one more branch/PR?

this driver (along with others) are doing I2C transactions in the main thread and although that looks to be fine in Linux it is a no-no for Pixhawk. That needs to be fixed before this can go in.

How and where it need to be fixed? What about other drivers?

P.S. Sure, you are right. Here is about midnight and I falling asleep a bit. I mean 'I'm a person who is remastering these PRs'

Contributor

dipspb commented Nov 4, 2016

@OXINARF thank you. Will redo. So one more branch/PR?

this driver (along with others) are doing I2C transactions in the main thread and although that looks to be fine in Linux it is a no-no for Pixhawk. That needs to be fixed before this can go in.

How and where it need to be fixed? What about other drivers?

P.S. Sure, you are right. Here is about midnight and I falling asleep a bit. I mean 'I'm a person who is remastering these PRs'

@dipspb

This comment has been minimized.

Show comment
Hide comment
@dipspb

dipspb Nov 4, 2016

Contributor

Ok. I can see 4 (sort of) unresolved issues to do:

  1. One missed usage of sprintf. To be done.
  2. "ARMED message only when armed" #5082 (comment)
  3. I2C issue(s) #5082 (comment) + threading issue
  4. Separate squashed commits for: AP_Notify, ArduCopter and ArduPlane

Right? I can see what to do with 1 and 4. And I need to see what to do with 2 and 3.

Contributor

dipspb commented Nov 4, 2016

Ok. I can see 4 (sort of) unresolved issues to do:

  1. One missed usage of sprintf. To be done.
  2. "ARMED message only when armed" #5082 (comment)
  3. I2C issue(s) #5082 (comment) + threading issue
  4. Separate squashed commits for: AP_Notify, ArduCopter and ArduPlane

Right? I can see what to do with 1 and 4. And I need to see what to do with 2 and 3.

@OXINARF

This comment has been minimized.

Show comment
Hide comment
@OXINARF

OXINARF Nov 4, 2016

Member

@dipspb Several points:

  • when I said there are comments from me that weren't addressed I was referring to the first two points of #5082 (comment)
  • regarding the I2C fixes you only need to worry about this driver since we can add it to Pixhawk without fixing it. You can see at 91cc8b7 how Tridge fixed it. We also need to understand why @kozinalexey was seeing artifacts with the big I2C transfer (your point number 3).
  • regarding the ARMED I just wanted to understand if that was the desired functionality, I haven't answered as I think @kozinalexey gave a good answer
  • you don't need to do another PR, you need to split the commit and force push. To do that you will either need to use the git command line or use a GUI to work with Git (Tom recommended SourceTree and I can recommend it too). If you need help with this we can help in Gitter.
Member

OXINARF commented Nov 4, 2016

@dipspb Several points:

  • when I said there are comments from me that weren't addressed I was referring to the first two points of #5082 (comment)
  • regarding the I2C fixes you only need to worry about this driver since we can add it to Pixhawk without fixing it. You can see at 91cc8b7 how Tridge fixed it. We also need to understand why @kozinalexey was seeing artifacts with the big I2C transfer (your point number 3).
  • regarding the ARMED I just wanted to understand if that was the desired functionality, I haven't answered as I think @kozinalexey gave a good answer
  • you don't need to do another PR, you need to split the commit and force push. To do that you will either need to use the git command line or use a GUI to work with Git (Tom recommended SourceTree and I can recommend it too). If you need help with this we can help in Gitter.
@magicrub

This comment has been minimized.

Show comment
Hide comment
@magicrub

magicrub Nov 4, 2016

Contributor

p.s. The person who is merging, it's me.

I meant the person who's merging into Ardupilot. We can do it

Contributor

magicrub commented Nov 4, 2016

p.s. The person who is merging, it's me.

I meant the person who's merging into Ardupilot. We can do it

Show outdated Hide outdated libraries/AP_Notify/AP_Notify.h
private:
static NotifyDevice* _devices[];
static float _voltage;
static uint8_t _control_mode;

This comment has been minimized.

@magicrub

magicrub Nov 7, 2016

Contributor

why are _voltage and _control_mode static?

@magicrub

magicrub Nov 7, 2016

Contributor

why are _voltage and _control_mode static?

This comment has been minimized.

@dipspb

dipspb Nov 21, 2016

Contributor

fixed with new set of commits in the same branch

@dipspb

dipspb Nov 21, 2016

Contributor

fixed with new set of commits in the same branch

dipspb added a commit to dipspb/ardupilot that referenced this pull request Nov 21, 2016

dipspb added a commit to dipspb/ardupilot that referenced this pull request Nov 21, 2016

dipspb added a commit to dipspb/ardupilot that referenced this pull request Nov 21, 2016

@dipspb

This comment has been minimized.

Show comment
Hide comment
@dipspb

dipspb Nov 21, 2016

Contributor

Commits were reworked.

Contributor

dipspb commented Nov 21, 2016

Commits were reworked.

dipspb added a commit to dipspb/ardupilot that referenced this pull request Nov 22, 2016

dipspb added a commit to dipspb/ardupilot that referenced this pull request Nov 22, 2016

dipspb added a commit to dipspb/ardupilot that referenced this pull request Nov 22, 2016

@dipspb

This comment has been minimized.

Show comment
Hide comment
@dipspb

dipspb Nov 22, 2016

Contributor

Extra accessor methods removed. Extra fields like _voltage and _control_mode were moved to AP_Notify::flags.

Contributor

dipspb commented Nov 22, 2016

Extra accessor methods removed. Extra fields like _voltage and _control_mode were moved to AP_Notify::flags.

@rmackay9

This comment has been minimized.

Show comment
Hide comment
@rmackay9

rmackay9 Nov 26, 2016

Contributor

I've had a quick look at this, the duplication of the flight mode names doesn't make me too happy. It's something we would need to remember to update each time we add a new flight mode. Not the end of the world but not great. We already have a print_flight_mode function in each vehicle class although it sends to a "BetterStream" and it would probably be ugly to pass this into Notify.

I was actually surprised that this was written as a Notify object. I was expecting it to be more like the FrSky protocol or a telemetry link to the ground station. It would be nice for example to have it display the messages that normally appear on the mission planner HUD.. like the pre-arm check failures.

Update: maybe I need to read this PR more, I see from a picture posted in gitter than the pre-arm messages do seem to be printed (or at least "Compass not calib" is being printed.

Contributor

rmackay9 commented Nov 26, 2016

I've had a quick look at this, the duplication of the flight mode names doesn't make me too happy. It's something we would need to remember to update each time we add a new flight mode. Not the end of the world but not great. We already have a print_flight_mode function in each vehicle class although it sends to a "BetterStream" and it would probably be ugly to pass this into Notify.

I was actually surprised that this was written as a Notify object. I was expecting it to be more like the FrSky protocol or a telemetry link to the ground station. It would be nice for example to have it display the messages that normally appear on the mission planner HUD.. like the pre-arm check failures.

Update: maybe I need to read this PR more, I see from a picture posted in gitter than the pre-arm messages do seem to be printed (or at least "Compass not calib" is being printed.

@dipspb

This comment has been minimized.

Show comment
Hide comment
@dipspb

dipspb Nov 26, 2016

Contributor

@rmackay9 First line of OLED display shows not just cropped message. It runs like a ticker showing complete HUD messages. Here is how it's running:
https://www.youtube.com/watch?v=VON2CzIsfOI

Contributor

dipspb commented Nov 26, 2016

@rmackay9 First line of OLED display shows not just cropped message. It runs like a ticker showing complete HUD messages. Here is how it's running:
https://www.youtube.com/watch?v=VON2CzIsfOI

@dipspb

This comment has been minimized.

Show comment
Hide comment
@dipspb

dipspb Nov 26, 2016

Contributor

Hello, @rmackay9 Unsure I've got your point about Notification vs Telemetry. Could you pls to clarify in more details? What's wrong with Notify object? We didn't do that, it was already implemented this way by @mirkix .

That's for mode names, IMHO it shouldn't be a big deal to refactor print_flight_mode by extracting get_flight_mode_string from it. Any other ideas are appreciated.

The only thing that frustrating me really much is a fact that review feedback notes are arriving one-by-one with a few days gap. May I have review notes for this PR all at once so I would able to resolve all of them and then to be sure PR will be accepted?

Contributor

dipspb commented Nov 26, 2016

Hello, @rmackay9 Unsure I've got your point about Notification vs Telemetry. Could you pls to clarify in more details? What's wrong with Notify object? We didn't do that, it was already implemented this way by @mirkix .

That's for mode names, IMHO it shouldn't be a big deal to refactor print_flight_mode by extracting get_flight_mode_string from it. Any other ideas are appreciated.

The only thing that frustrating me really much is a fact that review feedback notes are arriving one-by-one with a few days gap. May I have review notes for this PR all at once so I would able to resolve all of them and then to be sure PR will be accepted?

@rmackay9 rmackay9 self-assigned this Nov 28, 2016

@rmackay9

This comment has been minimized.

Show comment
Hide comment
@rmackay9

rmackay9 Nov 28, 2016

Contributor

The ability to display the messages is great. I'll take responsibility for reviewing this PR in more detail and getting it in.

As a side note, I've got four screens coming (two of each of these):
https://www.adafruit.com/product/326
https://www.adafruit.com/product/938

Contributor

rmackay9 commented Nov 28, 2016

The ability to display the messages is great. I'll take responsibility for reviewing this PR in more detail and getting it in.

As a side note, I've got four screens coming (two of each of these):
https://www.adafruit.com/product/326
https://www.adafruit.com/product/938

Show outdated Hide outdated libraries/AP_Notify/Display.cpp
_flags.gps_status = AP_Notify::flags.gps_status;
}
if (AP_Notify::flags.armed)
{

This comment has been minimized.

@magicrub

magicrub Dec 6, 2016

Contributor

tabs

@magicrub

magicrub Dec 6, 2016

Contributor

tabs

@rmackay9

This comment has been minimized.

Show comment
Hide comment
@rmackay9

rmackay9 Dec 6, 2016

Contributor

My screens have arrived the 1.3" one at least is not immediately working when connected to I2C.
As far as I can tell there aren't any parameters that need to be set to enable it.
Hopefully I'll figure out what's wrong.

Contributor

rmackay9 commented Dec 6, 2016

My screens have arrived the 1.3" one at least is not immediately working when connected to I2C.
As far as I can tell there aren't any parameters that need to be set to enable it.
Hopefully I'll figure out what's wrong.

@magicrub

This comment has been minimized.

Show comment
Hide comment
@magicrub

magicrub Dec 6, 2016

Contributor

Doh!

Contributor

magicrub commented Dec 6, 2016

Doh!

@kozinalexey

This comment has been minimized.

Show comment
Hide comment
@kozinalexey

kozinalexey Dec 6, 2016

Contributor

1.3 inch OLED have another IC driver, dipspb always prepare code for 1.3 inch display type support, but he waiting for this pr will be accepted, else oled code integration process stops in infinite loop

Contributor

kozinalexey commented Dec 6, 2016

1.3 inch OLED have another IC driver, dipspb always prepare code for 1.3 inch display type support, but he waiting for this pr will be accepted, else oled code integration process stops in infinite loop

"QLND", // = 20,
"QRTL" // = 21
};
#else //rover

This comment has been minimized.

@night-ghost

night-ghost Dec 6, 2016

Contributor

I think that you forget AntennaTracker, where display with coordinates of drone is a long awaited feature.

@night-ghost

night-ghost Dec 6, 2016

Contributor

I think that you forget AntennaTracker, where display with coordinates of drone is a long awaited feature.

This comment has been minimized.

@kozinalexey

kozinalexey Dec 6, 2016

Contributor

hi, what mode need for display? tracker mode or mode of model?
i see "notify display" is not suitable for tracker
the tracker need display but with another layout and parameters list.
also display for tracker not need small size and weight.

best solution for tracker https://learn.adafruit.com/adafruit-3-5-color-320x480-tft-touchscreen-breakout/overview

  1. big size
  2. full color
  3. touch screen
    small atmega 328 chip may decode mavlink for control this display
@kozinalexey

kozinalexey Dec 6, 2016

Contributor

hi, what mode need for display? tracker mode or mode of model?
i see "notify display" is not suitable for tracker
the tracker need display but with another layout and parameters list.
also display for tracker not need small size and weight.

best solution for tracker https://learn.adafruit.com/adafruit-3-5-color-320x480-tft-touchscreen-breakout/overview

  1. big size
  2. full color
  3. touch screen
    small atmega 328 chip may decode mavlink for control this display

This comment has been minimized.

@night-ghost

night-ghost Dec 6, 2016

Contributor

That solution is very good but requires a some additional piece of hardware. But small display which shows Tracker mode for some time and then shows UAV coords will be a very good thing too.

@night-ghost

night-ghost Dec 6, 2016

Contributor

That solution is very good but requires a some additional piece of hardware. But small display which shows Tracker mode for some time and then shows UAV coords will be a very good thing too.

This comment has been minimized.

@dipspb

dipspb Dec 6, 2016

Contributor

@night-ghost Thanks for your feedback, we will try to figure out how to implement it and probably to put it into separate PR

@dipspb

dipspb Dec 6, 2016

Contributor

@night-ghost Thanks for your feedback, we will try to figure out how to implement it and probably to put it into separate PR

This comment has been minimized.

@kozinalexey

kozinalexey Dec 6, 2016

Contributor

idea: based minim-osd code mavlink tft display device

@kozinalexey

kozinalexey Dec 6, 2016

Contributor

idea: based minim-osd code mavlink tft display device

This comment has been minimized.

@kozinalexey

kozinalexey Dec 13, 2016

Contributor

i tested both single colour ssd1306 modules and two-colour
all work fine
may be you have defect board?

@kozinalexey

kozinalexey Dec 13, 2016

Contributor

i tested both single colour ssd1306 modules and two-colour
all work fine
may be you have defect board?

This comment has been minimized.

@kozinalexey

kozinalexey Dec 13, 2016

Contributor

my yellow - blue module
two_color_oled

@kozinalexey

kozinalexey Dec 13, 2016

Contributor

my yellow - blue module
two_color_oled

This comment has been minimized.

@Micheal-Kelly

Micheal-Kelly Dec 13, 2016

When I tried to modify Mirko's original BBBmini code to use with Pixhawk, instead of BBBmini, I got the result above with random dots. I missed something that you did correctly Alexey. When I used your test code with the same SSD_1306 module and same fc it works fine. So I don't believe the module is defective.

@Micheal-Kelly

Micheal-Kelly Dec 13, 2016

When I tried to modify Mirko's original BBBmini code to use with Pixhawk, instead of BBBmini, I got the result above with random dots. I missed something that you did correctly Alexey. When I used your test code with the same SSD_1306 module and same fc it works fine. So I don't believe the module is defective.

This comment has been minimized.

@kozinalexey

kozinalexey Dec 13, 2016

Contributor

i split one big i2c transfer to two half-size part
05c15cf#diff-139e25bfb70fdbab5c597b2f84006f4dL81

@kozinalexey

kozinalexey Dec 13, 2016

Contributor

i split one big i2c transfer to two half-size part
05c15cf#diff-139e25bfb70fdbab5c597b2f84006f4dL81

This comment has been minimized.

@mariansoban

mariansoban Dec 13, 2016

OK, in the end I've made it work somehow.
This is the commit for Copter-3.4.3 that contains (hopefully all) the code changes from above (for the copter):
mariansoban/ardupilot@fb5ee4d
But it doesn't work:
dsc_0112

And this is the fix:
mariansoban/ardupilot@2c7628f

dsc_0113
It's Alexey's older version of SSD1306_I2C driver I guess, I've just added there method clear_screen() to fit library requirements.
Full Copter-3.4.3 with OLED support source code can be found here:
https://github.com/mariansoban/ardupilot/tree/Copter-3.4-oled

@mariansoban

mariansoban Dec 13, 2016

OK, in the end I've made it work somehow.
This is the commit for Copter-3.4.3 that contains (hopefully all) the code changes from above (for the copter):
mariansoban/ardupilot@fb5ee4d
But it doesn't work:
dsc_0112

And this is the fix:
mariansoban/ardupilot@2c7628f

dsc_0113
It's Alexey's older version of SSD1306_I2C driver I guess, I've just added there method clear_screen() to fit library requirements.
Full Copter-3.4.3 with OLED support source code can be found here:
https://github.com/mariansoban/ardupilot/tree/Copter-3.4-oled

@jinchengde

This comment has been minimized.

Show comment
Hide comment
@jinchengde

jinchengde Dec 14, 2016

Contributor

That's so great!

Contributor

jinchengde commented Dec 14, 2016

That's so great!

@dipspb

This comment has been minimized.

Show comment
Hide comment
@dipspb

dipspb Dec 29, 2016

Contributor

I've spent a lot of time in attempt to implement OLED type auto-detection, but there is no success. It seems there is no reliable way to auto-detect OLED type. So I going to implement a single parameter like OLED_CONFIG that will contain both values: the i2c bus number to use and the type of OLED. Will that do?

Contributor

dipspb commented Dec 29, 2016

I've spent a lot of time in attempt to implement OLED type auto-detection, but there is no success. It seems there is no reliable way to auto-detect OLED type. So I going to implement a single parameter like OLED_CONFIG that will contain both values: the i2c bus number to use and the type of OLED. Will that do?

@magicrub

This comment has been minimized.

Show comment
Hide comment
@magicrub

magicrub Dec 29, 2016

Contributor

Prefer sperate Params: _type and _addr.

Contributor

magicrub commented Dec 29, 2016

Prefer sperate Params: _type and _addr.

@dipspb

This comment has been minimized.

Show comment
Hide comment
@dipspb

dipspb Dec 29, 2016

Contributor

@magicrub agree, but there are 3 params to config indeed:

  1. i2c bus number
  2. i2c address (fixed value for most OLEDs, but options are possible)
  3. OLED type

Couldn't it be too much? In case nobody have objections will go this way.

Contributor

dipspb commented Dec 29, 2016

@magicrub agree, but there are 3 params to config indeed:

  1. i2c bus number
  2. i2c address (fixed value for most OLEDs, but options are possible)
  3. OLED type

Couldn't it be too much? In case nobody have objections will go this way.

@magicrub

This comment has been minimized.

Show comment
Hide comment
@magicrub

magicrub Dec 30, 2016

Contributor

Do we really need bus number?

Contributor

magicrub commented Dec 30, 2016

Do we really need bus number?

dipspb added a commit to dipspb/ardupilot that referenced this pull request Dec 30, 2016

dipspb added a commit to dipspb/ardupilot that referenced this pull request Dec 30, 2016

dipspb added a commit to dipspb/ardupilot that referenced this pull request Dec 30, 2016

@dipspb

This comment has been minimized.

Show comment
Hide comment
@dipspb

dipspb Dec 30, 2016

Contributor

tabs issue resolved

Contributor

dipspb commented Dec 30, 2016

tabs issue resolved

Show outdated Hide outdated libraries/AP_Notify/AP_Notify.h
@@ -111,10 +122,17 @@ class AP_Notify
static const struct AP_Param::GroupInfo var_info[];
bool buzzer_enabled() const { return _buzzer_enable; }
static void send_text(const char *str) { snprintf(_send_text, sizeof(_send_text), "%s", str); }

This comment has been minimized.

@magicrub

magicrub Dec 31, 2016

Contributor

calls to send_text() should probably do nothing unless this feature is enabled

@magicrub

magicrub Dec 31, 2016

Contributor

calls to send_text() should probably do nothing unless this feature is enabled

This comment has been minimized.

@dipspb

dipspb Dec 31, 2016

Contributor

The send_text() is a static method so it unable access _display_type parameter variable which is instance one. Unsure I can make _display_type as a static. Also send_text() just prints string to the buffer. It is not a problem, because in case of _display_type == DISPLAY_OFF the buffer will not be used to send data to display.

@dipspb

dipspb Dec 31, 2016

Contributor

The send_text() is a static method so it unable access _display_type parameter variable which is instance one. Unsure I can make _display_type as a static. Also send_text() just prints string to the buffer. It is not a problem, because in case of _display_type == DISPLAY_OFF the buffer will not be used to send data to display.

This comment has been minimized.

@magicrub

magicrub Dec 31, 2016

Contributor

Also send_text() just prints string to the buffer.

I agree that snprintf is the safest, but it extremely slow. It's not a simple mem copy, it's a string parsing operation. Even though it's a relatively simple one it's still much more complicated than a simple strncpy and I think it's safe to say that we will always have a null terminated string arrive here. Even not, you're clipping to the _send_text size so it's safe. I propose either using strcpy() and/or check if _type != DISPLAY_OFF.

See the comparison here: http://stackoverflow.com/questions/12275381/strncpy-vs-sprintf

Execution time, including parameter shuffling on/off call stack:

strcpy 43 instructions
sprintf 467 instructions
Program/ROM space allocated:

strcpy 56 bytes
sprintf 1488 bytes
RAM/stack space allocated:

strcpy 0 bytes
sprintf 15 bytes

@magicrub

magicrub Dec 31, 2016

Contributor

Also send_text() just prints string to the buffer.

I agree that snprintf is the safest, but it extremely slow. It's not a simple mem copy, it's a string parsing operation. Even though it's a relatively simple one it's still much more complicated than a simple strncpy and I think it's safe to say that we will always have a null terminated string arrive here. Even not, you're clipping to the _send_text size so it's safe. I propose either using strcpy() and/or check if _type != DISPLAY_OFF.

See the comparison here: http://stackoverflow.com/questions/12275381/strncpy-vs-sprintf

Execution time, including parameter shuffling on/off call stack:

strcpy 43 instructions
sprintf 467 instructions
Program/ROM space allocated:

strcpy 56 bytes
sprintf 1488 bytes
RAM/stack space allocated:

strcpy 0 bytes
sprintf 15 bytes

This comment has been minimized.

@dipspb

dipspb Jan 1, 2017

Contributor

replaced to strncpy

@dipspb

dipspb Jan 1, 2017

Contributor

replaced to strncpy

dipspb added a commit to dipspb/ardupilot that referenced this pull request Dec 31, 2016

dipspb added a commit to dipspb/ardupilot that referenced this pull request Dec 31, 2016

dipspb added a commit to dipspb/ardupilot that referenced this pull request Dec 31, 2016

@dipspb

This comment has been minimized.

Show comment
Hide comment
@dipspb

dipspb Dec 31, 2016

Contributor

Minor buffer initialization fix added 593654e#diff-538a73bac9a5fbabe5668d4e34f232caR163

Contributor

dipspb commented Dec 31, 2016

Minor buffer initialization fix added 593654e#diff-538a73bac9a5fbabe5668d4e34f232caR163

@dipspb

This comment has been minimized.

Show comment
Hide comment
@dipspb

dipspb Jan 1, 2017

Contributor

snprintf(..., "%s", ...) changed to strncpy

Contributor

dipspb commented Jan 1, 2017

snprintf(..., "%s", ...) changed to strncpy

@magicrub

This comment has been minimized.

Show comment
Hide comment
@magicrub

magicrub Jan 1, 2017

Contributor

Thanks @dipspb . I just did a check for snprintf and vsnprintf and it's used almost 70 times where strncpy is only used about 25 times. Maybe I gave you wrong advice?

Can anyone else chime in on this to sanity check me?

Contributor

magicrub commented Jan 1, 2017

Thanks @dipspb . I just did a check for snprintf and vsnprintf and it's used almost 70 times where strncpy is only used about 25 times. Maybe I gave you wrong advice?

Can anyone else chime in on this to sanity check me?

@dipspb

This comment has been minimized.

Show comment
Hide comment
@dipspb

dipspb Jan 1, 2017

Contributor

@magicrub I pretty sure it was really good advice for that particular method. Thank you!

Contributor

dipspb commented Jan 1, 2017

@magicrub I pretty sure it was really good advice for that particular method. Thank you!

@dipspb

This comment has been minimized.

Show comment
Hide comment
@dipspb

dipspb Jan 3, 2017

Contributor

Hi @rmackay9 , do you have any success testing your OLED modules with my final commits?

Contributor

dipspb commented Jan 3, 2017

Hi @rmackay9 , do you have any success testing your OLED modules with my final commits?

dipspb added a commit to dipspb/ardupilot that referenced this pull request Jan 7, 2017

dipspb added a commit to dipspb/ardupilot that referenced this pull request Jan 7, 2017

dipspb added a commit to dipspb/ardupilot that referenced this pull request Jan 7, 2017

dipspb added a commit to dipspb/ardupilot that referenced this pull request Jan 8, 2017

dipspb added a commit to dipspb/ardupilot that referenced this pull request Jan 8, 2017

dipspb added a commit to dipspb/ardupilot that referenced this pull request Jan 8, 2017

@rmackay9 rmackay9 added this to the AC 3.5.0 milestone Jan 9, 2017

rmackay9 added a commit to rmackay9/rmackay9-ardupilot that referenced this pull request Jan 17, 2017

@rmackay9

This comment has been minimized.

Show comment
Hide comment
@rmackay9

rmackay9 Jan 17, 2017

Contributor

I've received a display from @dipspb and it works! I don't understand why my existing displays from adafruit don't work. Is the aliexpress link from above the best source of displays?

I've rebased on master and resolved a few conflicts. https://github.com/rmackay9/rmackay9-ardupilot/commits/oled-display2.

There are a few potential issues that I hope to make more progress on tomorrow:

  • the front-end/back-end split is a slightly different method than we currently use (see other libraries like AP_Buzzer to see how we normally do it) so I will like re-format it to look more like other libraries.
  • @tridge is concerned about the I2C traffic especially when flying so I will test this.
  • @OXINARF (and perhaps others) will be unhappy about the vehicle specific #defines in the library to provide the flight modes.
Contributor

rmackay9 commented Jan 17, 2017

I've received a display from @dipspb and it works! I don't understand why my existing displays from adafruit don't work. Is the aliexpress link from above the best source of displays?

I've rebased on master and resolved a few conflicts. https://github.com/rmackay9/rmackay9-ardupilot/commits/oled-display2.

There are a few potential issues that I hope to make more progress on tomorrow:

  • the front-end/back-end split is a slightly different method than we currently use (see other libraries like AP_Buzzer to see how we normally do it) so I will like re-format it to look more like other libraries.
  • @tridge is concerned about the I2C traffic especially when flying so I will test this.
  • @OXINARF (and perhaps others) will be unhappy about the vehicle specific #defines in the library to provide the flight modes.
@kozinalexey

This comment has been minimized.

Show comment
Hide comment
@kozinalexey

kozinalexey Jan 17, 2017

Contributor

@rmackay9 oled display have i2c address solder jumper. maybe adafruit model have wrong default setting

Contributor

kozinalexey commented Jan 17, 2017

@rmackay9 oled display have i2c address solder jumper. maybe adafruit model have wrong default setting

@magicrub

This comment has been minimized.

Show comment
Hide comment
@magicrub

magicrub Jan 17, 2017

Contributor

To address the excess i2c traffic during flight, can we disable this feature while flying and/or armed to get this PR in and then fix that later?

Contributor

magicrub commented Jan 17, 2017

To address the excess i2c traffic during flight, can we disable this feature while flying and/or armed to get this PR in and then fix that later?

@kozinalexey

This comment has been minimized.

Show comment
Hide comment
@kozinalexey

kozinalexey Jan 17, 2017

Contributor

display do not have traffic in armed state, after ARMING it clear screen , show message "ARMED" and stop any updates

Contributor

kozinalexey commented Jan 17, 2017

display do not have traffic in armed state, after ARMING it clear screen , show message "ARMED" and stop any updates

@OXINARF

This comment has been minimized.

Show comment
Hide comment
@OXINARF

OXINARF Jan 17, 2017

Member

@OXINARF (and perhaps others) will be unhappy about the vehicle specific #defines in the library to provide the flight modes.

I couldn't think of a better option, so I'm not against it. It's not great to have it, but until someone does an AP_Telemetry library (which I envision as having subclasses in every vehicle) I think we'll continue to have these defines.

Member

OXINARF commented Jan 17, 2017

@OXINARF (and perhaps others) will be unhappy about the vehicle specific #defines in the library to provide the flight modes.

I couldn't think of a better option, so I'm not against it. It's not great to have it, but until someone does an AP_Telemetry library (which I envision as having subclasses in every vehicle) I think we'll continue to have these defines.

@rmackay9

This comment has been minimized.

Show comment
Hide comment
@rmackay9

rmackay9 Jan 18, 2017

Contributor

@OXINARF, Thanks. As a side note, I've also been thinking that we need an AP_Telemetry library which would absorb our GCS_MAVLink and FRSky telemetry libraries.

Contributor

rmackay9 commented Jan 18, 2017

@OXINARF, Thanks. As a side note, I've also been thinking that we need an AP_Telemetry library which would absorb our GCS_MAVLink and FRSky telemetry libraries.

@lucasdemarchi

This comment has been minimized.

Show comment
Hide comment
@lucasdemarchi

lucasdemarchi Jan 19, 2017

Contributor

I couldn't think of a better option, so I'm not against it. It's not great to have it, but until someone does an AP_Telemetry library (which I envision as having subclasses in every vehicle) I think we'll continue to have these defines.

A method inside each vehicle that returns the flight mode would suffice and avoid the ifdef. It would be very simple while a more elaborate solution is not done.

Contributor

lucasdemarchi commented Jan 19, 2017

I couldn't think of a better option, so I'm not against it. It's not great to have it, but until someone does an AP_Telemetry library (which I envision as having subclasses in every vehicle) I think we'll continue to have these defines.

A method inside each vehicle that returns the flight mode would suffice and avoid the ifdef. It would be very simple while a more elaborate solution is not done.

@OXINARF

This comment has been minimized.

Show comment
Hide comment
@OXINARF

OXINARF Jan 19, 2017

Member

I thought of that but I'm not a fan of vehicles calling libraries calling vehicles. Also, it wouldn't be a direct connection in this case because the Display object is created in AP_Notify (and that is what is created in the vehicle), which makes it even worse for me.

Member

OXINARF commented Jan 19, 2017

I thought of that but I'm not a fan of vehicles calling libraries calling vehicles. Also, it wouldn't be a direct connection in this case because the Display object is created in AP_Notify (and that is what is created in the vehicle), which makes it even worse for me.

@lucasdemarchi

This comment has been minimized.

Show comment
Hide comment
@lucasdemarchi

lucasdemarchi Jan 19, 2017

Contributor

Still better than a ifdef.

AP_Vehicle::get_flight_mode(), to be implemented by each vehicle. No reference passing, straight plain old boring function :)

Contributor

lucasdemarchi commented Jan 19, 2017

Still better than a ifdef.

AP_Vehicle::get_flight_mode(), to be implemented by each vehicle. No reference passing, straight plain old boring function :)

@OXINARF

This comment has been minimized.

Show comment
Hide comment
@OXINARF

OXINARF Jan 19, 2017

Member

I consider them almost equally bad that I don't care about the ifdef.

Member

OXINARF commented Jan 19, 2017

I consider them almost equally bad that I don't care about the ifdef.

@rmackay9

This comment has been minimized.

Show comment
Hide comment
@rmackay9

rmackay9 Jan 19, 2017

Contributor

I'm going to close this PR because we have an updated PR now: #5581

Contributor

rmackay9 commented Jan 19, 2017

I'm going to close this PR because we have an updated PR now: #5581

@rmackay9 rmackay9 closed this Jan 19, 2017

EShamaev added a commit to EShamaev/ardupilot that referenced this pull request Feb 28, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment