Pokitto magazine #2, article ideas?


#21

How about Bluetooth to PEX? Simple and cheap.


#22

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?


#23

Would a hardware hacking article 𝐇𝐚𝐯𝐞 be Pokitto related?


#24

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.


#25

The forum has a “And we also like…” category, it might make sense that the magazine have one too.


#26

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


#27

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



#28

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:


#29

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.


#30

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:


#31

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.


#32

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?


#33

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.


#34

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?


#35

I good volunteer: @torbuntu ! :wink:


#36

: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