In previous versions of Arduino, the limiting 8-bit microcontroller board, it seems that implementing HTTPS (not merely HTTP) was almost impossible. But the newer version of Arduino Due provides 32-bit ARM core - see spec here.
I tried to check several network libraries (libcurl, openssl, yaSSL), but I didn't find anyone that was already ported to work with Arduino Due.
OpenSSL is probably too heavy to be able to run on this processor, but I believe that yaSSL as an embedded library should be possible to do.
Do you have any information of a library that I can use to trigger HTTPS requests on Arduino Due?
Unfortunately this is too long for a comment.
► No out of the box solution
From what I have gathered, there is no straightforward solution for a webserver running on the Atmel SAM3X8E ARM Cortex-M3 CPU that outputs HTTPS out of the box.
Texas Intstruments provides better options at the moment using their boards equipped with a Stellaris Microcontroller ARM Cortex-M3 CPU.
► Alternative
There are several options available that render cryptographic functions, based upon which one could lay out and implement a simple secure communication protocol that communicates with an intermediary device, which in turn facilitates Rapid Application Development and SSL.
This intermediary device, for instance an off-the-shelf 70$ Android smartphone that keeps your project mobile and connected, runs a service on a specified port which in turn communicates with Amazon SQS. Already available. This may sound ugly or tough, but is much easier than doing the programmatic groundwork for a webserver with full TLS 3 support on the Arduino. Given the proper motivation the latter may be easy, but not if one just wants a fast pragmatic solution to one's own project.
► Cryptographic libraries
crypto-arduino-library http://code.google.com/p/crypto-arduino-library/ (not maintained since 2010)
matrixssl
mbed TLS (formerly PolarSSL)
wolfSSL (formerly CyaSSL)
► Discussions
Following is a list of discussions to get you started:
HTTPS alternative on Arduino
SSL from a Microcontroller
Lightweight Packet Encryption
Many of these libraries would still need to be adapted, but community experts can help you with that fairly quickly.
Good luck! If you are at liberty to upload your final project to github then you just gained a thanks and a follower.
IMHO Arduino (including the DUE) is the wrong tool for heavy and/or encrypted web based communication. I would strongly suggest to look for more appropriate hardware in the same size and price range. As soon you get into https you are close enough to also want a lot of the other stuff that real operating systems provide. With other words I suggest to go for something like the Raspi. Similar size and prize but way more powerful, especially it can run Linux. --> HTTPS becomes simple.
The big problem with https support on an arduino is the danger of overloading your processor which could make the project unviable.
Even embedded platform targetted solutions like PolarSSL can eat up too much memory and use too much processing power. Remember that even on the most streamlined implementations, SSL support is going to have to be generalized for wide adoption and will include components that you won't find necessary. There's also the question of which Certificate Authorities you will trust and how you will communicate with them for things like certificate revocation.
I would look instead towards a solution that isn't as broken on the surface for your needs. Something like CurveProtect, which is an implementation of CurveCP.
Of course, your decision will largely be based on what you want to do and how much time you want to spend figuring the problem out. PolarSSL has a footprint that can be as small as 30K (more typically close to 100K).
Related
In the Wi-Fi infrastructure mode, as to let stations communicate without creating packet collision, there is a randomized back-off delay in addition to the default delay before emission.
Is it possible to reprogram the Wi-Fi protocol in C or any other language\environment and change things about the details of the implementation, like for example disable completely the randomized back-off or alter it ?
(PS : please excuse me for the weird sentences, not my native language).
Thanks in advance,
If the implementation of the transmission back-off is open source, then there should be no reason why you cannot modify it.
However, this part of the protocol tends to be implemented in the WiFi radio devices, which tend to not be open source, and even if they are, tend to require specialised tools to program and debug. Sometimes there are methods to manage updating the firmware from the drivers (which allows the vendor to ship firmware upgrades via drivers), but not always, and they tend not to be public interfaces.
On the DroneKit.io page, it mentions using DroneKit Python when creating Ground Control Stations for Windows. However, there appears to be no documentation for this.
Is it meant to simply simulate a com port and act as a proxy for other Ground Control Stations, which just makes it easier hijack the MAVLink?
Also, it mentions Python being used for low-latency processes. This seems to be oxymoronic. Is there a reason that it would be better than just using C/C++ for the purpose of hijacking the MAVLink?
Thanks!
DroneKit-Python can be used either to create a python-based ground station or it can be run on a companion computer. There is no practical difference between the two except how you set up the connection to the vehicle from the computer running the script. The different ways of starting MAVProxy for the different connections are covered in the Getting Started documentation.
The reason that there is no "specific" documentation on using DK-Python for GCS is primarily "marketing". The far bigger market for ground station GCS software is in tablets/phones that will use DK-Android or a future iOS port. DK-Python has been positioned solely as for use in the air interface. Even though there is no "specific" documentation, in fact all the existing documentation is relevant.
Is it meant to simply simulate a com port and act as a proxy for other Ground Control Stations, which just makes it easier hijack the MAVLink?
No. See above.
Also, it mentions Python being used for low-latency processes. This seems to be oxymoronic. Is there a reason that it would be better than just using C/C++ for the purpose of hijacking the MAVLink?
It doesn't mention low-latency processes, so the answer is "invalid question".
You're probably misreading the text "that require a low-latency link". The point here is that if you have dronekit-python running on a companion computer and connected by a fast link you can do real time handling of incoming sensor data. This allows computer vision control of the UAV. However if you run DK-Python on a ground control station you will have a much slower link. You can still control movement of the UAV but the latency will be much higher.
Hope that helps!
I'm just starting a new project, a thermostat connected to wifi and controlled anywhere from mobile phone. I've seen the Nest Thermostat which has a Cortex-A8 but I need to make a simpler and cheaper one, just a Cortex-M3 + wifi + temperature sensor, no screen.
The Android app (developed by other people) uses Firebase, so my embedded system should use it.
I've selected a tiny RTOS, CyaSSL and lwIP, but this is my first Internet project and I need help with Firebase and everything related to Internet.
Is a Cortex-M3 suitable to connect to Firebase?
Is the selected software suitable to connect to Firebase?
What software do I need besides the selected? (Firebase API REST, JSON parser... and any software I don't even imagine)
I haven't found almost any info about such a system, there are some questions but most of them have no answer.
Thank you in advance
As I understood, to use the REST API you just need to implement the HTTP protocol, there is many RTOS that have full HTTP and HTTPS implementation.
I never used, but I know that mbed (http://mbed.org/) is designed for IOT,it is free, and developed by Arm, so it is probably the best way to go.
Just look for a C/C++ JSON Parser lib if it is not ready, otherwise you should develop one for yourself, it looks pretty simple.
I am working on a project to embed a web server written in C into a device. The requirement is that it should support web services (SOAP / JSON-RPC) and should be compatible with ARM processor. Any suggestions of specific products or where to look first?
Given your description: Linux based platform with 256MB RAM, you can basically use any web server you like. 256MB RAM takes your device out of the typical embedded territory into server space.
Don't worry about ARM support too much because it is well supported by the Linux community. It is one of the architectures that is officially supported by Debian. I myself run a couple of web servers on ARM running Debian and lighttpd with hardware having only 32MB RAM.
The top three most popular web servers (and popularity is quite important since it means you can easily google if you have a problem):
lighttpd - very light on RAM usage since it is single threaded and very light on CPU usage as well. The disadvantage is that it can be slow to respond if you try to run heavyweight, CPU intensive CGI applications on it since it is single threaded.
Apache2 - heavy on RAM usage. Apache's default operating mode is to keep threads alive as long as possible to handle heavy loads. This means most of the time you use up RAM on sleeping processes. But if you DO need to handle heavy loads this is a good thing. Good for heavy duty CGI apps.
Nginx - the new kid on the block. Not as well documented (at the moment, obviously documentation improves with time) as either lighttpd or Apache but people have been saying that it outperforms both. It is multithreaded like Apache2 but nonblocking like lighttpd so it has the best of both worlds: it uses less RAM that Apache2 (though more than lighttpd) in general and performs at least as well if not better than Apache2 under load. The only real downside for me is the documentation.
If the device is really short on resources consider an embedded webserver library like Mongoose or libsoup (using GLib). However note that services like SOAP and XML parsing in general are pretty heavy on resources.
I was asked to develop a algorithm for network application on C. This project will be developed on Linux for PC and then it will be transferred to a more portable platform, something that will include a microcontroller. There are many microcontroller/companies out there that provide very nice and large libraries for TCP/IP. This software will hold statistics on the network performance.
The whole idea of a cross platform (uC - PC) seems rubbish to me cause eventually the code should be written in a more platform specific way for the microcontroller, but I am not expert to judge anyway.
Is there any clever way of doing this or is there a anyone that did this before? My brainstorming has "Wrapper library" and "Matlab"... Any ideas?
Thx!
I do agree with you to some extent - you do want the target system and the system on which you are developing in the interim should be as close as possible (it is better if they can match). Nevertheless the idea with cross-platform is to get you started with the firmware development while the hardware is being designed. Instead of doing it on Linux - what I would do is to use Embedded OS simulator. Here are the steps
- Step 1: Identify the OS for the Embedded System; make sure that OS has a simulator that runs on PC (Win or Linux) Typical Embedded OS with Simulator include VxWorks, μC/OS-II, QNX, uClinux ... Agreeing on the OS means that the hardware design team knows that the OS is the right match for the hardware that is being designed and there is a consensus that the hardware + OS + Application being designed will meet the requirements of the system that is being developed.
- Step 2: Use this simulator to develop the application until the hardware that is being designed is brought up.
- Step 3: Once the first version of the hardware is ready and has been powered up - you can run your application with minimum changes - mostly likely no changes to the code, but changes to the linker/library being used is likely.
The idea of cross-platform if done correct has immense advantages - it helps remove serializing your project development activities.
Given that you mention it is a TCP/IP application - check for Berkeley Sockets support and you use it. Usually this API should not matter if you are using a Simulator, in the extreme case if you have to change the OS for whatever reason your Berkeley Sockets based application is likely to be better portable.
Just assume you can use the standard BSD socket library (system calls are socket(), bind(), accept(), connect(), recv(), send(), with various options). Any OS with a TCP/IP stack will support this standard API.
There may be some caveats that you will run into if your embedded system uses a run to completion type TCP/IP stack like *u*IP, but those will be easily solvable.
Also only use POSIX file I/O (fopen, fread, fwrite, printf, etc). But keep in mind your target may not have a filesystem.
If using a simulator was not an option I would try to wrap the Linux functions up in interfaces that match those of the embedded system, if possible. That way any extra bulk in the system will be on the Linux development system (which is not resource constrained). Various embedded OSes and TCP/IP stacks can have vastly different architectures, so how easy this is can range from nearly impossible to no work at all.
If it turns out that writing wrapper libraries to make Linux look like the embedded system is too difficult then I suggest at least trying to keep the embedded OS in mind while writing the Linux version so that you can try to at least write some functions so that they work on both systems.
If it doesn't take too long writing a Linux version of at least part of the code may help you to shake out a few flaws in the overall design, at the very least. At most it will allow you to more quickly test changes to the system since loading code onto an embedded device often takes more time than you would like. It may also be easier to debug on your development machine.
Some embedded OSes will run on x86, and it would not surprise me if some of them have drivers that allow them to be run in virtual machines, so this may be an option as well.
Another thing to consider is the endian-ness and the word size of the development machine verses the embedded system. If these differ then you need to keep this in mind as you code. Getting this type of thing right when you originally write the code is easier than going back and trying to fix code, in my opinion.