Pokitto magazine #2, article ideas?

How about Bluetooth to PEX? Simple and cheap.

2 Likes

Maybe the classical Christmas LED tree :stuck_out_tongue:

Actually, Iā€™d love a tutorial for controlling one of those 8x8 matrixes of LEDs from the Pokitto, maybe that could be something interesting as a hat project in general?

5 Likes

Would a hardware hacking article š‡šššÆšž be Pokitto related?

1 Like

Iā€™m not sure what Iā€™d write.
Iā€™ve already written a tutorial, so wouldnā€™t an article just be a rehash of that?

Also my electronics knowledge is still pretty limited.
The main reason I wrote the tutorial was because I was writing it more or less as I was learning it.

Iā€™d bought a basic Arduino kit (which in hindsight was possibly not very good value for money):


And that (together with the Pokitto) is pretty much all the electronics resources that I have.

(I meant to do more hardware stuff but it was the usual case of too many projects and not enough time or motivation to finish them.)


Now I think about it, I still donā€™t quite know whether itā€™s safe to use 5V connections with the PEX.
I vaguely remember looking into it and I think I found out that only some of the PEX pins are 5V safe,
but I donā€™t remember finding anything conclusive.

Maybe someone could write about that? :P


I might be able to write something like this if I can find the time,
but Iā€™d want to know what people actually want to know about.

I could write monologues about move semantics, templates, RAII et cetera,
but it would be a waste of time (and magazine space) if itā€™s not something people actually want to read about.


I think that would depend on the project.

If itā€™s something that doesnā€™t involve a microcontroller then it might make sense to not include the Pokitto,
but if it requires a microcontroller then that microcontroller ought to be the Pokitto if possible.

The forum has a ā€œAnd we also likeā€¦ā€ category, it might make sense that the magazine have one too.

2 Likes

Yes. I was told by an NXP designer that in fact all LPC11u68 pins are 5v tolerant

1 Like

Ah good, that makes things so much easier.
That means I can dismantle that circuit I was using as a workaround.


2 Likes

I found this list of your HW projects from the old post:

  • The potentiometer hat
  • The speaker hat
  • The N64 rumble hat
  • The Gameboy printer with Pokitto
  • The Wii controller with Pokitto

I found any of these a very good subject for an article! :slight_smile:

2 Likes

Yes, that is difficult to know. Maybe you could make a poll of it?

Edit: I personally am interested about efficient using of templates in MCU coding. Especially a performance & compiled code size comparison between templates and #defineā€™s.

That Gameboy printer might need looking at againā€¦ I think the method I used at the time was terrible. The Wii controller was fun also. :thinking:

2 Likes

Canā€™t really make a poll until thereā€™s actually a pool of suggestions,
so maybe I (or someone else) can make a ā€œadvanced C++/programming topic suggestionsā€ thread.

Thatā€™s a pretty odd one.

Macros and templates are two very different tools,
so Iā€™m not sure what comparisons youā€™re expecting.

If you mean something like #define MIN(x, y) (((x) < (y)) ? (x) : (y)) vs template<typename T> const T & min(const T & x, const T & y) { return (x < y) ? x : y; } (i.e. function-style macros vs template functions) then the performance difference will depend entirely what expressions are passed as arguments.

More specifically...

For example, given int a = 0; int b = 0;, if you attempted MIN(a, b) and min(a, b) youā€™d get the same result for both expressions.

However, if you attempted MIN(++a, ++b) youā€™d be left with a nasty surprise because the macro would be translated to (((++a) < (++b)) ? (++a) : (++b)) which would leave you with either a or b being incremented twice.

If on the other hand you attempted min(++a, ++b) there are no nasty surprises - a and b are incremented and evaluated just once before the call to min (and that call will almost certainly be inlined because of how small min is).

This is precisely why itā€™s bad to fall into the trap of thinking function macros and template functions are comparable - theyā€™re fundamentally different, so even cases that seem equivalent can hide nasty pitfalls.
This is also an example of one of the many reasons why I prefer templates - templates generally have fewer nasty surprises.

Sorry if thatā€™s not exactly the response you were hoping for,
but hopefully Iā€™ve illustrated why I find ā€˜comparing the performance of templates and #definesā€™ such an odd idea - theyā€™re not even functionally equivalent, so it would be like comparing apples to oranges.

As for template classes,
itā€™s probably possible to simulate them with macros,
but the only way I can think of is horribly cumbersome.

1 Like

So there is not any performance overhead in that case when using templates, if x and y are just integers? Do they produce the same assembler instructions?

1 Like

Assuming:

  • The compiler inlines the template function
    • For something as small as min this is extremely likely
  • The expressions passed in are either variables or literals

Then yes, the resulting machine code should be exactly the same.

If more complex expressions are being used then the template function is likely to produce less machine code because it doesnā€™t duplicate the expression like a function macro would.

More specifically...

If the compiler can prove that the expressions duplicated by the function macro have no side effects then itā€™s allowed to do common subexpression elimination which would mean the duplicated expression isnā€™t a problem,
but the compiler canā€™t always prove that an expression has no side effects (particularly where functions are involved),
in which case using a macro is likely to produce more machine code,
whereas a template function will always force its arguments to be evaluated in full,
just as a non-template function would,
so itā€™s likely to produce less machine code.

3 Likes

Maybe we could start making the magazine after the new year. What do you think? Any volunteers for being the chief editor of the zine #2?

3 Likes

I good volunteer: @torbuntu ! :wink:

1 Like

:sweat_smile: I guess I could give it another go. Would like to have a proof reader as well just in case. I think I missed a few on issue 1

7 Likes

How about a few articles on some of the best games/app released for Pokitto so far?

2 Likes

I think @Zockeromi already has suggested to write that kind or article:

4 Likes

An article in making sound effects and music?

6 Likes