It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 9 years ago.
I want to establish a secure communication between embedded devices. I am using TMS570 microcontroller and I have FreeRTOS running on it. So can you please provide me some guidelines regarding how I can implement SSL on it (preferably MatrixSSL /CyaSSL)
CyaSSL, and a demo application that demonstrates how to use it with FreeRTOS, are included in the official FreeRTOS zip file download.
The demo uses the FreeRTOS Windows simulator to ensure it is easily accessible without the need for any special hardware. Although the demo uses the Windows TCP/IP stack CyaSSL just needs a standards sockets interface, so if your TCP/IP stack has that (I can only think of one that doesn't) then the example integration is equally applicable to a TMS570 application.
Links to the main FreeRTOS/CyaSSL page and the documentation for the example are provided below:
1) http://www.FreeRTOS.org/ssl
2) http://www.freertos.org/FreeRTOS-Plus/CyaSSL/FreeRTOS_CyaSSL_Example.shtml
If you are building CyaSSL proper for FreeRTOS, you'll need to uncomment the define for FREERTOS in the /cyassl/ctaocrypt/settings.h file.
As Richard stated, CyaSSL uses the BSD socket API by default. I'm not sure what TCP/IP stack you are using, but a common TCP/IP stack to use with FreeRTOS and CyaSSL would be LwIP, in which case you would need to uncomment the CYASSL_LWIP define as well.
If your TCP/IP stack (or other transport medium) doesn't provide a BSD-style socket API, CyaSSL provides an I/O callback for applications to register their own I/O functions with CyaSSL. More information on this can be found in Chapter 5 of the CyaSSL Manual:
CyaSSL Manual (Chapter 5): http://yassl.com/yaSSL/Docs-cyassl-manual-5-portability.html
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 5 years ago.
Improve this question
I'm totally new to AUTOSAR and Arctic Studio. I have read the documentation available on www.autosar.org and now I would like to start playing around, understanding and writing some code.
I also found that only open source free development environment available for AUTOSAR platform is Arctic Studio (please correct me if I'm wrong). So I downloaded and installed it. I followed all the steps at http://212.181.18.149/wiki/Quick-start_Tutorial but unfortunately my build was not error-free.
I read example codes given in the 'examples' folder but didn't exactly get what happening or how to get started with writing even a simple code.
I was wondering if anyone could point me a direction to create a "Hello World" equivalent for AUTOSAR.
Writing a hello world equivalent in Autosar won't help you to familar with the concept.
you require the following things to get a know how about Autosar.
1)you need the MCAL(microcontroller layer),BSW and a simple application in the system.Non autosar component which can be included as Complex device driver is optional.
2)Create a sample application which sends a data 1 or 0 from a swc to any IO driver(preferable DIO)
depending on this you turn an LED on or off based on the corresponding registers
Also check for the supported boards on the Arcore site.
Commasso also provides an open source tool for Autosar but only to its members
AUTOSAR is a platform configurable based in layers.
You need the MCAL layer from the semiconductor company. The BSW+RTE layer created by your company/university or maybe some free plus the RTOS, then you integrate all for your uC, and create your "Hello World" in the APP layer, in some SWC to "print/send/show" the "Hello world" message.
If you don't have RTE or APP layer, you can create a CDD to execute your "Hello World".
The easiest way should be only using the MCAL: put the "hello world" in the main function, just integrate/configure the MCAL, (and the Startup). Check it with the debugger.
Arctic Core supports about a dosen different development boards which are listed in boards/ folder. If you have one of these, you can actually build and run a small project which prints "Hello world" over the UART or blinks a LED.
Walk through this tutorial and introduction to AUTOSAR by one of the biggest 3rd party provides, Vector Informatik GmbH.
The typical "Hello world" in the Embedded and Electronics world would be a blinking LED. Such examples exist for AUTOSAR too, however as has been pointed out you need several tools, libraries, packages, hardware to make this happen. Another way of "Hello world" in AUTOSAR could be a CAN message which you send on the bus, which is a key feature of every vehicle ECU being able to communicate.
There is another version of open source AUTOSAR platform available, How ever it is not completely free, Check this out
https://www.comasso.org/
Sorry this question really indicate that you are not much aware of AUTOSAR, as per AUTOSAR there is no UART module either.. of course blinking a LED is possible using DIO module along with PORT module.
I will try to explain as much as I can, please correct me if I am wrong and I am working in AUTOSAR development from last 5 years..
AUTOSAR is a collection of different requirement for developing ECU's in automotive industry.
Its some what open to all also, you can get all latest requirement on it from http://www.autosar.org/
Its total number of components or modules depends on your application and ECU.
Its architecture is in such a way that you can develope any one or few module or component and can use it with any other AUTOSAT compatible module / components. ( if both designed for same AUTOSAR major versions).
BR
Jerry James
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 9 years ago.
I have a Raspberry Pi, to access the GPIO pins or hardware peripherals (eg. I2C, SPI), you need to be running the program that accesses these as root. Or you can add the user running that program to the group for that peripheral (eg. the group i2c for I2C).
My question: In the real world (eg, some piece of machinery running embedded linux) is it standard practice to simply add a user to every user group for each peripheral that the program needs? Is there a better way of doing this?
My second question: How does this work when, for example, your using C to directly access hardware registers rather than via /sys. The only ways I can think of doing this is to run as root all the time which is not a good idea at all OR write a kernel module that deals with accessing the registers, while the user space program communicates with that module (which all seems like a lot of work if there are more "recommended" ways). How do programs normally access hardware registers on an embedded Linux setup?
Adding all users to all the required groups would be painful. You have a couple of options. You can make use of the setuid and setgid mechanism. With this mechanism, the process takes on the uid gid of the executable, and can then access the devices with the right access level. Or, you can leverage the sudo mechanism, where you can allow users to execute programs as root with some fine grained control.
The general model in modern OSes is to delegate the hardware access to a kernel resident device driver. In *nix OSes, the device driver then offers an API to the programs in the user space via the standard filesystem calls (open, close, read, write, ioctl). For most drivers, the ioctl call is effectively the kitchen sink for the entire API offered to the user space.
Libraries are provided with Raspberry Pi's Raspbian/Debian release for access to GPIO. Check out the back issues of The MagPi for numerous examples in Python and other languages. And also the example projects here.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 9 years ago.
I would suspect such a method might not even expose much from an engineering standpoint from the architecture and hence to not even be intrusive to the involved entity's intellectual property.
Probably not, because the JIT compiler would have to compile that code in real time first, and since drivers hook into the kernel, the kernel would be the only real program that could do that, and since this arrives the possibility of security issues I would imagine such a scenario would not be practical.
Another reason for that being impossible in general is that the internal kernel API is different, even conceptually, between Windows and Linux.
So in general a Windows driver is based on resources and functions that are Windows specific (and vice-versa).
Some clever people could do an ndiswrapper but I guess they had to simulate the Windows kernel specific API for wifi...; doing that for other types of drivers (graphics, ...) may be practically impossible.
A practical advice is to avoid buy hardware without Linux drivers (preferably free software ones). This put a market pressure on hardware manufacturers.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
There are a notebook A and a wireless access point B.
The scenario is:
1. the notebook A successfully connects to the wireless access point B.
2. the notebook A sends a "hello" message to my server.
3. my server receives this message. My question is how my server knows this message is sent by the notebook A (not other notebooks) via the wireless access point B (not via other wireless access points). Here who uses the notebook A is not my concern.
I am thinking a rough solution like this. Let my server know the notebook A's CPU serial number and the wireless access point's mac address. Any computer sending message to my server needs to report its CPU serial number and wireless gateway mac address. If these two are the same as those kept by my server, then pass.
I understand those two can be faked also. Please advise better solutions. Thank you so much.
Set up your access point to run WPA enterprise. Run the RADIUS server on your server. Optionally tunnel the traffic from the AP to the server. Issue unique credentials to each possible client, possibly certificate based.
With the RADIUS information and a "secure" (i.e. tunneled or direct cabled link) from the AP you can unambiguously and securely identify the wireless clients on the server, provided you trust the whole machine, the AP and the intermediate links.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 11 years ago.
I have a winCE device. I need to know whether the device has support for activesync. How can I check whether the device has support for ActiveSync?
Plug it in to a PC and see if the PC makes a connection?
Seriously, how, exactly, do you want to "check"? Programatically? Manually looking at the device? Some other way?
If you built the OS, it's in the catalog of the OS build.
If you didn't, then there's a file in the \Windows folder called "ceconfig.h" that outlines all of the SYSGENS used to build your OS, if it contains something like SYSGEN_AS_BASE or SYSGEN_AS_MAIL then at least some of the ActiveSync synchronization stuff was selected to be in the OS (though there are always ways to subvert the sysgen process, so it could still be missing, likewise it could also be there without the sysgen being defined). It would also bepresent in ce.bib, so if your OEM shipped you an NK.BIN and ce.bib, you could check that without even booting the device.
At runtime from an on-device app, you could look at the file system. The ActiveSync device-side piece is in repllog.exe, so it's presence in the \Windows folder would also be a strong indicator of inclusion in the OS.