Have an issue with mBot and 2.4G dongle.
Device is mBot V1.1 WiFI 2.4G.
Using original SW mBlock v3.4.11
Having operating system Windows 10
I can control mBot via Wireless dongle by keyboard, but cannot upload code. I get error:
avrdude: ser_open(): can't open device "HID": The system cannot find
the file specified.
I do not know what to do. I am not a programmer.
Please help me to enable it for my son.
I recommend that you use the latest version of mBlock:
https://mblock.makeblock.com/en-us/download/
However, if you do not wish to download it, you can use the mBlock web IDE:
https://ide.mblock.cc/
Make sure that you are connecting to the right port, too. If you are connecting to a port named “Com1”, you are most likely connecting to the wrong port.
Also, be sure to ask your question on the official mBlock Forum:
https://forum.makeblock.com/
I've found a similar topic on there here:
https://forum.makeblock.com/t/code-not-uploading-to-my-mbot-ranger/20879/
Thanks for your time,
Best Codes
Related
After upgrading to Windows 11 I realize that there is no COM-Port to connect to, as it has become legacy software. And now I cannot find my device connecting through a USB port anymore
As I try to install the driver again, there was errors. Seems like some software to install driver is missing. It also said that even if the driver is installed, they might not be installed correctly.
And now when I try to connect my device and use pyserial on it it can not recognize any ports free to use. When I connect my device, it seems that they don't appear at Ports(COM and LPT) anymore, but instead in in Universal Serial Bus Controller. Still pyserial have problem to find available COM and my peripheral devices also cannot be found(As I think they often try to find COM port to connect to) What can I do to solve this? Please specify any clarification if you find my question somewhat misleading. Thank you in advance and have a great week!
I'd like to know if it is possible to establish communication via a serial port in an Ubuntu for W10 terminal using the USB interface.
Concretely, I am using a Sparkfun edge board and in this tutorial, it is explained how to detect if the device is connected by checking /dev/tty*. However, it does not work in my testbed, nothing new appears in the directory.
Probably, it is related to using Ubuntu over Windows, but I'd like to be sure before moving to another system.
This is a bit old, but it should've worked then... New devices don't show up in the directory, they're already all there, so you need to know what COM port it's on, let's say it's on COM4, then your device will be /dev/ttyS4 in linux.
I've been using this for well over a year to upload files to my MCU boards kinda like what you want to do, and as long as the device shows up as a COM interface in Windows, and isn't in use, you should be able to connect it to it in WSL as /dev/ttyS[COM#].
Hope this helps, even if it's a bit delayed.
I'm really having trouble connecting to my ESP8266. I was working with this setup for long time now and I didn't have to flash my boards. Now after having to use a different wifi i needed to flash the board. After doing the following
Updating to the newest ConfigurableFirmata
Using FirmataBuilder to download fitting firmata
Uploading the Firmata to the ESP8266
I can't connect via Johnny-Five anymore (getting the usual timeout error). I couldn't narrow down what it exaclty is (and I have been trying all day) but these are things that I have noticed (Using ConfigurableFirmata directly as well as using firmatabuilder and StandardWifiFirmata, all with the same behaviour)
an open Hotspot gets created even though I'm in Client Mode
when scanning for ports I do find the Module connected to my Wifi (Serial Monitor in Debug tells me the same too) but no open port is found, even though it's specified in the firmata.
I just can't narrow down the reason. I hope you guys can.
OK,
this was a simple user mistake. But since I lost a whole day searching for the error and I think others might too, I'll share my mistake here.
As I pointed out I created the Firmata as Client (thinking its a client to my Hotspot). But you will have to create it as a server (as you want to connect to the board)
It's as simple as that. If you are on http://firmatabuilder.com/ make sure you choose TCP Server if you want to connect to your board.
How do you enable the linux kernel driver for a network adaptor based on a 81ry52 chip?
The development board I'm using states the support is enabled by default. It implies this chip is popular. However it is not working, I can see the USB device is inserted but no network interface is created. And I could not find the adapter/chip model in the kernel source. Nor much information could be found on the net either.
So far, this model of the USB to network adapter does not work for Linux. The comments following the original question have many insights and shared experiences on USB in general. There might be many things to be fixed but not clear for now. I'll keep these in mind and hopefully explore more and find out a solution.
Though if somebody else find out a solution. I'll be very glad to know.
I purchased a BLED 112 dongle from BlueGiga (http://www.bluegiga.com/BLED112_Bluetooth_smart_dongle). I purchased the dongle since I was trying to do a simple POC with an iPhone. I did not want to get into breakout boards or the dev kit just yet.
I am trying to get the heart rate monitor samples working and I am not sure how to load the firmware on the device. I am using the latest version of the SDK (v1.1.1) which states to use the BLE Update tool, not the TI Flash Tool.
However it looks like you need the CC Debugger with the BLE Update Tool to update the SOC. I looked at the CC Debugger and it does not appear to be designed to be used with BLED 112 USB dongle. It appears you need a breakout board to expose the pins to be able to hook the CC Debugger to a BLE 112 module, not a BLED 112.
Lastly, I am not sure if DFU will work without bricking the dongle.
Any advice on how to properly use and program the BLED 112?
Thanks,
G
From the SDK docs:
TI Flash tool should NOT be used with the Bluegiga Bluetooth Smart SDK
v.1.1 or newer, but BLE Update tool should be used instead. The BLE112
and BLE113 and BLED112 devices contain a security key, which is needed
for the firmware to operate and if the device is programmed with TI
flash tool, this security key will be erased.
It is possible to update the firmware on the BLED112 via the USB connection, and without requiring a breakout box or a CC Debugger. However, it is fairly easy to accidentally 'brick' your device in so doing. The problem is that the firmware itself needs to provide the interface to enable DFU mode; if you do an update with your own firmware, and your firmware doesn't provide this capability, you're stuck with the last thing loaded on it.
That being said, here's the process.
The BLED112 dongle is essentially just a BLE112 with an attached USB connection. The BlueGiga SDK ships with drivers that allow the device to be mapped with a simple serial interface, such that the device shows up as a simple COM port (e.g., "COM16") to applications running on the host PC. The SDK also ships with two utilities - BLEGUI, and DFUTOOL - that are able to use this COM port interface to communicate with the device.
(Getting the drivers installed seems like it should be easy, but the process was finicky for me, and I ended up having to mess around with Device Manager, etc., for a while before getting the COM port to show up reliably when I attached the dongle.)
The basic process for building and installing firmware on the BLED112 is:
Compile your BGScript program to an image file using BGBUILD.EXE
Reboot the dongle into firmware update (DFU) mode using BLEGUI2.EXE
After attaching to the appropriate COM port, select Commands | DFU from the menu.
Update the firmware using DFUTOOL.EXE
Before you do this, make sure you read the "Developing Bluetooth 4.0 single-mode applications" and other technotes from BlueGiga's forum (registration required). Specifically around your project configuration:
WARNING:
If the firmware is to be installed into the BLED112 USB dongle the USB
CDC configuration MUST BE included in the project file. If this is not
included in the project file and the compiled firmware is installed
into the BLED112 USB dongle, the USB interface will be disabled and
the dongle stops from working.
Phew. Not necessarily for the feint of heart. I personally found it more appealing to shell out the money for the DKBLE112, which has the BLE112 module mounted on a board with some other accessories, and a CC Debugger for programming. With this setup, you can flash new images to the chip without worrying so much about screwing things up (there's a "reset" button on the board itself).
Other people have reported using breakout boards that are cheaper than the DKBLE112, such as this one from Jeff Rowberg. They also let you program with the CC Debugger, but I have no experience with them.
Have fun!
Based on the information provided, I found the following technote on the BlueGiga support knowledge base.
https://bluegiga.zendesk.com/entries/22810076--HOW-TO-Run-a-BGScript-application-on-the-BLED112-USB-dongle
Thanks
Greg