Skip to content
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

Add guide "Using Arduino-libraries in XOD" #63

Merged
merged 1 commit into from
Sep 12, 2018

Conversation

brusherru
Copy link
Contributor

@brusherru brusherru commented Sep 11, 2018

The alternative title of the guide: "How to require and use third-party libraries from GitHub" :)
Check out both languages, please, English and Russian.

@brusherru brusherru self-assigned this Sep 11, 2018
@brusherru brusherru requested a review from a team September 11, 2018 11:07
Copy link
Member

@nkrkv nkrkv left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the title is too general. It’s not about using any Arduino libraries in XOD, it’s about creating wrappers around classes representing hardware modules in existing Arduino libraries.

Can we have a more precise title? Not sure, here are suggestions:

  • Wrapping Arduino libraries
  • Wrapping hardware Arduino libraries
  • Wrapping Arduino libraries’ objects
  • Wrapping class-based Arduino libraries

50% reviewed at the moment


# Using Arduino-libraries in XOD
Many libraries have already been written for Arduino and they can be included
into XOD to use the full power of the existing ecosystem.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

📜 already have been


To understand this guide, you have to know how to work with
[custom types](/docs/guide/custom-types/) and how to write
[C++ code in XOD](/docs/guide/nodes-for-xod-in-cpp/). Also, you need to have
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggest swapping the order of “C++ code in XOD” and “custom types” since the C++ should be read first

some experience of working with C++ libraries for Arduino.

Imagine that we want our Arduino board to turn the built-in led on or off when
we bring the NFC tag (our travel pass, for example) to it.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

📜 an NFC tag

Suggest dropping parens. Just embed “such as a travel pass” right into the sentence.

Imagine that we want our Arduino board to turn the built-in led on or off when
we bring the NFC tag (our travel pass, for example) to it.

Picture that we have no XOD library to work with RFID/NFC scanner PN532
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is “Picture that” even correct? I’d better use “imagine” or “consider”.

we bring the NFC tag (our travel pass, for example) to it.

Picture that we have no XOD library to work with RFID/NFC scanner PN532
([xod-dev/pn532-nfc](/libs/xod-dev/pn532-nfc)), and try to do it on your own. In
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

📜 to make it

#include <Adafruit_PN532.h>
{{/global}}

// Adafruit_PN532 class wants to know ports in the moment of instantiating
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

📜 instantiation

{{/global}}

// Adafruit_PN532 class wants to know ports in the moment of instantiating
// but we don't know it at this moment.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

📜 don't know them

// Adafruit_PN532 class wants to know ports in the moment of instantiating
// but we don't know it at this moment.
// Therefore, we reserve memory to store an instance of the class,
// and create an instance later:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

📜 the instance

{{ GENERATED_CODE }}

void evaluate(Context ctx) {
auto state = getState(ctx);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should have a if (!isSettingUp()) return; as the very first check of the function. Otherwise, memory leaks are possible. Don’t forget to add a reasonable comment about it.

auto irq = getValue<input_IRQ>(ctx);

// Create an instance of the class with specifying prepared place to store it
// using the pointer in parentheses.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Too complex sentence. Suggest:

Create a new object in the memory area reserved previously.

we bring an NFC tag, such as travel pass, to it.

Consider that we have no XOD library to work with RFID/NFC scanner PN532
([xod-dev/pn532-nfc](/libs/xod-dev/pn532-nfc)), and try to make it on your own.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we have
on your own

🤔

download it, saving users from manual install.
3. Create action nodes for the new type that correspond to the functions
and methods provided by the third-party C++ library.
4. Create a quick-start node that reads an NFC tag to solve most common purposes.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm pretty sure it's either "solve problems" or "serve purposes"

another branch or edited — make a fork and require it.
</div>

This is a special line tells XOD, that this node need a third-party library.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this node needs a third-party library?

to use it. Will it be handy to use a chain of nodes `pn532-device`, `init`,
`read-uid`, just to know is there any NFC tag near the module?

Let's simplify the life of both ourselves and the library's consumers, and write
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure the idiom "давайте упростим жизнь себе и ..." can be translated like that.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"Let's simplify our lives and write an nfc-scanner node that solves most common
tasks with just one node."
Ok? :)

Copy link
Contributor

@evgenykochetkov evgenykochetkov Sep 11, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm still not sure. https://www.google.ru/search?q="Let%27s+simplify+our+lives" gives just 6k results 😬

@evgenykochetkov
Copy link
Contributor

evgenykochetkov commented Sep 11, 2018

Also, I noticed that we have a few conventions that are scattered through the docs or even unwritten.
For example:

  • any nodes that create a new type to work with hardware should be named as xxx-device
  • node that initialises hardware module should be named init
  • names of any nodes which do instructions "what to do" in imperative style must begin with a verb (init, read-byte, pair-tag, write-line, etc)
  • nodes that "unfold" complex types into more primitive ones are named unpack-xxx
  • example patches are named example-xxx
    (and probably a few others that I forgot to mention)

Should we make a "styleguide" section in our docs?

@brusherru
Copy link
Contributor Author

@evgenykochetkov @nkrkv check it out, please!

Copy link
Contributor

@evgenykochetkov evgenykochetkov left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM👍🏻

@brusherru brusherru changed the base branch from master to next September 12, 2018 09:16
@@ -30,6 +30,7 @@ The most straightforward way to extend XOD and add support for new hardware.
- [Creating variadic patch nodes](./creating-variadics/)
- [Creating generic patch nodes](./creating-generics/)
- [Defining custom types](./custom-types/)
- [Wrapping Arduino libraries](./using-arduino-libraries-in-xod/)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Bad link URL

first line:

```cpp
#pragma XOR require "https://github.com/adafruit/Adafruit-PN532"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

XOD, not XOR

![Quick start node "nfc-scanner"](./nfc-scanner.patch.png)

1. `flip-flop` is used to trigger `INIT` only once;
2. Open the `gate` to trigger `READ` on each subsequent pulse on the `SCAN`.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These footnotes are outdated now

@brusherru
Copy link
Contributor Author

@nkrkv fixed

Copy link
Member

@nkrkv nkrkv left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Woohoo 😌

@brusherru brusherru merged commit 709f789 into next Sep 12, 2018
@brusherru brusherru deleted the feat-using-ardulibs-in-xod branch September 12, 2018 16:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants