Is there a way to access NodeMCU's EEPROM using Lua?
I would like to store data to the EEPROM on NodeMCU but I cannot find any libraries to do so in Lua.
You have the Flash memory accessible through the normal File interface and the NVram on the RTC chip accessible through the RTC User Memory Module.
Related
I have a USB device (actually, a digital camera) that talks the MSC protocol, i.e. it appears as a disk device and can be talked to with SCSI commands. When it's connected to a Mac, the IOBlockStorageDriver takes over and mounts the volume.
Now, my goal is to prevent this from happening, in hopes that I can then talk to the device thru the SCSI interface functions for SCSITaskDeviceInterface, provided in <IOKit/scsi/SCSITaskLib.h>.
Is that possible? The SCSI Architecture Model Device Interface Guide states that the SCSITaskDeviceInterface is only available for types other than $00, $05, $07 and $0E (the MSC device is type 00), but I wonder if that's only because these types are taken over by the Mass Storage driver and therefore are not available. But if I prevent the Mass Storage driver to take over, will these types, such as 00, become available via SCSITaskDeviceInterface?
If that's possible, what must the kext code do to achieve this? E.g, which class should it subclass and which functions must it implement so that it prevents the mass storage driver from taking over while keeping the device visibile as a SCSI device in the io registry?
If that's not possible, could I then instead use the kext to provide a way to offer SCSI-cmd passthrough somehow? I would like to be able to send custom CDBs to this kext from userland, and it should then route them through the SCSI layer to the USB device. Is that possible? Assuming the kext has received a CDB string, how would it locate the SCSI functions for passing the data onward to the USB layer?
I've so far based my unsuccessful tests on Apple's VendorSpecificType00 sample project, which shows how to inject a kext that adds handling custom properties for a SCSI device.
For now, let's ignore upcoming kext deprecations by recent macOS versions (I want to get this working on High Sierra first).
I am looking to transfer data from the zynq ddr to a custom ip, then store the result on the sd card. The sd card is connected through the emio pin, so it is available to the PL. So far, I can access the DDR from Windows, so I put files there. All I need is to connect each component in vhdl to send and receive data from each other. My current Block diagram has AXI stream FIFo, AXI DMA, BRAM generator, and BRAM controller. I've read different tutorials, and only find how to set up the hardware, but not how to connect each piece. Any ideas?
Block Design
The easiest way is using a Linux distro to access the SD card.
Afterwards you can use AXI4 or AXI4S to communicate.
DMA is you friend to copy data from RAM to AXIS and back.
If you want to transfer data directly using AXI4 you can test it with devmem from busybox by accessing the corresponding register. This can be AXI BRAM Controller or AXI GPIO for example.
I am using a i.Mx6 Sabre Lite board running Linux Kernel 3.14.18 and board is supposed to act as a USB Device (USB Gadget). One Vendor specific interface need to be added into CDC/NCM Configuration. CDC/NCM Configuration by default has two standard interfaces - Communication & Data. I have added third interface (Vendor specific) to CDC/NCM Configuration. This interface has two Bulk (IN & OUT) Endpoints. I can verify this newly added interface once board is connected to PC using "lsusb".
Problem:
I cannot see the newly added interface getting exposed to user-space on i.Mx Board or PC, like standard NCM interfaces can be seen as usb0 (Ethernet device) on i.Mx Board as well as on PC and I can PING to/from board using usb0.
If I have to hookup this newly added interface with some g_"driver" (just like standard NCM interfaces are hooked to g_ether); then what is the best choice for BULK I/O?
How to make this newly added vendor specific interface available to i.MX6 user space so as to do read/write on it from Linux Application? I came to know about GadgetFS; but any example would be
Hope someone must have tried similar thing in Linux-USB and can guide.
A vendor-specific interface does not use a standard protocol, so it is not possible to use one of the standard drivers. (And bulk is not a protocol, it is a mechanism to implement your own protocol.)
To access such an interface, you have to use the low-level functions from something like libusb.
I'm working with embedded linux.
There are two USB gadget drivers built as LKM, g_ether.ko and g_file_storage.ko.
I did depmod and then in modprobe -l both drivers show up in the list.
kernel/drivers/usb/gadget/g_ether.ko
kernel/drivers/usb/gadget/g_file_storage.ko
The problem is, the kernel doesn't load either of them on boot anatomically.
Curently my solution is to add boot scripts to /etc/init.d etc/rcX.d to force g_ether.ko to be loaded on boot as the default driver.
Are there other (better) ways to make g_ether.ko default driver?
A possible solution is, I make g_ether.ko a static driver, and make g_file_storage.ko an LKM, but I don't know how to turn off a static driver to release the hardware so that another LKM driver can be loaded.
Any suggestions?
It's a user choice to use USB peripheral controller as ethernet or storage. So there is no related hardware event for automatic client driver loading.
But there is a way to bind/unbind driver in user space through sysfs. Look at this： https://lwn.net/Articles/143397/
few days ago I asked here about implementing USB. Now, If I may, would like to ask few more questions, about thing I dind´t quite understood.
So, first, If I am right, Windows has device driver for USB interface, for the physical device that sends and receives communication. But what this driver offers to system (user)? I mean, USB protocol is made so its devices are adressed. So you first adress device than send message to it.
But how sophisticted is the device controller (HW) and its driver? Is it so sophisticated that it is a chip you just send device adress and data, and it writes the outcomming data out and incomming data to some internal register to be read, or thru DMA directly to memory?
Or, how its drivers (SW) really work? Does its driver has some advanced functions like send _data to _device? Becouse I somewhat internally hope there is a way to directly send some data thru USB, maybe by calling USB drivers itself? Is there any good article, tutorial you know about to really explain how all this logic works? Thanks.
The USB protocol stack has several layers and is quite complex. You really need to read a good book on USB (e.g. USB Complete) to get an understanding of how it all fits together. The bottom line though is that you want to go as high up the protocol stack as you can, ideally using a system level API (e.g. if it's a USB HID device then just treat it like any other HID device, rather than thinking if it as a USB device - ditto for mass storage devices, etc).