I want to make a Java Card Connected Edition Application in a Omni Ring, based on WEB (HTTP).
This Contactless Ring comes with Java Card 3.0.1 and I already have an ACR122U reader/writer.
I downloaded NetBeans IDE 8.2 RC and made an example of the Java Card Connected Edition (HTTP) and everything worked correctly on the NetBeans Virtual Card, however I am not finding any information on how I download it to the Ring.
How can I do this?
You cannot. The SLE78 only has 8 KiB of RAM available. That's not enough to run the Java Card Connected operating system. Actually, you will find preciously few implementations of Java Card Connected due to the high RAM requirements, which prohibits the use of cheap silicon. The few implementations (or rather, implementation) that I'm aware of used a contact based chip. Your chip runs the Java Card Classic variant.
That said, it is certainly possible to create a web server within an Applet (and this has been done in the past). Implementing TLS is going to be a lot trickier though, just because of the code size. TLS has many options. Instead you could tunnel the connection on a more smart card specific secure channel I suppose.
Related
I would like to use a windows machine as a USB488/USBTMC device. USB488/USBTMC is a reimplementation of the good old GPIB/IEEE-488 on USB rails. But most articles on the topic refer to a Windows machine as a host/controller. The Windows USB stack is not well suited for USB device/USB OTG modes. However, if you look at some of the high-end gear like oscilloscopes and spectrum/network analyzers, it is well known that they are often Windows machines inside with some additional hardware. So, how it is done?
To some background: it is a project to retrofit a very old SEM microscope with new hardware. The current one is a 68k custom system with a CRT that uses a GPIB interface for comm with a PC. Things like sample spectroscopy are done as a BASIC program running on a pc and communicating through that gpib port. The plan is to replace that 68k junk with a modern day windows pc with an FPGA on a PCIe bus. For compatibility reasons, it would be nice to have a usb488 port in the new PC. Though I have no idea of how to do it properly. The only solution I have so far is to have some cheap USB-capable micro hanging on the SPI bus on the FPGA facing side and a USBTDM class on the USB side. But maybe Im missing something and there is a specific thing or chip that exists that can do it that Im not aware of.
I can only speculate how high-end oscilloscopes achieve it. The most likely option is that they use a dedicated chip like a MAX3420E. It is connected via SPI. Part of the USB protocol is implemented by the chip, part of it will be implemented by the oscilloscope software.
Most USB controllers chips found in PCs can operate as the host only. And even if they could do a role swap, Windows (for Desktop) has not supported device/peripheral mode until recently. It now does. See USB Dual Role Driver Stack Architecture. But I don't fully understand it to tell you what hardware you would need to purchase where this feature is enabled.
Role swapping is very common on smartphones. It is also implemented in Linux (search for "Linux USB gadget"). Many Apple Macs can run in Target Disk Mode, which is a USB device/peripheral mode as well.
What is the additional advantage of developing a full UMDF windows driver if a CDC device is detected as a virtual COM port?.
I have some experience with embedded examples using a microcontroller, both communicating with a terminal like teraterm or using a dedicated USB peripheral that allows for cdc or hid functionality.
Are these drivers the ones you download and install before using any USB device? It is not clear yet what features are avaialble through the host driver.
Often on Windows the "driver" for a USB serial device is no more than an inf file that maps the device VID/PID to the Microsoft usbser.sys CDC/ACM driver.
Recent releases of Windows 10 appear to have stopped insisting that each CDC/ACM have a VID/PID specific inf file, and will load the standard driver for any device that presents as a CDC/ACM device.
The advantage of having a VID/PID specific inf file is that your device can have a vendor specific "friendly name" which can be used in applications to more easily identify your device, rather than just appearing as a generic "USB Serial Device".
One problem with Microsoft's usbser.sys driver (and Linux and Mac OS are no different) until recently was that if you disconnect the USB device, the driver is unloaded even if an application has the COM port open, and the application must close and reopen the port to recover when reconnected. I have previously used a custom driver (provided by a third party), that does not unload if an application has the port open, so that when the USB cable is reconnected, the data connection continues as normal, just as it would if it were an RS-232 cable. However, again in recent versions of Windows 10 I have noticed that usbser.sys appears to exhibit this behaviour in any case.
Note that when you do provide your own driver file, or even just a custom inf file, you will be required to go through WHQL testing in order for your device to be allowed on Windows 10, or to load without warnings on earlier versions. To do that you will need a USB.org assigned VID, an Extended Validation code-signing certificate, and either the tools and facilities to perform the testing, or pay a test house to perform the testing. That all gets somewhat expensive, and may be prohibitive for low volume, low value or non commercial products.
At one time Microsoft too charged for WHQL processing submissions, but no longer do so. That is however little combination since at the same time they changed to requiring an EV certificate and stopped a deal the used to have for low-cost certificate.
The advantage of WHQL qualification is your driver will be provided by Windows Update.
If you are using a USB serial bridge chip rather than your own USB stack and USB controller, then there is a lower cost solution. These chips can be customised with your own VID/PID and descriptors, and the vendor's existing WHQL can be associated to your device so you get all the advantages of your own driver without the costs. Most vendors will even allow you to use their VID and will assign you a unique PID so you can avoid USB.org fees. I have used this route with both Prolific and FTDI devices; it is by far the most cost effective solution.
I'm interested in PC firmware programming, and am just studying the UEFI spec. To my surprise, it seems like a spec for an entire OS which is embedded in firmware. You can even write UEFI "applications", which run directly using the UEFI boot services, without any other OS present.
I've found blog posts which show how to create a "Hello, world!" application which can run in the UEFI preboot environment. This is... interesting, and bizarre at the same time. I'll run my "Hello, world" programs on a regular OS, thank you.
What kind of use cases are UEFI applications actually good for? Fancy boot configuration screens? Does any "real", commercially available PC firmware use UEFI applications to implement anything more than just boot loaders and boot configuration utilities?
Anything that isn't PEI/DXE/SMM core or driver is an application, so any "real" PC have them, because BIOS Setup is actually an UEFI application. Some vendors include various other apps like firmware updaters, diagnostic and troubleshooting utilities, etc. UEFI 2.4 makes possible to add your own application with a properly filled BootXXXX/KeyXXXX variable pair and then run it by pressing a key combination during POST.
Most console applications written in C can be compiled as UEFI application by using StdLib package of current EFI Development Kit and then run in UEFI shell.
Major examples of useful UEFI apps (besides bootloaders, shell and Linux kernel, of course) are Intel ME System Tools, Read Universal, Python 2.7 and many more.
Eventually, when legacy boot will not be available anymore, all currently useful DOS utilities must either be made UEFI applications or go extinct.
Despite many valuable answers here, because I wrote couple UEFI applications myself I will try to add my 2 cents. First, what is UEFI application to just give ground what we talking about:
UEFI Specificatin v2.5:
Section 2.1.1
The major differences between image types are the memory type that the firmware
will load the image into, and the action taken when the image’s entry point exits or returns. An
application image is always unloaded when control is returned from the image’s entry point.
Section 2.1.2
When the application returns from
its entry point, or when it calls the Boot Service EFI_BOOT_SERVICES.Exit(), the application
is unloaded from memory and control is returned to the UEFI component that loaded the application.
Groups of applications that make sense in UEFI:
Configuration tools - Configuration interface for Option ROMs (ie. for storage controllers), out of band management (ie. AMT configuration tools), manufacturer performance tweaking tools
Provisioning tools - used by administrators to preload specific BIOS setting, manually setting all options in BIOS setup would be inefficient
Diagnostics tools - mostly for tests that cannot be performed in OS (DRAM tests, full storage scan, storage R/W tests, etc.). In some districts specific diagnostics tools are required in UEFI BIOS, so those can be sold to government.
Security applications - HDD encryption/decryption, antivirus scanner and anti thief applications
BIOS capability enhancement - Power Over Ethernet extensions, DRAM discovery, patching and modification of system tables (SMBIOS, ACPI)
Display tools - for displaying complex animations while running, splash screen displaying
Bootloaders - this is special type of application, which can call EFI_BOOT_SERVICES.ExitBootServices() causing termination of all memory management and passing control to Operating System.
Note that very important feature of UEFI application is that it can be added to boot order and be executed each boot time. Also UEFI application do not have to be delivered with BIOS image it can be stored in connected device memory, which is common for Option ROM configuration tools.
Here it is an example of a full blown UEFI Pre-boot Application;
There are SED SSD/HDD drives. As soon as SSD/HDD loses its power it goes into locked state (hardware-based encryption) There is no way you can get access to drive's data and all partitions on the drive are no longer even visible. Only small read-only partition (ShadowMBR) is available. UEFI firmware boots an UEFI application from that only available partition (UEFI app is written on that partition during the initialization process and when the ownership of an SED is taken). It securely authenticate user and if credentials are valid it unlocks the drive. When the drive is unlocked Shadow MBR disappears and all partitions on the drive becomes available. Then the App chain-boots the installed OS.
So if you don't have credentials you cannot even boot the OS and you cannot access the data on the drive by any means.
Here's a couple of examples:
https://github.com/NikolajSchlej/CrScreenshotDxe
UEFI DXE driver to take screenshots from GOP-compatible graphic console (yes, you can make PNG screenshots of your BIOS and save them)
http://ruexe.blogspot.com/
RU.EFI is quite an advanced tool for debugging the BIOS
Well, there are the OS loaders - both the more heavyweight ones (Windows, GRUB, BSD Loader) and the "present a menu" ones (rEFInd, Gummiboot). Shim, which enables UEFI Secure Boot for Linux platforms, consists of an application as well as installing a protocol for use by other applications.
Then you have things like the Linux kernel, which when compiled with CONFIG_EFI_STUB becomes a valid UEFI application, with the awareness of booting itself.
And firmware updates can also be shipped as UEFI applications.
The UEFI shell itself is an application.
Then there are things like factory production testing utilities, development diagnosis tools, ...
Windows 7 - 8 have UEFI installer. I'm not fully aware of the details, but I'm pretty sure this new environment gives a lot more flexibility to the developers than traditional boot environment on DVD.
Some motherboards have "instant on" features that allows you to get to a desktop screen within a few seconds. This is usually a stripped down flavor of some linux that allows you to access a web browser and play music/video. ASUS have such boards.
Currently, IntelliJ IDEA does not have a "Remote Development" feature.
Lets say I have two machines: Machine 1 (very good configuration ex 64GB ram with Intel Xeon processors) and Machine 2 (Macbook Pro with 8GB RAM).
Lets say I have IntelliJ IDEA installed on both machines. The problem now is, there is no client-server mode for the IDE. The closes thing I have is to use OpenNX.
What I'm looking for is a plugin/feature that enable remote development. What I mean by this is: On my macbook, I should be able to add Machine 1 as a "server". And once that is done, the IntelliJ IDEA on my macbook will only act as a client for the IntelliJ IDEA on my Linux box. Basically it would be replicating the UI. However, the catch here is that, it shouldn't do so by sending images (the way any VNC or NX client would). Instead, since it is for a specific application most of the data can be managed through text data only.
Since OpenNX uses images, even with compression it wouldn't match up the performance of text only transmission.
Basically I'm looking for IDEA on one machine to be a client (Remote GUI) for IDEA on another machine.
UPDATE
The eventual answer is: This is not possible (As of now). While I was aware of other options, that wasn't what I really wanted. However, it appears there is no such option.
The main reason why I wanted the option was because my desktop (remote Linux box) has a much higher configuration (Intel Xeon 2GHz processor and 64GB RAM) and my client was an Macbook Pro with Intel Core i7 and 8GB RAM. (By no means any less). However, due to the size of my codebase etc, the indexing of the code etc by the IDE slows it down.
Both client and server are perfectly capable of running an IDE by themselves. However, due the size of the code base it would be better to have the build of the work being done by the IDE on the server and the client being just the front end to it.
The other solutions like VNC, Nomachine - OpenNx all use image compression. And when your client is a Mac, you run into keyboard mapping problems. A client-server mode in the IDE itself would use text compression instead and would be much faster. It would also solve the keyboard mapping problems.
While to me, it sounds like a good idea, it probably doesn't get used by enough people for it to be a feature of the IDE.
Note: I would also be open to considering Eclipse as the IDE if this feature is available. Any answers will always be apreciated.
You'd probably be better off switching instead to a remote code repository that you keep in sync. While the concept of doing this in an IDE plugin is interesting, it has some fundamental flaws. What happens when the machines can't talk to each other? Are you unable to work at that point, or can you work offline. If you work offline on both machines, how do you reconcile changes...
I suggest looking into using "git". You can set up a remote repository very easily. If you have ssh access to either machine or some other shared machine, you can create a remote repository on that machine, and your "client" machines can easily push files/changes around.
There are plenty of other code repository options, but I've found git the easiest to set up.
I have been tasked with writing a USB driver for our embedded software to send raw data to Host. This will be used to send some logging data to host. We are using iMX31 litekit for development.
From the documents that I have read on USB, my understanding is that the embedded device will be in device mode only. Also it will only be communicating with host machine.
So can any one guide me here? Any article, reference or code is welcome.
Some things to consider:
Is this a high bandwidth device like a camera or data recorder, or a low bandwidth device?
For low bandwidth, I would strongly consider making your device act as a USB HID class. This is the device class that supports keyboards, mice, joysticks, gamepads, and the like. It is relatively easy to send data to nearly any application, and it generally doesn't require that you write a custom device driver on the host side. That latter feature alone is often worth the cost of lightly contorting your data into the shape assumed by the HID class. All the desktop operating systems that do USB can use HID devices, so you get broad compatibility fairly easily.
For high bandwidth, you would still be better served if your device fits one of the well established device classes, where a stock device driver on the host end of the wire can be used. One approach that often works is to use the Mass Storage class, and emulate a disk drive containing one file. Then, your device simply mounts on the host as if it were a disk, and you communicate by reading and writing to one (or a few) file.
I would expect there to be a fair amount of sample code out there for any serious USB device chipset that implements either or both of HID and Mass Storage.
If you really must wander into fully custom device territory, then you will need to be building device drivers for each host platform. The open source libusb library can be of some help, if its license is compatible with your project. There are also ways in newer versions of Windows to develop USB drivers that run in user mode using the User Mode Driver Framework that have many of the same advantages of libusb, but are not portable off the Windows platform.
The last custom device I worked on was based on a Cypress device, and we were able to ship their driver and an associated DLL to make our application code easier to build. I don't know off the cuff if there is any equivalent available for your device.
For a really good overview, I recommend the USB FAQ, and the latest edition of Jan's book, USB Complete.