[Solved]M5fire read microphone

[m5-docs]

@hetzer @world101 It need to realize it yourself through python code

[m5-docs]

@hetzer @world101 Here's the arduino code about microphone

https://github.com/m5stack/M5Stack/blob/master/examples/Fire/M5StackFire_Microphone/M5StackFire_Microphone.ino

[jpilarski]

@watson Just curious why not expose the mic in the hardware blocks. It's already a function of the m5stack micropython api and I think it makes sense to have mic blocks exposed in flow.

[world101]

@jpilarski said in M5fire read microphone:

It's already a function of the m5stack micropython api

Is there a microphone specific API (I couldn’t find it), or are you referring to the analogRead API?

[jpilarski]

@world101 It is just an adc call with a buffer but it's documented as part of the api. Still wondering why there isn't a block.
https://m5stack.readthedocs.io/en/master/api-reference/mic/mic.html

[ajb2k3]

@jpilarski said in M5fire read microphone:

@world101 It is just an adc call with a buffer but it's documented as part of the api. Still wondering why there isn't a block.
https://m5stack.readthedocs.io/en/master/api-reference/mic/mic.html

I have spoke to M5Stack about thinks like this and it is not something they thought of at the time. As the community grows and the hardware spreads it is the users that are discovering the functions needed.
BTW you can also make your own blocks but this function is largely undocumented at present.

[m5-docs]

@jpilarski @hetzer @ajb2k3 @world101

Why don't we edit mic block? Because it's not all core owns microphone.

The core bottom in BASE and GRAY kit does not owns microphone. And M5GO Bottom in Fire, M5GO Kit owns microphone. Hope to get your forgive and understanding.

In addition:

This documentation will not be updated no longer.
https://m5stack.readthedocs.io

But the documentation will be updated always. https://docs.m5stack.com/#/

[jpilarski]

@watson @world101 @ajb2k3 @hetzer
I would still consider adding it. I understand it only exists in m5go and fire but then under hardware blocks call the block m5go mic. I just think new users would experiment more with that function exposed as a block. I totally understand I can now make a custom block for this but I still think it makes sense to see it as a default block. It should definitely be exposed for StickC since with that board there is no confusion as they all have a mic. What about having a toggle when the user selects core that designates fire, go, grey, etc. (just like you do with stick and stickC) and have that toggle load the appropriate on board hardware blocks. What about a block that exposes the hall effects sensor too while you are at it. I guess I feel like expose it all since it encourages development and you never know what someone makes with it. At the very least it helps encourage learning and ease of use which seems like the point of block based visual coding.

[m5-docs]

@jpilarski Thanks a lot! I will tell the engineer about this need

[Isabelle]

Hello,

meanwhile it is possible to use the block "analog read pin (34)" from the blockpack "Easy I/O".
So I was able to bild the probram from user M5DOCS just with UIFLOW.

Unfortunally it just shows Numbers between 450 and 600 or so. And it dows not react to any sounds.

This is the python code of the blockly program:

=====
from m5stack import *
from m5ui import *
from uiflow import *
from easyIO import *

setScreenColor(0x222222)

label0 = M5TextBox(122, 84, "Text", lcd.FONT_DejaVu24,0xFFFFFF, rotate=0)

while True:
label0.setText(str(analogRead(34)))
wait_ms(100)
wait_ms(2)

What did I do wrong?