When i flashed my custom rom i tried to see what it recognizes because the stock kernel was not recognizing this atheros external adapter which was connected with OTG cable. So when i typed in the terminal (in this case i was using Termux, which is a whole linux environment) lsusb and it recognized the atheros bus but when i tried to install the drivers nothing has worked how it is supposed to do.
Note: I am posting the question here bacause if i was about to drop it in the android section i might be linked to post it in the unix but then the question body contains programming parts in it and becase of that i've posted it here.
Related
num=[1];
den=[1 3 1];
G=tf(num,den);
H=1;
T=feedback(G,H);
step(T);
hold on;
Kp=23;
Ki=0;
Kd=0;
C=pid(Kp,Ki,Kd);
T=feedback(C*G,H);
step(T);
When run this script nothing happen in Octave but works fine in octave-online.net
online octave
Octave Windows
I will put a proper answer here for future users, even though OP has already solved their problem from the comments.
octave-online.net is an excellent cloud service providing an instance of octave on the cloud.
Contrary to a typical installation of octave on linux or windows, the octave-online client autoloads some of the more popular packages, one of which is control.
You can confirm this by typing pkg list in the octave-online console.
In your normal linux / windows installation however, this needs to be loaded explicitly before use, e.g. in the case of the control package, by doing pkg load control.
Your code uses the functions feedback and pid, both of which rely on the control package, therefore in your windows instance, your code failed, because you tried to use these functions without loading the package first.
Presumably there was also an error in your terminal informing you of this fact, that you may have missed.
I am new to ESP8266 and to the electronics world. I request you to please be patient if I am mis-understanding a point.
I am using ESP8266-01.
I successfully re-flashed the at official ai-thinker firmware version 1.1.1 to my module and I noticed that it was being written at memory location 0x00000.
Later I successfully uploaded a basic blink program using Arduino ide. Again the program was written to the memory location 0x00000(over-writing the firmware I guess).
I want to use it as a web server. The code for that uses the AT commands, something like "Serial.println("AT+RST");"
Now from what I understand the firmware would be over-written. Then how would the module understand what "AT+RST" means?
Thanks
"Arduino" is more than just the IDE you see and the boards (e.g. Uno). Arduino is also a kind of firmware/OS that runs on those boards. A sketch you write in the IDE is compiled together with the firmware into a single package that's written to memory.
There are a few more hints at https://github.com/esp8266/Arduino:
This project brings support for ESP8266 chip to the Arduino
environment. It lets you write sketches using familiar Arduino
functions and libraries, and run them directly on ESP8266, no external
microcontroller required.
ESP8266 Arduino core comes with libraries to communicate over WiFi
using TCP and UDP, set up HTTP, mDNS, SSDP, and DNS servers, do OTA
updates, use a file system in flash memory, work with SD cards,
servos, SPI and I2C peripherals.
When you hit that 'Upload' button in the IDE you're effectively replacing anything that's been written to the ESP8266 before.
This question is wrong on many levels.
It was based on the assumption that "Serial.println("AT+RST")" was a command to the esp while in reality the programmer meant it as a logging message to the serial monitor.
I had asked "How does it understand what “AT+RST” means without the firmware". The answer is that it doesn't and it can't unless I write some code in my sketch to handle it. The firmware is a kind of interpretter. It accepts a command in a particular format (e.g. "AT \n"), parses it, executes some corresponding low level function and returns the result.
After I have uploaded a sketch and over-written the AT firmware, the interpretter code is gone and hence the esp cannot interpret/understand the AT command.
#AdrianoRepetti:
"How "web server" and AT commands are related is unknown to me" - You are right, they are not related. My bad.
"Anyway AT commands is understood directly by ESP8266 chip" I doubt it.
Thanks for your answers.
This question is not adding any knowledge to anything. I think it should be deleted.
I was installed CUDA 4 on my laptop (Dell - Vostro 3500) and started to write CUDA programs. But I got an error: driver is not compatible with this versios of CUDA.
So I decided to update my GPU driver (GPU: Nvidia GeForce 310M) and downloaded the driver from Nvidia's site. But when I want to insall the driver, see this error:
NVIDIA Intaller cannot continue
This graphics driver could not find compatible graphics hardware.
I tried 301.42 , 301.32 , 275.33 and 270.81 versions of Nvidia GPU drivers.
My friend installed 275.33 on his laptop with GeForce 310M on an Asus device.
Finally I found my answer with the help of Ben Stewart.
I hacked the INF file in this way:
Go here.
At the second part (NVIDIA Video Drivers and Tools) select suitable part. For example select 29X for 296.10.
Select appropriate part for your downloaded driver and Windows version.
In this page download INF file.
Replace the INF file with INF in the Display.Driver folder at driver unzip location (for example, C:\NVIDIA\DisplayDriver\296.10\WinVista_Win7_64\International\Display.Driver)
Set up the driver!
I had the same problem recently running Windows 7 on an iMac and managed to hack the nv_disp.inf file on version 301.42 to get it to install fine. Basically, you need to add an identifier from your graphics card to the inf file and away she goes. Not to hard.
Here's how I did it.
First, we need the identifier from your graphics card. Open Device Manager and bring up the property box for your graphics card in Display adapters. In the "Details" tab you will find a drop down box, open it and select "Device Instance Path"; you should be able to right click on the value in the field below and copy it.
Then find the temporary folder that the driver setup was extracted to when you ran it previously. For me it was "C:\NVIDIA\DisplayDriver\301.42\WinVista_Win7_64" - if you can't find it, just run the setup again and note where the installer extracts itself. The file we need to edit is located in the Display.Driver directory, and it's called nv_disp.inf. Open this in Notepad or your favorite text editor.
Now we need to modify the string you have copied and add it to this file.
If you scroll about 15% of the way down you will find a heading similar to [NVIDIA_SetB_Devices.NTamd64.6.0]. This is the start of Nvidia's list of supported devices.
If you paste your device instance path here you will probably notice that the first 21 or so characters of your device path are similar to the last 21 on the proceeding few hundred lines. Something like PCI\VEN_10DE&DEV_0240. You can delete the rest of the text you have copied in.
The devices are organised into groups, so it's probably best to search for a line that is similar to yours in the last four numbers and use this as a template for creating the entry.
You want to use this information to create an entry that looks like the others that are already here.
I modified the line:
%NVIDIA_DEV.0868% = Section005, PCI\VEN_10DE&DEV_0868
with the identifier PCI\VEN_10DE&DEV_0869 to be:
%NVIDIA_DEV.0869% = Section005, PCI\VEN_10DE&DEV_0869
Note that the four-digit number near the beginning of the line matches the number at the end.
Save the document over the original nv_disp.inf, then run setup.exe from the already extracted folder. If you run the file you downloaded again, it will just extract again and overwrite your changes.
Are you downloading the notebook drivers from http://nvidia.com/drivers?
If you were using the notebook drivers, then it is likely that NVIDIA didn't include your GeForce 310M in the INF file for the latest drivers. You can hack at the INF files yourself to fix this. It is not simple, but can be done by googling for it and carefully reading certain forums where others have hacked at the INF files themselves. No fun.
I'm trying to port a C++ utility program that I want to be run from the Android ADB shell.
For that, I'm using the Android NDK's make-standalone-toolchain.sh script, and compiling my program with it.
Unfortunately, when I try to run it, I get this error:
reloc_library[1315]: 16304 cannot locate '_ZNKSs5c_strEv'...
CANNOT LINK EXECUTABLE
After some research, I saw that this means that the c_str function doesn't exist in libstdc++.so in the NDK. I also couldn't find the symbol in stlport.so either, and actually only found it in the ./sources/cxx-stl/gnu-libstdc++/libs/ version of the C++ libraries. These libraries are not included in the standalone toolchain I made, and I also couldn't find them on the device (the device is running Honeycomb).
The text in the NDK clearly states that there's support for the entire STL when I use stlport. Is this something that is only true in Ice Cream Sandwich? The libstlport.so or in libsupc++.so on the device and in the NDK didn't have any signature like the one that wasn't found.
So my question has two parts:
Is there something I'm missing in the build process/Android setup? Can I set up things differently so that the program will compile without needing the gnu-libstc++, or at least fail with a compilation/link error instead of failing to load on the device?
If linking with gnu-libstc++ is the only way, how can I do that? I think I can manage statically link to it but I'd rather not.
How can I add the gnu-libstdc++ version to my
If someone else is looking for a solution, I ended up adding a dependency using the -l switch on libgnustl_shared.so. You can find it inside the NDK at
sources/cxx-stl/gnu-libstdc++/libs/<architecture>/
I then pushed this .so together with the program to the device, and made a script that adds the current directory to LD_LIBRARY_PATH. It seems similar to what the NDK does when you use the make scripts to create a program that depends on gnustl.
According to this tutorial, calling Class.forName isn't needed anymore with JDBC 4.0+ drivers. I successfully followed the method in the example (just calling DriverManager.getConnection) for a stand-alone program using MySQL, but when I tried to connect to the exact same database from a class that was part of a web app running on Tomcat 7, it wouldn't work; instead I got a No suitable driver found exception.
The mysql-connector-java-5.1.18-bin.jar file was in tomcat\webapps\DatabaseProject\WEB-INF\lib, I triple checked, but it wasn't working, so I started trying things. I added a call to Class.forName and it worked. That was the only thing that changed.
Anyway my question is, does anybody know why this worked or what was going on here? My only theory is that I also have hsqldb.jar in tomcat\lib for another project and maybe somehow the drivers got confused? But I was under the impression that DriverManager is supposed to be able to tell automatically which driver to use, so that's not supposed to be an issue... Anyway if someone could enlighten me as to what's going on here, I'd really appreciate it.
JDBC4 drivers include a file:
META-INF/services/java.sql.Driver
in the jar which uses the ServiceProvider mechanism to register the Driver implementation with the JVM (see javadocs for java.util.ServiceLoader). That's why Class.forName is no longer necessary.
My guess is that this is a class loader issue. The ServiceLoader javadoc mentions that:
The provider must be accessible from the same class loader that was
initially queried to locate the configuration file; note that this is
not necessarily the class loader from which the file was actually
loaded.
I would try putting your driver in the tomcat\lib directory rather than your web app directory to see if that makes a difference (different class loader?).
If you launch your web app through an ide and set a breakpoint, once you hit the breakpoint, you can use the "evaluate expression" feature to execute: ServiceLoader.load(Driver.class). This will give you a ServiceLoader class which you can peek into to see which Drivers are registered. You can check if the mysql driver is there, where in the list it is, etc, which might help in figuring out the behaviour here.