Using nodemcu_integer_0.9.6-dev_20150704.bin I get these strange things:
> uart=require("uart")
> =uart
romtable: 40240a00
>=uart.PARITY_NONE
nil
> =uart.STOPBITS_1
nil
>
As a result, I'm not able to do this:
uart.setup(0, 2400, 7, uart.PARITY_NONE, uart.STOPBITS_2, 0)
Just because uart.PARITY_NONE is not defined, and:
stdin:1: bad argument #4 to 'setup' (number expected, got nil)
Probably I should use a newer firmware, but the cloud build service does work for me. I just requested a new firmare and tried to flash to the device - but it does not work. When I restart the device (after flashing), the WiFi led is blinking like crazy and it sends garbage over the serial port.
Yes, you need an up-to-date firmware to use those constants (as per the docs).
As for your failed flash attempts I suggest you stick to the documentation the cloud build service sent you a reference for. However, I suggest you build from the current dev branch as to avoid having to flash the new esp init data manually. See https://stackoverflow.com/a/38793023/131929 for details.
Related
I am working with openmote-cc2538 for the project: https://github.com/cetic/6lbr/wiki
Here when I was trying to flash openmote with this command
sudo make TARGET=cc2538dk BOARD=openmote-CC2538 bootload0/dev/ttyUSB0 slip-radio.upload
This error message is displayed
ERROR:Cant CONNECT TO TARGET:Ensure bootloader is started(no answer on sync sequence)
cc2538 bsl.py script is available for uploading binary to openmote. But I don't have much experience about this. Can anybody give me some suggestions regarding how to proceed??
Grab a scope and probe different digital I/O pins on the CC2538. Typically a bootloader will initialize all the ports on the chip and you will see them change state, which is an indication that the bootloader is indeed running. I would guess one of the LEDs would change state as well (which doesn't require a scope).
I'm trying to get Microsoft's Windows Filtering Platform stmedit sample to work and am running into some difficulties.
When I turn on the InspectOutbound flag in the registry, set EditInline to 1, set InspectionPort to 80, set StringToFind to A and StringToReplace to B, and use a proxy, going to www.A.com redirects to www.B.com as expected since the destination is moved to part of the payload.
When I turn off the InspectOutbound flag in the registry (in order to inspect inbound packets), still using EditInline, still InspectionPort=80, accessing a simple http://www.somewebsite.com/somepage.html page I see that no functions from the driver source code have been called. I can see on WireShark that packets are in fact going through port 80 as expected.
I added a DbgPrint() call to every function in the source code to see the basic code flow without having to use the debugger for everything, although I do have it working and haven't been able to find the issue here.
Any help would be really appreciated.
I have been using Windows APIs for NFC communication. I am successful in getting and sending NFC messages from Windows PC, using a local console app. However, I want the communication to be done using a Windows service. Here is what I have:
A C# plugin (DLL), which makes the API calls.
C++/CLI Wrapper that allows unmanaged C++ code, to use the above plugin.
A C++ plugin, that the service will load (this is a requirement, it has to be a plugin)
If I load the C++ plugin into a local console app, and run, it can catch all NFC events (NFC device arrives in proximity, departs from proximity, can read and write to it). But, when I use the same plugin with a service, it is not able to catch those events. I can clearly hear the ping sound that comes when an NFC device comes close to Windows PC, however, none of the event handlers are called (For device arrival, device departure, read or write).
I also tried impersonation thinking that perhaps the context of who calls the method might result in blocking of the events. I could impersonate local user on the service, but the results were the same, no events could be identified.
Is there a reason why I cannot see any NFC events from a service, where as a local console app can get all of them? Again, I am able to hear the ping sound signifying that NFC device is close to Windows PC, but there is no handler getting called for it, suggesting there is blockage of something. Any ideas of what is going on?
Appreciate your time guys!
I've created a simple Go application on a Mac for writing and reading data to and from a TCP connection. I've used the GAE Go version. Later, I ported that program to Windows, and I got this error :
Connection.SetReadTimeout undefined (type *net.TCPConn has no field or method SetReadTimeout)
I guess the net package information on the Golang website describes the package only for the GAE version. How would I properly set the timeout in a non-GAE Go version?
With latest weekly (aka Go 1 RC2) one has to use the various Set*Deadline methods of the net.Conn type. Note that the old timeouts were relative to some event, deadlines are absolute times. The background for this change is roughly: setting a [relative] timeout of 1 s seems like a good idea in some scenario, but it applied to every event, like receiving a single byte, thus allowing crafted transfers to avoid timeouts forever (with the respective DOS nearby).
I have implemented a class that gets local printers and, depending on the application option, uses one of the local printer available.
Firstly, the class enumerates the printers (EnumPrinters - PRINTER_ENUM_LOCAL) and saves the corresponding PRINTER_INFO_2. Then, it gets printer capabilities (DeviceCapabilites) and DEVMODE. Each class instance will access one printer.
When application selects the printing option, it selects which printer will be used and its corresponding instance of the class. Then, this instance creates the device context:
m_hdc = CreateDC (m_pi2->pDriverName, m_pi2->pPrinterName, NULL, m_pdm));
where
HDC m_hdc;
PRINTER_INFO_2 * m_pi2;
DEVMODE * m_pdm;
and process all printing data accordingly.
The problem is that sometimes, the CreateDC return NULL and GetLastError() return ERROR_FILE_NOT_FOUND(2).
I mean 'sometimes' because in other machines, with same printer, same processor, same Windows XP SP3 image and same test data, the CreateDC processes correctly. In addition, the reinstalling the system and application the problem disappears sometimes no.
I am looking forward to hearing any suggestion that helps me to find out the issue.
Thank you in advance.
It sounds like a problem loading a file required by the printer driver. You could use Process Monitor (a free SysInternals tool downloadable from microsoft.com) to get a bunch of information about what's going on at the time of the error. I'd do a capture and look at failed file and registry accesses. The fact that it fails intermittently on one particular machine seems consistent with a messed up driver configuration.
Another thing you could try is to create an information context rather than a device context. You can't print with an IC, but you can query information about the device, which may be a way to get additional information.