I want to create hardware accessory for iPhone and iPad but there is very less resources out there. I am not a programmer or engineer. My concept is very simple building a number pad connected through lightning cable. It will have 6x4 keys layout, in this 4 keys can be customize as per need means key a will work as copy(command+c)key b will work as paste(command+v) this keys can be customised in diffrent kind of shortcuts. I dont want a blueetoth connectivity.
Do I need a arduino or raspberry pi kind of device to program and test run a functional prototype?
What kind of cable do I need to sue to communicate with the device?
What kind of programming langauge do i need to learn?
Do I need to first register for Mfi program or I can do it after I develop the product?
As far as I'm aware, you'll need to join MFI for developing Lightning accessories.
However, you don't need Apple's permission for designing and building your own Bluetooth LE (Bluetooth 4.0) accessories. You should be able to do what you want by programming a Bluetooth LE capable microcontroller to act as a HID device that sends the key events you want. I've not done this specific type of project myself and I'm far from an expert on embedded stuff, but Adafruit have a bunch of resources and development boards on Bluetooth LE using Arduinos and other dev boards. I believe they even have something that already acts as a HID device. I'd start researching in that direction.
Another option is to program a microcontroller to act as a standard USB HID keyboard device, and plug that into the iDevice using the Lightning to USB Camera adapter. iPads recognise standard USB keyboards without needing MFI approval, but you do need to use Apple's adapter. Note that the adapter allows the USB device to draw very little power (50mA I think) so it will not work with any device that requires more. The USB3 version of the adapter has an extra power input and so allows you to attach a USB device that draws more than that.
I'm trying to read Bluetooth Low Energy transmitted data programtically using Ruby. Bluetooth Low Energy technology provides no support for the Serial Port Profile (SPP) in the standard Specification v4.0.
With older Bluetooth communication methods, one can just read the serial port for Bluetooth incoming data (/dev/tty.Bluetooth-Incoming-Port). Clearly, this won’t work for Bluetooth Low Energy, given it works almost completely differently.
I came across a few tools like LightBlue and XCode Hardware IO tools to read the data transmitted by the said Bluetooth Low Energy device but I’m not sure how they work. Can somebody help?
Reading up on fundamentals really helped me a lot. Here's a link to great post explaining BLE basics. Having understood this, on OSX I ended us using noble to establish connection and read BLE transmitted UART data using another library using noble called blendmicro.
We didn't use blendmicro BLE chip but still were able to use blendmicro-node library. If you read through blendmicro.js, it's easily modifiable to suit any BLE chip that uses UART for data transmission.
I'm developing an authentication system with NFC technology with strong cryptographic functions.
There are two solutions from NXP: Mifare DESFire EV1, which is a chip with memory areas and 3DES and AES128 crypt functions, and SmartMX2,which is a complete MCU that needs an OS and software to run.
To choose between the two, I have to know how to program those tags. For what I've understood, the DESFire needs a USB reader/writer and the interface software, like this --> http://www.mpsys.de/chipmanrfid_en.html
What equipment is needed to install the OS on a SmartMX card, and then debug? Is it possible to do it only via NFC interface?
Thanks for your attention,
gfunky
SmartMX cards always come with the Card OS installed. The Card OS is actually fixed in the ROM mask of the chip. An example of such a Card OS is NXP JCOP; an implementation of JavaCard.
Developing JavaCard applets for JCOP is usually done in Eclipse. NXP offers JCOP development tools to customers that consist of a plug-in for Eclipse. Debugging is not possible on the card itself (also for security reasons), but is done in a simulator that runs on the PC.
DESFire is a chip with fixed functionality. It has its own command set to do things like creating files, reading and writing data and performing authentication. In principle, this can be done using any software that allows sending commands through a contactless card reader. But specialized software that has built-in support for DESFire will be very convenient and likely speed up your development a lot.
I am planing to spend few days a week writing a driver for a Greenpacket USB WiMax modem. Greenpacket only provides Windows driver with it and as I am fond of Linux and Mac I feel very bad not having driver for them.
I have experience writing C++ programs so I think it won't be hard for me. Even I like C++ programming very much. I have never written drivers but I know some concepts. I have PDF of the device specification from the company's website.
I would like to ask if I can write driver with that provided specifications? If yes what would be my starting point assuming I would like to write it for MAC first and then Linux. I am reading this article right now but your experiences would be of great help.
The product specifications sheet does not provide enough data to write a device driver. You are going to need low-level information about how to speak with the WiMax device via USB. You are probably also way out of your depth of you think a product sheet is enough information to write a device driver.
I know this probably is not the easiest thing to do, but I am trying to connect Microcontroller and PC using USB. I dont want to use internal USART of Microcontroller or USB to RS232 converted, its project indended to help me understand various principles.
So, getting the communication done from the Microcontroller side is piece of cake - I mean, when I know he protocol, its relativelly easy to implement it on Micro, becouse I am in direct control of evrything, even precise timing.
But this is not the case of PC. I am not very familiar with concept of Windows handling the devices connected. In one of my previous question I ask about how Windows works with devices thru drivers. I understood that for internal use of Windows, drivers must have some default set of functions available to OS. I mean, when OS wants to access HDD, it calls HDD driver (which is probably internal in OS), with specific "questions" so that means that HDD driver has to be written to cooperate with Windows, to have write function in the proper place to be called by the OS. Something similiar is for GPU, Even DirectX, I mean DirectX must call specific functions from drivers, so drivers must be written to work with DX. I know, many functions from WinAPI works on their own, but even "simple" window must be in the end written into framebuffer, using MMIO to adress specified by drivers. Am I right?
So, I expected that Windows have internal functions, parts of WinAPI designed to work with certain comonly used things. To call manufacturer-designed drivers. But this seems to not be entirely true becouse Windows has no way to communicate thru Paralel port. I mean, there is no function in the WinAPI to work with serial port, but there are funcions to work with HDD,GPU and so.
But now there comes the part I am getting very lost at. So, I think Windows must have some built-in functions to communicate thru USB, becouse for example it handles USB flash memory. So, is there any WinAPI function designed to let user to operate USB thru that function, or when I want to use USB myself, do I have to call desired USB-driver function myself? Becouse all you need to send to USB controller is device adress and the infromation right? I mean, I don´t have to write any new drivers, am I right? Just to call WinAPI function if there is such, or directly call original USB driver. Does any of this make some sense?
To make your life easier, and avoid writing your own driver, try using the HID (Human Interface Device) API on top of USB. Although it says "Human Interface", it doesn't actually have to be for devices that a human controls. The advantage is that modern OSes already come with a HID driver and you can use sample code such as what you can find here to get started. Many microcontroller manufacturers provide suitable code for the embedded of the protocol.
Because OSes already understand HID, if you build a device using the HID interface you'll find that not only can you read from it from any OS, you may also find that many applications can already talk to your device if its communication is restricted to a small enough subset of HID. (For example, I built an input device for a music app, but amazingly I found I could literally plug it straight into a 3D animation app we use at work, running on a different OS, and have it work right away without writing a single additional line of code!)
This answer might aim you in the right direction.
The first answer here might also be helpful.
The answers to this have some actual code and links to yet other resources.
USB includes a set of stock functionality, much like supporting USB flash drives (USB Mass Storage class). The two most interesting for microcontroller interfacing are HID and CDC. CDC is easiest to use as it directly emulates an old fashioned serial port.
If you configure the microcontroller to act as a CDC device, Windows will enumerate it as a serial port, and all the old serial APIs will work on it.