Since I cannot get the manifold 2 in my region, I created a cable according to https://forum.dji.com/forum.php?mod=viewthread&tid=219723.
The cable is connected via FTDI converter directly to the drone's OSDK port.
when connected to a serial terminal application I get data from the drone
Terminal
When I try to debug the flightcontrol-sample in Linux, I get the following:
LinuxOutput
Data is also received in Linux using 'screen' command.
testing the cable for 'loopback' works fine.
I have changed the port baud rate to several options (230400 & 921600) to no avail.
the ACM cable is connected through an additional USB port to the drone's port directly.
Am I missing some HW components in my setup?
I have entered all the relevant Linux commands to get the required permissions as advised in
https://developer.dji.com/onboard-sdk/documentation/quickstart/development-environment.html
&
https://developer.dji.com/onboard-sdk/documentation/quickstart/run-the-sample.html
Am I missing something in that department?
The final goal is to use STM32 as FC, but testing is easier using the Linux environment.
Any additional things I can test?
Are there other working setup designs I can try?
Thanks for your help.
i got M300 osdk connection up at Apr 2020.
So far not many issues. There are many tricks and rules that you need to follows e.g osdk adapter board usb type C seam side face inside. make sure osdk adapter board is powered up by checking the output supply voltage. 3.3V FTDI. and make sure it is pull up properly by checking voltage as well
After you check through the hardware.
the software has many tricks as well. for M300 only osdk/osdkros 4.0 and above can drive. The new userconfig.txt format changed and you have to change accordingly. and you can go through my checklist which I posted on DJI forum https://forum.dji.com/forum.php?mod=viewthread&tid=216529
If you really still have a problem. do provide photos on your connection, the terminal output for the error message.
As Dr. Yuan suggested, have a look at the UserConfig.txt file. Depending on which OSDK version you are using, it has a different format.
In my case, using osdk 3.9 configuring it this way solved my issues:
app_id : xxx (number)
app_key : xxx (number)
device : /dev/ttyUSB0
baudrate : 230400
Also check your FTDI cable, it once burned out for me and it was the reason for this error too. You should try a new one just in case.
I use the OSDK with a raspberry pi, in case you are using this kind of linux environment, I suggest you check the configuration files (cmdline.txt and config.txt) doing sudo nano /boot/cmdline.txt and same for config.txt.
my configuration for cmdline.txt is:
dwc_otg.lpm_enable=0 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait
And for config.txt just add this at the end:
enable_uart=1
init_uart_clock=64000000
start_x=1
I hope these can help and that I am not too late.
Related
Finally the sparkfun board edge boards arrived today ;-)
Following this well written guide : https://codelabs.developers.google.com/codelabs/sparkfun-tensorflow/#3 i am stuck with the following NoResponseError when trying to flash the code on the Ambiq, with the uart_wired_update.pyscript, that comes with tensorflow examples
opprud$ python3 tensorflow/lite/experimental/micro/tools/make/downloads/AmbiqSuite-Rel2.0.0/tools/apollo3_scripts/uart_wired_update.py -b 115200 /dev/cu.usbserial-1430 -r 1 -f main_nonsecure_wire.bin -i 6
MOJ/Connecting with Corvette over serial port /dev/cu.usbserial-1430...
Sending Hello.
No response for command 0x00000000
Traceback (most recent call last):
File "tensorflow/lite/experimental/micro/tools/make/downloads/AmbiqSuite-Rel2.0.0/tools/apollo3_scripts/uart_wired_update.py", line 336, in <module>
main()
File "tensorflow/lite/experimental/micro/tools/make/downloads/AmbiqSuite-Rel2.0.0/tools/apollo3_scripts/uart_wired_update.py", line 38, in main
connect_device(ser)
File "tensorflow/lite/experimental/micro/tools/make/downloads/AmbiqSuite-Rel2.0.0/tools/apollo3_scripts/uart_wired_update.py", line 58, in connect_device
response = send_command(hello, 88, ser)
File "tensorflow/lite/experimental/micro/tools/make/downloads/AmbiqSuite-Rel2.0.0/tools/apollo3_scripts/uart_wired_update.py", line 235, in send_command
raise NoResponseError
__main__.NoResponseError
My setup:
Macbook pro, tried both old 15" & new 13"
Sparkfun serial basic breakout, USBC version (default jumped to 3v3)
FTDI 3v3 serial cable
I have tried
two different edge boards, with the correct Key14 & reset combo + misc variants and timing
legacy USB on old Macbook
new Macbook w USB C
FTDI 3v3 serial cable as alternative to sparkfun serial board
Running an alternative uart_boot_host.py script in tensorflow/lite/experimental/micro/tools/make/downloads/AmbiqSuite-Rel2.0.0/tools/bootloader_scripts/uart_boot_host.py, also no response
I can measure, with a scope, the handshake bytes '0x14', '0x55', '0x9d', '0xe9' '0x0', '0x0', '0x8', '0x0' being transmitted initially at 115200 on the TXO pin on the programming header - but the ambiq is not replying anything.
btw. The onboard demo is running, blue led flashing, an some "yes's" are being recognized.
Any inputs welcome.
Does anyone know the protocol for the corvette bootloader ?
Are there any CPU revision changes from the first batch of boards, or possibly any lock bits programmed accidentally from sparkfun ?
rgds from an eager TF lite user ;-)
I tried measuring the actual baudrate with a scope on rx/tx pins, and saw that the bit timing using default OSX serial driver is rather imprecise, app 10% off, causing faulty readings, and ultimately missing bytes, when the baudrate are high.
After updating to the ch340 serial driver, timing improved, and the bit timings were correct.
At 921600bps, a single byte 8N1 is supposed to be10.9uS
Driver install
https://github.com/adrianmihalko/ch340g-ch34g-ch34x-mac-os-x-driver
This is what worked for me: (source: github.com/sparkfun/SparkFun_Edge_BSP/issues/3, the SparkFunEdge tutorial and my teammates!). I am running this on a Linux machine (x86_64; Run $ uname -a) and my SparkfunEdge DEVICENAME=/dev/ttyUSB0
The tutorial does warn you about this problem at Step 4:
Note: Some users have reported issues with their operating system's
default drivers for programmer, so we recommend installing the
driver before you continue.
Click on the driver link and follow the instructions under "Other Linux distributions" as follows:
Install the correct version of the ch34 library.
$ git clone https://github.com/juliagoda/CH341SER.git
$ cd CH341SER/
$ make
$ sudo insmod ch34x.ko
$ sudo rmmod ch341
To verify that the correct driver is being used, run:
$ dmesg
..
[889247.585301] usb 1-7: ch341-uart converter now attached to ttyUSB0
[955698.718839] usbcore: registered new interface driver ch34x
[955698.718848] usbserial: USB Serial support registered for ch34x
[955759.196437] usbserial: USB Serial deregistering driver ch341-uart
[955759.196576] ch341-uart ttyUSB0: ch341-uart converter now disconnected from ttyUSB0
[955759.196601] usbcore: deregistering interface driver ch341
[955759.196643] ch341 1-7:1.0: device disconnected
Now unplug the USB-C from the SparkfunEdge Board, and plug it back again
$ dmesg
....
[955876.176950] ch34x 1-7:1.0: ch34x converter detected
[955876.177320] usb 1-7: ch34x converter now attached to ttyUSB0
glad to hear that you're so excited about the board. I have a hunch that this will be an easy fix.
The Edge boards handed out at the conference have a bootloader set for 115200 baud, however the Edge boards that have come out in the second batch are upgraded to flash at 921600 baud, greatly reducing flashing time. Try changing the baud rate in your serial upload script.
You can also set up the Ambiq Software Development Kit to write your own applications for the Apollo3 microcontroller. Check out the tutorial here: Using the Edge Board with Ambiq SDK
Since I can't comment on your post (not enough reputation.... thanks SE) I'll be responding here.
If the baud rate accuracy is a problem I'm slightly unsure that that would be caused by the OS, but rather I'd think it is a problem with the USB-serial converter chip. I've been using the CH340G whereas on the USB-C version there is the CH340C IC. The difference between the two is that the "C" version includes an internal oscillator to provide the frequency reference. It is possible that that one is less accurate...? I'll try it out over here (but on windows) and let you know.
If this is a persisting problem would you mind making a post on the SparkFun forums? That way our tech support can get linked in (they are the people who could get you replacement hardware in case it is defective, also). Here's a forum for the Edge: SparkFun Edge Forums
If the problem is coming from the OS then the only fix that we can do with the Edge is to reduce the bootloader speed. We're working on a short tutorial about how to do that, but it would require having a programmer/debugger for Cortex-M processors. The Ambiq Apollo3 Evaluation Board has a built-in SEGGER J-Link which is what we used to program the boards.
On MacOS Mojave, Installing/Reinstalling CH340 works for me:
https://learn.sparkfun.com/tutorials/how-to-install-ch340-drivers#mac-osx
Before doing install, check that you actually see the sparkfun edge device with:
ls -l /dev/cu*
If driver is correctly installed, you should detect:
/dev/cu.wchusbserial1420
I got similar issue whereas I only had /dev/cu.usbserial-1420 and thought that was expected device to access, whereas it is /dev/cu.wchusbserial1420 which was only detected after installed ch340 driver.
Then flashing device works successfully for me.
I'm new with NodeMCU firmware use. I have a Amica ESP-12E (v2?) dev kit connected to a DHT22 which I program using the Arduino IDE. All is setup and working fine.
My problem came when I wanted to update NodeMCU firmware. Since I don't really know what came pre installed from China, I downloaded ESPlorer to try to determine NodeMCU version. I get the following "error" when I reset the dev board:
Communication with MCU..Got answer! Communication with MCU established.
AutoDetect firmware...
Can't autodetect firmware, because proper answer not received (may be unknown firmware).
Please, reset module or continue.
{{a long string of weird characters that I can't copy and paste appear here}}
At this point I'm totally clueless about what version of firmware I have. Is there a way to obtain NodeMCU firmware version by software via Arduino IDE code, ESPlorer GUI or something similar?
On the other hand, is there a really easy way to compile/download latest NodeMCU firmware BIN file? Even one with all the modules active will be fine for me now, I'm just trying to understand and test things.
You seem to be confusing two very different platforms. I leave out some details as not to confuse you any further.
Arduino: you use Arduino programming in the Arduino IDE then build and install a binary to your device whenever the application changes. No NodeMCU firmware needed!
NodeMCU: you flash the NodeMCU firmware once (e.g. using esptool.py) and then upload Lua code (e.g. using ESPlorer) whenever the application changes. This is more lightweight than the Arduino platform.
On the other hand, is there a really easy way to compile/download
latest NodeMCU firmware BIN file?
Yes, have a look at the NodeMCU documentation at http://nodemcu.readthedocs.io/en/latest/en/build/. The easiest is to use the cloud builder at https://nodemcu-build.com/. I currently suggest to build from the dev branch because flashing is easier with it.
As pointed out you have several options for firmware and you'll need to make a choice as to which suits you going forward. If you are going to stick with the Nodemcu LUA firmware you can determine the version by typing:
print(node.info())
at the command line prompt.
There are alternatives to using ESPlorer e.g. Putty or Coolterm that will give you the raw output from the device with no interpretation. So if you have the correct serial port settings and the device plugged into the USB port it will show the banner when you reset giving an indication of the origin and version of the installed firmware.
In ESPlorer, there is an option under settings which if unchecked will stop looking checking for the version of the code.
For whatever reason, ESPlorer is not designed to read nodemcu version.
The error message throws you off, could lead you to think, there is an error.
At best, the above error can be ignored. It has no impact at all. In background, init.lua is up and running.
I'm having trouble with an industrial Linux computer I'm working with to achieve communication over an RS485 bus with multiple connected devices. What I've encountered is that the IO pins used by the RS485 USART driver are set to different levels at startup instead of going to the RS485 idle/tri-state. As a result, the other devices on the bus are blocked for more than 30 seconds while the device boots up, triggering all sorts of external problems. The course of events can be viewed in the attached image, where I've measured the output voltages with an oscilloscope during startup.
My guess is that the actual driver is not started until the voltage levels reach their tri-state levels (e.g. ~2.2V for this device). After that everything works as expected.
I've tried to find any config-files to set the default IO level of the pins at boot (thinking this may be set by the bootloader) to no avail.
Also, I've tried to apply a startup-script to run "early enough" to set DATA- high, but the device in question does not provide any interface to control these pins as regular GPIOs as far as I can tell.
Any help, tips or insights would be much appreciated!
EDIT: I am not an experienced Linux developer, so please highlight if I've left out any important details.
Some specs:
ARM920T rev 0 (v41) CPU
Proprietary distribution of Linux 2.6
Uses Busybox
Atmel USART drivers
Extract from boot log:
Linux version 2.6.28.10 (root#) (gcc version 4.1.2) #94 PREEMPT Tue Oct 29 10:22:19 CET 2013
CPU: ARM920T [41129200] revision 0 (ARMv4T), cr=c0003177
/...
.../
RS485 mode for port /dev/ttyS3 enabled
/...
... (I'm guessing the ~30 secs elapse here)
.../
atmel_usart.3: ttyS3 at MMIO 0xfffcc000 (irq = 9) is a ATMEL_SERIAL
atmel_serial.3: Putting the RS485 RTS pin down
/...
...
.../
Full boot log: https://drive.google.com/file/d/0B2XYl1mNCa8jNUZ5V0Nic1hkU0U/view
Similar issue:
Possibly a similar issue is discussed here: UART initialisation: Prevent UART to pull RTS high
But I'm not sure how to proceed with the suggested solution.
This is little more than wild speculation, but it might be worth adding a start-up script that echoes a NULL character to the device (e.g. /dev/ttyS1 or whatever) as early as possible during start-up. This might be enough to kick the driver into initialising the hardware.
You could also try to locate the driver in the Linux source to look at how it starts up.
Probably you have access to the source code, so you can investigate who and when mess with the that GPIO. Just grep the kernel source for the atmel gpio controller port addresses to figure out what happen. If you are lucky may be there will be kernel command line option that you can pass from the bootloader to set the line to what you need in advance.
this answer may work if you can find required things mentioned below
of your board!
Once I also had a same issue on PWM. There I found that my bootloader was responsible for the same, I changed in bootloader configuration and it started working fine.
Check your BSP provided by board vendor or third party (If you have the source), If your bootloader is U-boot you can find it inside U-boot-(source)/include/configs/(your-board).h there you can find configuration for RS484. As per your datasheet for the board you can check for other things which are muxed on the same pin and disable those if not required for boot time and enable RS485.
enabling/disabling can be done by changing the values 0, 1 or 2 as per your configuration and also you can simply disable anything just by commenting // out the line.
I am using a buildroot image (3.12 kernel) running on my raspberry Pi with a USB LED light connected to it and I want to control on/off through the CLI.
I went through this. However, there is no control or level file in the power folder.
Is there any kernel configuration that I have to enable to get this ?
Found the answer to this. I have to enable PM_SUSPEND in the kernel configuration to get the class files. But then, as mentioned in the comments, RaspberryPi has the power lines directly connected to the power rails
I am trying find out how and with which program for OSX (10.5.8) I can configure serial ports? I am trying to establish a wireless connection between two Xbee´s (RF modules) and cannot figure out how to use ZTerm nor screen under Terminal. The setup I am using is: an Arduino+Xbeeshield+Xbee with external power supply, and an xbee on the xbee explorer connected to the Computer via USB.
I am trying to gather information on this through various forums, but most of them cover the configuration issue for PC using X-CTU (which I tried with CrossOver but it doesn´t recognize ny of my ports). According to one source, using screen under Terminal should show me all my serial ports, particularly /dev/tty.KeySerial1 - but it doesn´t show, even though I´ve plugged in both my arduino+xbee shield and the xbee on the explorer.
/dev/tty.KeySerial1 is incorrect.
First step is to get the FTDI USB driver installed if it has not yet been installed. The fastest way to determine if it is installed or not is to connect the XBee Explorer board. Then go look in /dev for a device named tty.usbserial-XXXXXXXX (Xs will be a unique hex ID). If you see multiple devices like this, then you probably have the Arduino plugged in too and you will need to disconnect it to determine what the device name is for the XBee Explorer board.
Once you know the device name, all you need to do is the command "screen /dev/tty.usbserial-XXXXXXXXX 9600". That should do it for you.
You can configure the tty device itself using stty. Be sure to redirect input from the terminal you want to configure, as stty operates on it's input. For instance, to set a serial port to 9600, no parity, 8 data bits, and 1 stop bit, aka "9600N81" in Windows parlance, try:
stty 9600 cs8 -cstopb -parenb < /dev/tty.usbserial-xxxxxxxx
Programmatically, you do this by opening the serial port and using the termios(4) ioctls on the device. See the termios(4) man page for more assistance.