I have seen the wikipedia article which is a bit sketchy on the details.
I would like to know, in addition to general principles of operation, some practical details like:
Are they limited to compiled native programs or they can be employed with Java/Dot Net etc?
You have to check with the manufacturer of the dongle on what languages they support. Usually for Windows OS a DLL is supplied that can talk to the dongle and any language that can call into a DLL can use the dongle.
Related
Some context: I'm working on embedded system with Micro-Controler targets. My purpose here is to clarify the terms I can use for my code repository names. I focus on the low-level naming in that post which represents for me the target-oriented code (versus application-oriented code for the high level).
I enter in a loop over the web and forums where nobody seems to clearly defined the difference between these terms: HAL vs BSP vs Drivers.
According to me, all my three terms are theoretically equivalent, but people seems to make difference where the HAL is reserved for the MCU drivers (e.g. UART, GPIO, ...) and the BSP is reserved for the external peripheral drivers (e.g. accelerometer, EEPROM, ...).
Can somebody help me to clarify this? Additionally, can you mention if your answer is based on your personal opinion or if it is based on the reasoning/rationale of a community/company/standard/whatever?
Thank you for your time,
My particular hardware target is a MinnoboardMax Turbot Dual-E, but I believe this question is generic to Intel Atom/BayTrail processors on other boards.
The SoC has a "multifunction serial port" (SSP) that can be used as a SPI bus interface. It can be attached by ACPI or by PCI (in the later case, the PCI id is 0x8086:0x0f0e). And within the Linux kernel, there is existing driver support (low_speed_spidev, spi_pxa2xx_pci, spi_pxa2xx_platform) which allows access to the hardware.
I would like to access the hardware from UEFI, and I'm finding very little documentation on how to access or program this hardware. I don't care very much whether I have to set it into ACPI or PCI mode in the BIOS, either one is OK for my purposes. I'd love to find an existing driver, but after half a day of searching I'm pretty convinced it's not out there. (Happy to be proven wrong on that.)
In lieu of that, can anyone point me to any code examples that would help to bootstrap this? I've tried looking at the Linux and BSD source code, but they both involve so many extra layers for generality/portability that I'm having trouble sorting out the portions that relate to this particular device, and the portions that simply support a generic driver model.
Edit: Post originally mistakenly said AHCI.
As I understand, ACPI defines a generic hardware programming model where operating system relies on the OEM firmware provided AML (ACPI machine language) code to manipulate the hardware.
In order to execute the AML code, operating system has to incorporate an AML interpreter.
So, it looks to me that firmware developers use AML to provide a control interface between platform hardware and operating system.
But do we really need AML?
I think ultimately the hardware can only be configured through the native instruction of the platform. So the AML interpreter must translate the AML into native instructions otherwise it cannot be executed on the platform.
But what's the point of using an intermediate language like AML? I mean though the AML is said to be platform-independent, which means I can use AML to describe my platform in a non-native way.
But the AML is part of the platform firmware in practice. And the entire firmware has already been built into the target platform's native instructions. So what good can it be to make such a little part of the firmware as platform-independent? Why not just use native instructions? There must be some way to let OS use it as well. And this way operating system doesn't need the AML interpreter at all. A lot of complexity can be avoided.
One of the big goals of ACPI over its predecessor APM was to give the OS more viability and control over power state transitions.
APM was a black box. The OS knew nothing about the power management implementation. It would just call a BIOS function and the BIOS handled all of the magic. Did it work? Did the system sleep properly? Did the system freeze? Was a user application able to handle the BIOS implementation? The sad truth was that many systems had power management that was downright broken, and Microsoft wanted to provide a better power management experience for the growing laptop industry.
Now, the BIOS hands the ASL/AML code over to the OS and the OS executes it not the BIOS. If the BIOS code does something dumb (like messing with registers it shouldn't), Windows can detect that by parsing the code and block it. AML is 100% decompilable unlike C.
Remember that ACPI is not x86 specific. At the time it was developed, Itanium and Xscale were around. Intel and Microsoft needed a language that would work on all platforms, both 32 and 64 bit.
Lastly, ASL is more than just a list of executable functions. It is also number of static configuration tables. The ASL code has tables to define the non PnP hardware built onto your motherboard. It has tables of supported power states. A traditional programming language like C isn't really setup for that.
If ACPI was invented today, they would probably use something like XML to provide the info to the OS.
Originally, hardware for "80x86 PC" was cloned from IBM's PC, and this created an effective de-facto standard for hardware to follow. However it didn't take long before manufacturers wanted to add features that didn't previously exist, where there was no (official or de-facto) standard to follow.
This led to a major problem for operating system software (how do you support "non-standard chaos"). Some standards were created for some things (APM, etc) but they didn't really cover everything needed and became out-of-date. ACPI was created to fix this.
Ideally, what was (and still is) needed is standards that allow operating system to detect and use supported features of the motherboard. For example, a "standardised case temperature and fan control" device (with support for detecting how many fans, temperature sensors, etc), or a "standardised CPU speed/power consumption", a "PCI slot IRQ routing for IO APICs" standard, a "hot-plug PCI controller device" standard, etc.
However, ACPI didn't provide useful standards that hardware manufacturers and operating systems can use. Instead, ACPI provided an over-engineered mess (AML) to allow an OS to cope with ACPI's failure to standardise the hardware.
Essentially; we "need" AML now because it's the only viable way for an OS to work-around the "non-standard chaos" problem that ACPI failed to fix.
The problem with providing native code instead of AML is that different operating systems use CPUs in different ways (e.g. native 64-bit 80x86 code in firmware would be useless for an older "32-bit only" OS). AML provides portability between different types of CPUs and between the same CPU/s in different modes.
Also; native code is considered a major security problem (rootkits, etc); and people tend to think an interpreted language mitigates that problem. Of course in practice AML needs far too much access to the underlying hardware and does it in a way that an OS can't check, and there's isn't even a way for an OS to determine if the AML has been maliciously modified before the OS booted. For these reasons AML is still a major security problem despite using interpreted language.
I have some basic requirements. In an windows PC I am supposed to
Read some files.
Perform some scientific computations on read file.
Send and receive data to a board through peripherals.
Was searching for lightweight scripting language and stumbled upon Lua! Want to validate here, if Lua is a good choice? Questions are:
Are there Lua libraries which can handle USB, Ethernet et.al. drivers ?
Are there libraries available in Lua which can be used for scientific computation and/or data mining. In this case I will be needing linear algebra support, numerical analysis support and few more.
Please let me know your opinion if my choice is correct.
Lua is very good for scientific computation because of Torch (http://torch.ch/). The problem in your case would be the periphery support on Windows. For Linux there is https://github.com/vsergeev/lua-periphery but I'm not sure if there is anything good for Windows out there.
I'm figuring that CORBA is considered a legacy technology that just refuses to die. That being said, I'm curious if there are any known standards out there that are preferred (and are also as platform independent.)
Thoughts? TIA!
Many organization are moving to WebServices and the open standards relating to them (HTTP, WS-*) as alternatives to Corba.
This article provides a comparison of the two technologies and offers some recommendations on when to use which.
If you really care about platform independence and protocol standardization - then the WS-* standards are something to look into.
There is now a state of the art modern CORBA implementation using C++11, TAOX11. This uses the new IDL to C++11 language mapping. For TAOX11 see the TAOX11 website. TAOX11 is supported on a wide range of platforms and compilers.
I have recently tried Google Protocol buffers, they seem rather similar to CORBA by design (some kind of IDL with compiler, binary compact messages, etc). It is probably one of the many possible successors.
Web services are good for the right tasks but creating and parsing messages needs more time and text based messages are more bulky than binary ones. REST API with JSON looks like a good solution where binary protocols do not fit well.
ICE from ZeroC aims to be a "better CORBA".
Unfortunately their licensing terms are crap (at least last time I checked with them), as they do not sell developer licenses but only (roughly) per-installation terms.
It is offered via GPL license too, if you can live with this.