Hello All,
Can the I/O's for the LED's connected to the NINA pins 16 and 17 be exposed?
I don't see any lib functions and/or calls that will currently work.
Maybe it's possible to link in another ESP32 lib - haven't looked at that yet - but just simple I/O control
of the GPIO's on the NINA will allow this.
I imagine this has been posted/requested someplace already - sorry my Google foo isn't up to par if so.
Thanks In Advance,
John W.
Hi,
yes those can be exposed by creating a custom FPGA image that routes those pins somewhere else.
note that these are now connected to the LED...
What I checked from schematics WM.WM_PIO16+17 is connectec only to NINA. There are other WM.WM_PIO pins that are connected to FPGA and these can be routed to SAM or connector.
jwestmoreland:
Hello All,Can the I/O's for the LED's connected to the NINA pins 16 and 17 be exposed?
I don't see any lib functions and/or calls that will currently work.
Maybe it's possible to link in another ESP32 lib - haven't looked at that yet - but just simple I/O control
of the GPIO's on the NINA will allow this.I imagine this has been posted/requested someplace already - sorry my Google foo isn't up to par if so.
Thanks In Advance,
John W.
Unless there's a mistake in the schematic - these pins are ONLY connected to the NINA device - so, that firmware has to toggle these pins.
So, the question still stands, and, these two pins ARE NOT connected to the FPGA.
There needs to be and/or should be a GPIO function exposed at the user level to toggle these pins via the NINA. That means a command has to go across the SPI bus to tell the NINA to turn the BLUE and GREEN diodes on and off.
Thanks,
John W.
I suppose it should be possible to put something like the following as a quick test in cpu_start.c and making a build with the esp tools:
#define BLINK_GPIO1 16
#define BLINK_GPIO2 17
void blink_task(void pvParameter)
{
/ Configure the IOMUX register for pad BLINK_GPIO (some pads are
muxed to GPIO on reset already, but some default to other
functions and need to be switched to GPIO. Consult the
Technical Reference for a list of pads and their default
functions.)
/
gpio_pad_select_gpio(BLINK_GPIO1);
/ Set the GPIO as a push/pull output /
gpio_set_direction(BLINK_GPIO1, GPIO_MODE_OUTPUT);
gpio_pad_select_gpio(BLINK_GPIO2);
/ Set the GPIO as a push/pull output /
gpio_set_direction(BLINK_GPIO2, GPIO_MODE_OUTPUT);
while(1) {
/ Blink off (output low) /
gpio_set_level(BLINK_GPIO1, 0);
gpio_set_level(BLINK_GPIO2, 1);
vTaskDelay(1000 / portTICK_PERIOD_MS);
/ Blink on (output high) */
gpio_set_level(BLINK_GPIO1, 1);
gpio_set_level(BLINK_GPIO2, 0);
vTaskDelay(1000 / portTICK_PERIOD_MS);
}
}
sorry for the confusion, yes those pins are connected only to the Nina module so you have to alter its firmware to do that. right now that is not yet open source and keep in mind that unfortunately if you modify it you will lose certification.. one thing we may do in the future is exposing APIs to remotely request these pins to be set/cleared from the SAMD side.
Dario,
OK - I don't want to open this Pandora's box - but in the US if you are a licensed radio operator (also Ham) - even though this is ISM and one can claim they aren't fiddling with the TX power you are SUPPOSED to be OK to do this since as a licensed radio operator you are supposed to understand these things.
Notwithstanding the FCC stomping my guts out on this - I think it's OK for experimental purposes and one's own household types of projects.
Something that goes out into the 'wild' - that's a completely different story - maybe.
That aside - I was looking at the BluetoothSerial sketch - seems that's not too far for what's needed.
Regards,
John
I think you need FCC stomping if you want to sell "any" electrical deivice in US. With serial communication you can cause unintentional radiators that are under FCC 15.101-15.123.
I'm not sure how they handle things if customer modify it but if you want to use it in product and sell it in US then you have to do FCC required measurements and approvals.
I recommend also to do EMC measurements because you can cause nice RF noise with FPGA IO:s and these can fail your FCC approval measurements. Also use small serial resistor in serial data transmission for eliminating fast transients if you use long cables. Without serial resistors these can cause EMC noise.
BTW: did you also measured customer worstcase image in FPGA with 5-20cm cables to receivin device. I think that should fail masurements. Maybe in good main PCB design hispeed IO:s are fine or in matal box.
Edit:
computers are part of FCC 15.101-15.123. Also SMPS requires FCC.
Getting back to my response to what Dario was implying:
Several of the FCC part 15 rules govern the transmit power permited in the ISM bands. Here is a summary of those rules: Maximum transmitter output power, fed into the antenna, is 30 dBm (1 watt). Maximum Effective Isotropic Radiated Power (EIRP) is 36 dBm (4 watts).
And, according to the attached - it looks like it's not even possible to get into any trouble with the NINA modules.
Yes but if you want to sell then you have to do FCC required approval measurements and cerification. With Arduino provided firmware you don't have to do these for Nina.
Hi guys,
things are a bit crazy when you talk about certifications. there are several issues and emitted power is only one of those. for one ISM bands require a balance between power and duty cycle, secondly if you say you're compliant to BT or WiFi you should also be compliant at protocol level.
now, of course if you modify the code and you are just doing it at your place it' likely to be fine however there are cases when this may become an issue anyway such as when a few weeks ago customers of a store in the US could not open or close their cars due to a radio gone wild.
so, having said this Nina firmware at some point will be released open source so you'll be able to do whatever you please but i can't say at the moment when this is going to happen
