For a project I need wps support in the nodemcu firmware. To enable that I have added wifi.wps.* commands in app/modules/wifi.c and I have added -lwps to the Makefile in app. All builds well, but after flashing the firmware I get problems in that the firmware reboots in a loop.
Commenting out the calls to libwps.a and only having the lua commands in place makes the problem disappear. Is there a know issue, why there is no wps support in nodemcu?
I have a clone of the nodemcu git repository and a docker build environment for building the firmware.
Arnulf
Found the problem myself. There seems to be a limit of the firmware size of 512 KB. I removed some modules when building to stay under that limit and then all worked as expected :)
Found out that if I use the ESPTOOL_FS environment variable of esptool.py to set the correct flash memory size, the firmware size can be greater than 512K and there are no problems starting the module.
Related
Im having a hard time getting hardware acceleration for videos working in electron running on Linux (ARM64) and Linux (Intel64). Im not sure if this is an issue with the flags electron is using for chromium or if its more an issue at drive level on the host machines. Or maybe it's just not possible. Both machines are running Chromium 95 snap 64 bit.
When running chromium (ARM64) without any flags and running chrome://gpu i get the following:
When running chromium (ARM64) with --enable-features=VaapiVideoDecoder i get the following:
This leads me to believe that when calling chrome with the flag hardware acceleration should be working. Just to add to the complexity of this if i go to youtube and check media it looks like it may still be disabled (even with the flags):
I have read through a number of articles titled 'how to enable hardware acceleration in electron'. Most of which list the following flags to provide:
app.commandLine.appendSwitch('ignore-gpu-blacklist')
app.commandLine.appendSwitch('enable-gpu-rasterization')
app.commandLine.appendSwitch('enable-accelerated-video')
app.commandLine.appendSwitch('enable-accelerated-video-decode')
app.commandLine.appendSwitch('use-gl', 'desktop')
app.commandLine.appendSwitch('enable-features', 'VaapiVideoDecoder')
I have tried all of these but nothing seems to make any difference. When running a video in electron it has the following properties:
Is anyone able to point me in the right direction with this? Thank you.
This has been solved. The main issue was the VaAPI driver needing to be installed on the hardware running the application. Secondly the only flags needed was the following:
app.commandLine.appendSwitch('enable-features', 'VaapiVideoDecoder')
For all of these scenarios, I am able to upload the firmware and monitor via serial usb. But after creating my first firmware, for all new firmware, I can't upload Lua scripts using the nodemcu-tool without getting the following:
Error Message
F:\Development\NodeMCU\helloworld>nodemcu-tool -p COM3 upload init.lua
[NodeMCU-Tool]~ Unable to establish connection
[NodeMCU-Tool]~ Invalid node.chipid() Response: 6935962
Observations
Can reset the board using nodemcu-tool. Leads me to assume the baud rate is fine.
Can see the file system being created from PuTTy after loading any of the firmware. Leads me to assume the firmware is OK.
Have tried multiple dev boards, same results
Found the source of the error message device-info.js. either line 45 or 49
I have no idea what "Response: 6935962" means. Is that my chip id or an error code?
A new commit was made to the firmware source during the last couple of days. No idea if this is relevant.
Was hoping to get this resolved before I go down the Docker rabbit hole. Lazy. I know.
9/6/2019 - created first firmware to start development
Built a firmware using https://nodemcu-build.com/ with these modules (cron, file, gpio, i2c, mdns, mqtt, net, node, sjson, tmr, uart, wifi)
Uploaded the firmare using NodeMCU-PyFlasher-4.0
No issues with this firmware. I've been able to upload lua scripts and test them successfully. Even now, I can revert back to this firmware and use it without issues. I've even redownloaded this firmware from the original link, and it works fine.
9/7/2019 - created a new firmware to use adc and other goodies
Built a firmware using https://nodemcu-build.com/ with these modules (adc, cron, file, gpio, i2c, mdns, mqtt, net, node, rtctime, sjson, tmr, uart, wifi)
Uploaded the firmare using NodeMCU-PyFlasher-4.0
Having the problem described above.
9/8/2019 - built firmware with minimal modules
Built a firmware using https://nodemcu-build.com/ with these modules (file, gpio, net, node, tmr, uart, wifi)
Uploaded the firmare using NodeMCU-PyFlasher-4.0
Having the problem described above.
Platform & Tools
Windows 10
Development board: HiLetgo ESP8266 NodeMCU LUA CP2102 ESP-12E Internet WiFi Development Board Open Source Serial Wireless Module
Firmware builder: https://nodemcu-build.com/
Serial Monitor: PuTTy 0.72
Firmware Loader: NodeMCUPyFlasher 4.0
Lua script loader: nodemcu-tool 3.0.2
fetchDeviceInfo() first calls node.info() at https://github.com/AndiDittrich/NodeMCU-Tool/blob/master/lib/connector/device-info.js#L9. Then it does an if-else to figure out whether it's running on ESP8266 or ESP32.
With the recent upgrade to SDK 3.0 node.info() was changed in PR #2830. See documentation at https://nodemcu.readthedocs.io/en/latest/modules/node/#nodeinfo. It now returns values the script doesn't consider to be coming from ESP8266. The script then calls node.chipId() in the else branch. So, it's getting a chip id from ESP8266 but it is expecting one from ESP32. Hence, the exception.
I have no idea what "Response: 6935962" means. Is that my chip id or an error code?
It's your chip id.
To cut a long story short: NodeMCU-Tool needs to be adjusted as laid out above to work with the current NodeMCU version.
I cached the same issue from the recent cloud build(https://nodemcu-build.com/). It works when i switch back to the old ones. It looks like a problem of the build system or recent source code. You can switch to other build method and try use the older code.
Background: We are looking to release a commercial product based on the Android Things OS and Pi 3 hardware. The OS seems to become corrupt over time. Usually after several weeks of continuous testing. By corrupt, the Android screen will no longer appear on startup and putting SD into new hardware does not remedy. We are using an application Factory Image base on the 0.5.1-devpreview created in the Console.
My question: Is there a way to debug or monitor what caused this state in the OS? Direct serial connection?
try to clean the sd card with the diskpart command and start again from scratch.
And to debug, maybe a USB to TTL cable may help. As explained here.
Regards!
I added my driver in wince 6.0 platform builder. It compiles sucessfully and added in nk.bin(i checked manully by open nk.bin in vs2005) also reg file contaning that driver enrty. I did below processure to add my driver.
Copy driver code into “$(_TARGETPLATROOT)\Files\MyDriver”
Add below line at “platform.bib”
MyDriver.dll $(_TARGETPLATROOT)\Files\MyDriver\MyDriver.dll NK SHK
Add below line at “platform.reg”
#include "$(_TARGETPLATROOT)\Files\MyDriver\MyDriver.reg"
But when I flash that, nk.bin. driver is not loaded on board. I checked with tool which help to check which driver loaded on board.
Does anyone have idea about that?
We have no idea what is in mydriver.reg, so if there's a problem there, or the resulting platform.reg, then that could be an issue.
There are a few ways to diagnose this problem. The first step would be to check ce.bib and platform.reg and make sure the expected entries are there. If the driver or it's registry entries are not ending up in the OS, that would cause a problem.
If that looks good, then there are two steps you can take.
Build a Debug version of the OS, copy the debug version of device.exe into the FLATRELEASEDIR of a Release build and call makeimg. This will give you a release build with a debug version of device.exe. Boot up and look at the debug messages for when it attempts to load the driver and look at the report of the failure.
Create a simple application that calls ActivateDevice and look at the return value from it. Outputting debug messages from the driver in DllMain and XXX_Init is usually helpful as well.
I've installed JDK, Android SDK and Mono Android for Visual Studio 2010, I've created an empty solution and I got the emulator up and running with Android 2.3.3 - so far so good.
When I try to deploy (F5) the app to the emulator, it connects to the emulator, and all goes fine until it starts "Installing the platform framework". Then it loads for several minutes, and finally throws an exception that looks like this:
I have tried googlin' it, but the INSTALL_FAILED_MEDIA_UNAVAILABLE doesn't seem to be described anywhere else.
I don't know if this is an important detail, but on my PC I have remapped my home folders (Documents, Favorites, Desktop, etc.) to folders like "D:\Mikkel\Dokumenter". It seemed to cause some problems when starting the emulator initially, but after adding the environment variable "ANDROID_SDK_HOME" pointing to "D:\Mikkel.android" the emulator started up with no problems.
Please advise.
Ensure that you have enough internal and external free space in your device. You can determine the free space available with the command:
$ adb shell df
Filesystem Size Used Free Blksize
/dev 192M 32K 192M 4096
/mnt/asec 192M 0K 192M 4096
/mnt/obb 192M 0K 192M 4096
/system 145M 124M 20M 4096
/data 196M 167M 29M 4096
/cache 95M 32M 62M 4096
/mnt/sdcard 3G 177M 3G 32768
In the above output, /data (which is the default install location) has 29MB free, while /mnt/sdcard (the SD card, and the external install location) has 3GB free.
For Debug builds, you need to have ~40MB free (for the Runtime package, Platform package, and apps). Release builds are significantly smaller, but Release builds cannot be created with the Evaluation version.
It's plausible that if your emulator doesn't have an SD card, then Android would generate the INSTALL_FAILED_MEDIA_UNAVAILABLE error. (To add an SD card to your emulator, start the android app, go to Virtual devices, select a device, click Edit, and look at the SD Card section.)
A cursory grepping of Android suggests that DefaultContainerService.java is the controlling factor, specifically DefaultContainerService.recommendAppInstallLocation(), and that if you're out of internal space and the package specifies auto (as Mono for Android does) and the SD card is unavailable (status.equals(Environment.MEDIA_MOUNTED) is false), then RECOMMEND_MEDIA_UNAVAILABLE is returned, which is translated into INSTALL_FAILED_MEDIA_UNAVAILABLE. This still seems odd to me (wouldn't RECOMMEND_FAILED_INSUFFICIENT_STORAGE make more sense?), but this appears to be what's happening.
Possible Problems :
No Internal/ External space in the Drive(or sdcard).
Connection is lost during the installation (apk to device or emulator).
Solution :
Try to create some space( remove some apps).
Try to reconnect the phone/emulator restart (worked for me)
This can be caused by having insufficient space on the device. So it goes looking for an SD card to install on to instead. if that isn't there it will trigger this response.
I had this problem even with 1GB of free space and an .apk of 1,5Mb. What I did was building an .apk and moving it to data/app folder. This worked for me. The problem is that I think your device must be rooted in order to access this folder.
I've solved the problem - it seems that if you close the (weird) empty DOS prompt that opens when the emulator is started, the connection to the emulator is lost.
Leaving the DOS window open, everything works like a charm.
In my case, it helped me out to switch the usb connection mode. You have to "just load" the device by usb instead of providing the sd card to the pc file system.
INSTALL_FAILED_MEDIA_UNAVAILABLE
Because of low memory. Delete unnecessary files and apps.
This problem appeared for me when I installed Facabook app on my phone. so I uninstalled it and problem solved.
It is due to not enough space on the phone.
Check your build packaging In my case it was packiging all kinds of assets, psd, etc.. and the .apk file was huge and the phone did not have that much space