I wonder when one will favor Greengrass over FreeRTOS? Any gotchas or empirical heads-up will be highly appreciated
Thanks!
Greengrass is designed for edge devices that are considered as heavier computer (at least in the edge), such as Raspberry Pi, IMX6/IMX8 devices and even PC's.
FreeRTOS (and AWS FreeRTOS) is designed for much leaner MCU (Microcontrollers), such as ESP32.
Greengrass and FreeRTOS are two totally different types of software. FreeRTOS is an "operating system" that powers embedded MCU for sensors and smart lightbulbs, for examples. Greengrass is AWS's IOT edge computing platform and it runs on Linux.
Related
I was wandering, why there are no implementations of the devices written in CMSIS-Driver?
I mean that I have few peripherals: LCD, temperature and pressure sensor, current meter etc. - all of them very popular used in arduino and learning sets.
Each of these devices uses some protocol to communicate with the uC. some are for i2C, some communicate by SPI, some by UART. I was wondering if there are drivers that handle those devices, and as a backend use CMSIS-Driver API.
I think that it is a decent api, and after all standard develop by ARM, so why I can not find any drivers using it?
For example when I was looking for s18b20 (temperature sensor for 1-wire), I was easily able to find driver for this device written in RUST language, but I was not able to find any implementation for C that would use CMSIS. (in this case compare to rust is quite solid, because Rust has nice embedded API, and you can easily use the driver on multiple targets, just like CMSIS-Driver is spouse to work)
I was able to find some projects using this peripheral, but they all operated on HAL that is different for every uC, so the implementation is not portable ( unlike RUST, and potentially CMSIS-Driver)
So my main questions are:
Why there are so little implementations based on CMSIS-Driver? Maybe there is some hidden implementation repository that I do not know about?
Am I missing something? Is the CMSIS-Driver not designed for the casual developers? Who is it designed for then ?
CMSIS is not concerned with external devices, it deals primarily with interface drivers for interfaces on the microcontroller die. So if you have an SPI device, you might use the CMSIS. SPI driver for that part, but it is then your responsibility as a developer to write the higher-level driver for the external device.
Higher-level software platforms such as ARM's embed, or ST's CubeMX use CMSIS interface drivers, and include drivers for common higher level devices. They tend to be for more complex devices related to networking, filesystems and displays. I would not expect much support for such trivially simple devices such as a temperature sensor.
I don't know if this is the right place to ask this. Sorry if I'm wrong.
I'd like to know if you can run code in an Xbee module without being connected to the computer or another device like arduino.
For example, I want to have 2-3 Xbee modules that communicate with each other sending information and then take decisions by code dynamically without using the X-CTU software. And I don't want those Xbee modules to be connected to the PC or other devices, they have to run by themselves with a coin cell battery and run some code previously written into their memory. Is this possible? If so, can you provide me some info/documentation to take a look? which language do you have to use to program the code? Which Xbee model do I need?
Thank you!
The XBEE modules can not do such tasks without a host. You can not run your own code on the module.
If you want to run you own code on the same device as the ZigBee stack then you should choose a solution from a silicon/stack provider.
You could achieve your goal using the Texas Instruments ZigBee Home automation SDK from www.ti.com/tool/z-stack which runs the ZigBee stack and your application on one of the TI ZigBee SoC's. But there are likely other similar providers as well.
Regards, TC.
XBees can be configured to initialize themselves with network data, i.e. the PAN ID, so they're aware of how to communicate on start up without requiring external configuration. However, they cannot run headlessly; they must to have some idea of the data that needs to be sent. They're fundamentally designed to act as a transparent serial bridge between computers to aid communications on personal networks. They cannot however be configured to do something bespoke.
It sounds like you're worried about power, so you could try looking for a low-power microcontroller that possesses a USART; this is all you'll need in order to communicate with an XBee via Serial.
It isn't possible to put your own code on a standard XBee module, but Digi does offer a Programmable XBee that includes a Freescale HCS08 co-processor that you can write code for. They offer a development kit with sample programs to get your started.
For a small-scale project where you don't need to be ZigBee certified, that might be easier than getting up to speed with a ZigBee development kit from TI, Freescale or Silicon Labs.
I'm trying to make a new app that talks to a bluetooth low energy chip. I have never played around with bluetooth or BLE before, so I'm trying to learn as much as I can about it. I know that I have to implement Apple's Core Bluetooth framework, and from there I have a few very basic questions.
Is the code for writing apps with classic bluetooth the same as apps with BLE, or are they different?
What's the deal with AT commands, I tried reading a bit into it but are those something I have to mix with Objective-C while making a call to the device?
Central and peripheral. I noticed that when you are making two devices talk to each other, one has to be central and one peripheral. Lets say I make an app that turns on a light via a bluetooth low energy chip. Would the iPhone be the peripheral, and the chip / light be the central?
Bluetooth "classic" and Bluetooth Low Energy don't work the same way. Bluetooth Low Energy works with Peripheral->Service(s)->Characteristic(s) (it's like a tree)...
There are a few videos at the WWDC 2012 session (from the Portal iOS Developers) dealing with Bluetooth Low Energy and the CoreBluetooth.framework.
There is also sample code (CoreBluetooth Temperature Sensor) from Apple.
Apps to play with and free : LightBlue & BLE Utility, which can convert them into Peripheral/Central and interact...
I need to integrate a network stack into my embedded application. It can be a cross-platform real-time network stack written on C. The application is based on ARM7 processor and FreeRTOS kernel.
For example I would use TRECK (Treck Inc.) or Fusion (Unicoi Systems) real-time network stacks if they were free. Also I know that, for instance, there are ports of FreeBSD's and OpenBSD's network stacks to eCos operating systems, but is it possible to obtain them as a stand-alone package so that it's relatively easy to integrate them? Although I suspect they are not real-time.
Please, do not suggest me to change the OS for my application to one that has a built-in network stack. :-)
Why, I've found at least uIP and lwIP open-source network stacks. But they appear to be not real-time.
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).