I wanted to update the application of an ESP8266 that I have very little physical access to. The new application uses the function uasyncio.create_task(coro) which is not available in Micropython 1.12. Fortunately I was able to replace the function with uasyncio.ensure_future(obj).
Nevertheless, I have the question of whether the area in the flash with Micropython can be updated via WLAN at the runtime of the "OS" Micropython?
Does Micropython run completely in RAM?
A Linux kernel, for example, can easily be exchanged at runtime so that the new kernel is loaded at the next boot.
Yes, Over The Air (OTA) updates are possible. Your device has to be configured for OTA updates before hand with two OTA partitions. MicroPython will run from one of the OTA partitions. You can use MicroPython to retrieve and write new firmware to the other OTA partition. When you perform a reset the processor will start the application in the other OTA partition. You can do this over and over again ping-ponging between the two OTA partitions.
See these links for some examples
Related
I'm running Arch Linux and the Bluez libraries on my computer, and I'm trying to connect to an iPad [w/ Retina] over BLE. I can see the iPad in bluetoothctl, pair it, trust it, and connect to it. My question is in two parts:
1) I want to be able to select the attributes, more specifically for the MAP service. However, running
list-attributes
either during or outside of the connection returns no information.
2) My iPad cannot see the computer like it can see the iPad, either through the Settings --> Bluetooth menu or the CBCentralManager in an app that I'm developing. My computer is set to be discoverable and pairable forever, but it just doesn't find it.
How would I be able to connect to the iPad appropriately, if there even is a way?
Disclaimer to anyone using BlueZ user space tools:
OP mentioned in the comments that he utilized hcitool. It's best not to use hciconfig nor hcitool as these are in the process of
being phased out of BlueZ and have been unmaintained for a very long
time. They are prone to errors and the raw calls these programs make are blocking and cause interference with other Bluetooth applications.
BlueZ publishes some methods in order for users to use its Bluetooth (LE) functionality for applications or tasks: DBus and a lower-level approach. Programs included in the BlueZ user space package include bluetoothctl, which uses DBus for bluetooth related tasks, such as scanning, advertising and GATT. Tools like btmgmt, which can be considered a maintained version of hcitool, use the lower level libraries. BlueZ recommends using the DBus API for applications. Be sure to have compiled the source code and have followed the recommended instructions to use the mentioned tools. Also always check the licensing on mentioned tools and source files as some can not be included in proprietary software.
DBus-less solution:
If using bluetoothctl or DBus doesn't work out for you, I would suggest you use btmgmt. It can be found in the /tools folder of the user space source code.
If you're looking for or wanting to include GATT-related tasks, you can use btgatt-client to act as a GATT Client or btgatt-server to act as a GATT server from that same /tools folder.
These do not use DBus, nor the corresponding Bluetooth Daemon (bluetoothd) like bluetoothctl does
DBus solution:
What is most likely the cause of you not seeing services using bluetoothctl, however, is that you are not running the aforementioned bluetooth daemon with the -E flag (experimental). Currently, all GATT-related functionality is only usable when running in this experimental mode. (They're working to get it out of experimental-only mode) I think because it's still being developed. If I recall correctly BlueZ can also be configured/installed in this experimental mode, so that no manual actions are required.
To restart the BlueZ Daemon (bluetoothd) with GATT enabled run:
sudo service bluetooth stop && bluetoothd -E
In most cases, when stopping the bluetooth service, your bluetooth controller will power down and bluetoothctl won't respond to user input/freezes on startup. If this is indeed the case, use btmgmt and issue a power on to power the bluetooth controller again.
To VIEW the MAP service attributes, use list-attributes to view them. Ensure proper spelling. To SELECT the MAP service, you need to list-attributes then select-attributes, in that order.
It sounds like your ipad is having a problem. Perhaps try turning it off and on again. Make sure you have bluetooth enabled!
There is always a way!
i plan to try some bare-metal TCP/IP stuff on a beaglebone. There is TI StarterWare containing the TCP/IP stack which is good. However, to flash my program to BB, I need some JTAG adaptor and software. Which one should I buy/use there so many different JTAG debuggers, are they all equivalent?
One preliminary remark:
You don't really need a JTAG probe for downloading/running/flashing your program: you can load and execute using u-boot loadb or load commands from the serial console, provided that your beaglebone does still have u-boot installed - The procedure for connecting a USB-to-TTL adapter is described here. I would strongly suggest to buy the exact adapter featured in the article above on e-bay if you don't have one.
In addition to the u-boot/serial adapter, you can to connect your beaglebone to your local network, and download your application using u-boot tftp commands. You can buy a USB to Ethernet adapter for a couple of dollars, plug it into your PC, then install a TFTP server, tftp32 (Windows) or tftpd-hpa (Linux). You will then be able to connect directly your development PC to your beaglebone.
In the case your beaglebone would not have a working u-boot installed anymore, you still can re-install it from the serial port:
This can be done by connecting both P8.44/SYS_BOOT3/LCD_DATA3/GPIO2_9 and P8.43/SYS_BOOT2/LCD_DATA2/GPIO2_8 to the ground (two of P9.43/P9.44/P9.45/P9.46) using two 4.7 k ohm resistors, powering the beaglebone with an external 5V power supply (not by USB), and power-cycling the beaglebone - power-cycling IS required, performing a 'reset' is not enough for the new SYSBOOT configuration to be taken into account.
You can then download u-boot from your PC using Teraterm: u-boot-spl-.bin should be downloaded using x-modem, and u-boot.bin using y-modem, as described in the 'Boot over UART' section of this TI wiki article.
This being said, a JTAG probe is always useful when debugging a bare metal application or the Linux kernel: as a hobbyist, I am using the EDU version of Segger J-link with my beaglebone (around USD 63). If you need it for commercial use, the price tag is around USD 400 I guess.
You will also need to have the TI 20 pin header soldered on your beaglebone - see section "Optional JTAG" of the beaglebone documentation.
I bought the Samtec FTR-110-03-G-D-06 connector, and am perfectly happy with it.
Please note the CircuitCo used to sell Beaglebone Blacks with the connector already soldered.
Finally, you will need an adapter to connect the TI 20 Pin connector to the standard 20 pin ARM JTAG connector used by the J-link.
To my knowledge, they are at least two solutions:
The J-Link TI-CTI-20 Adapter from Segger, which was my choice,
The BeagleBone Black JTAG Adapter Kit from Tican Tools.
The J-Link has software support for both Windows and Linux. I have been using it with the Starterware and my beaglebone black on both Windows and Linux systems with success to this day. It has been working fine with a bunch of different Cortex-M0+, M0, M3, and M4 as well.
Unfortunately, I don't have been experimenting with other JTAG probes...
From what I have read, the JTAG emulator that allows you to use the free license to Code Composer Studio with the Beaglebone Black is the XDS100v2. Here is a link to it:
https://store.ti.com/TMDSEMU100V2U-20T-XDS100v2-JTAG-Emulator-20-pin-compact-TI-connector-P1848.aspx
I just bought one myself to use with the BBB. I have not tried it yet though.
You don't necessarily need JTAG to test them. You can build it and put it in a path in your filesystem, then during boot, ask your bootloader i.e. u-boot to load it and then jump there and execute it.
I am aware that there are programs out there like lojack for laptops that get installed on the BIOS, but I'm still a little confused. When reading about lojack, it seems to me that they can't fully located the laptop's location until the user logs in and tries to access the internet. So I'm thinking that it's a BIOS application so that it wouldn't matter if the thief reformats the HD.
So my question is, does anyone have any ideas of how an internet enables BIOS application would be written. I'm not looking for full answers -- just ideas or resources to get started. For example, is such a thing written in assembly? Once one such app is written, how does it get transfered to the BIOS.
Does the BIOS program itself recognize that there is an internet connection (when the thief logs on to the OS). Or upon logon, does additional processes get spawned? Are there any resources/websites that anyone can direct me too?
You didn't mention whether you were interested in legacy BIOS or EFI BIOS, but I would mention that with EFI there is the capability of writing EFI applications. See Intel Press:
Harnessing the UEFI Shell
The EFI Application toolkit comes with a complete TCP/IP network stack:
http://www.intel.com/technology/efi/toolkit_overview.htm
More at tianocore.org
Regarding "LoJack"-style solutions, one of the providers of this technology is Absolute Software's Computrace product.
Basically there are 3 components: 1) a software component that runs in the OS; 2) a BIOS component which is baked into the system BIOS (accomplished via Absolute working with the PC vendor); 3) servers at Absolute software that talk to the PC.
For more information on how it works visit:
http://www.absolute.com/en/company/Computrace-Persistence.aspx
(see especially the demo video on this site)
To learn something about BIOS, one good source is coreboot.org. It is an open source BIOS (or firmware) and support some physical machines.
Legacy BIOS is written in assembly language, but new generations, such as UEFI or coreboot, are written mostly in C language. BIOS program is stored in the ROM, and executed by the CPU automatically.
The BIOS program itself does not access the internet or perform any of the advertised functions. The LoJack addition to the BIOS firmware is a file copying/patching utility - at boot up it can check the harddrive for a copy of Windows and proceed to silently install/repair the LoJack service if it has been removed. The service itself includes several measures to lower it's profile and prevent itself from being disabled (similar to how many trojans and malware run several processes that each restore the other if one is disabled or killed).
The LoJack BIOS program can't do anything if a unsupported operating system (like Linux) is installed after the harddrive is wiped.
I have a Wi-Fi driver from a manufacturer. That driver has Plug and Play support. After the adapter has been inserted or removed, Windows CE has recognized it successfully. But at boot time, if the adapter is "inserted state", CE OS does not load it so I must remove then insert it.
I want to load the driver automatically during boot time. Is it possible?
Before, I've written a simple stream interface driver. I have edited project.reg to create a sub-key under HKLM\Devices\BuiltIn so that Device Manager can load automatically during boot time. And it was successfully loaded. But Wi-Fi driver is a non-stream driver. Can Device Manager load Wi-Fi driver automatically with the same way?
Are "all of drivers under HKLM\Drivers\BuiltIn" stream interface drivers? What differences are there between stream interface drivers and NDIS Wi-Fi drivers from the point of loading automatically during boot-time? I will very happy if you can explain it a little.
I want to load the driver automatically during boot time. Is it
possible?
Yes, it is definitely possible. That was the main purpose of plug and play devices. The WinCE device automatically loads a driver appropriate to the Plug 'n' Play device. There would not be any need for doing it manually. If so, then there is no need for a Plug 'n' Play functionality.
As this is not happening in your case, you could try the following
Have you checked with any other Plug-n-Play devices to the WinCE device?
Each time you plug-out and plug-in, is it installing the drivers or is it just loading? You can verify the debug logs to confirm this.
Are "all of drivers under HKLM\Drivers\BuiltIn" stream interface drivers? What differences are there between stream interface drivers and NDIS Wi-Fi drivers from the point of loading automatically during boot-time?
Actually, the block devices can also be loaded automatically, as similar to stream interface drivers. The HKEY_LOCAL_MACHINE\Drivers\BuiltIn registry key recognizes built-in block devices also.
You can refer this msdn link for further information regarding loading the block devices.
I am very enthusiastic in writing device drivers for a microcontroller(like PIC, Atmel etc).
Since I am a newbie in this controller-coding-area I just want to know whether writing device drivers for controller is same as we write for linux( or any other OS) ?
Also can anyone suggest some online device driver building tutorial for the same ..?
Thanks,
If you are thinking about developing the device drivers to interface your device with a host computer (probably using USB), then most of the microcontrollers nowadays implement default classes that rely on native drivers.
A concrete example:
If you use a PIC18F4555, you can use the regular HID (human interface device) windows driver to communicate with your microcontroller (given you implemented it correctly). No need to develop any driver.
Writing a device driver for an MCU is a pretty far cry from writing it for a OS. Most MCUs won't have an OS running on them at all. You'll generally end up writing some low level Interrupt Service Routines (ISRs) and filling up buffers, that your application software will end up emptying. You don't have to fit into any device driver paradigm that an O/S has defined. You basically have to read the datasheet for the device you are wanting to interface with and read and write to its memory over whatever interface it might use (e.g. SPI, I2C, UART, etc.). Ultimately the device driver ought to provide intuitive function calls to the application software.
If you are using AVR MCU like atmega then you can use vusb (https://www.obdev.at/products/vusb/index.html) for those MCU that don't have any HID and handles the interrupts by connecting D+ and D- pins of the USB to digital I/O ports of the MCU.
The atmegaU2 packages have their own USB communication ports and HID.