German forum announcement

Engineers working in the development of software for automotive embedded computers will have the opportunity to learn about the latest tools and techniques at Lauterbach's September Automotive Forum. However, much of the content will be based around the embedded computers development and validation of Autosar compliant code and the development of code for specific devices such as the BOSCH GTM, the AURIX and Freescale's Nexus based Qorivva solutions. Some of the presentations will also touch on the debugging of code on multicore systems. Delegates will also have the opportunity to discuss their specific challenges and requirements.

refer to: http://embedded-computing.com/news/lauterbach-software-debugging-workshops/

Microelectronics application on mobile cars

Today, microelectronics enable advanced safety features, new in-vehicle information and entertainment services, and greater energy efficiency. The electric/electronic share of value added to a state-of-the-art vehicle is already at 40 percent for traditional, internal combustion engine cars and jumps as high as 75 percent for electric or hybrid electric in-vehicles. This trend will accelerate as advances in semiconductor technology continue to drive down the cost of various electronic modules and subsystems. What's more on the global mobile market, let us just wait for the next trend arrive.

refer to: http://embedded-computing.com/articles/automotive-industry-innovation-driven-electronics/#at_pco=cfd-1.0

Case study: Challenges in incarnating a credit card sized SBC

The initial goal in creating the Raspberry Pi credit card sized, Linux-based Single Board Computer (SBC) – targeted primarily at education – was to develop a response to the decline of students engaging with computer science and related engineering disciplines. Our desire was to reverse the trend of children becoming consumers rather than creators. The following case study follows the hardware development process from an early failure, initial prototypes, and through to the finished production design.

Over recent years there has been an increasing trend for children to be consumers of digital content rather than be future creators or engineers. This trend is driven by manufacturers looking to provide a seamless experience for target customers on a variety of electronic platforms, from gaming consoles to tablets and laptop computers.

As a result, access to raw I/O has become restricted. Similarly, any packaged provision of a programming environment is an anathema to the products’ commercial goals. The knowledge required to create “hello world” or flash an external LED has become simply too vast and the opportunity to learn vital skills such as structuring/codifying ideas and debugging has been largely subsumed by a click-and-shoot world. Any motivation to get under the hood and see how these products work is largely dissipated by the impenetrable barriers presented by these “locked down” systems.

The challenge in developing the Raspberry Pi credit card sized, Linux-based SBC was to break down these barriers and provide access at a sufficiently low cost so any fear of breaking the hardware was effectively removed. Having the hardware is only half the story; the provision of a rich set of programming environments such as Scratch and Python with libraries to allow control of peripheral hardware provides an engaging toolset for learning through experimentation and play in either the formal classroom or at the many school and independent maker (hackspace) clubs. The following case study shows how Raspberry Pi was developed from the ground up.

refer to :http://embedded-computing.com/articles/case-card-sized-sbc/

Wi-Fi applications on in-vehicle video performance

Although video over Wi-Fi applications have been available for quite some time, this is the industry’s first attempt to develop an interoperability specification for video distribution. It specifies provisioning and management for negotiating video capabilities between a source and sync device, standard video transcoding schemes built on H.264, transport and control schemes, packetization, and content protection based on High-bandwidth Digital Content Protection (HDCP) 2.0. Many of the device and in-vehicle discovery components of the protocol are built around the previously released Wi-Fi Direct specification. The WI-FI CERTIFIED Miracast specification enables car manufacturers to wirelessly mirror smartphone screens to in-dash LCDs, creating an immediately personalized interface in the dashboard. Additionally, this in-vehicle standards-based technology allows consumers to safely control smartphones through the dashboard so they can answer calls and check text messages.

refer to: http://embedded-computing.com/articles/wireless-accelerate-next-wave-in-vehicle-innovation/

1U Networking Appliance System with 3rd generation Core i

ANR-IB751N1/A/B networking appliances.


ANR-IB75N1/A/B is a rackmount platform (440x372x44mm) which can be installed in the 19” rack. It can carry a 3rd generation Intel Core i i3, i5, i7, or Pentium processors to deliver higher efficiency, increased processing throughput, and improved performance on applications. ANR-IB75N1/A/B also comes equipped with a maximum 16GB DDR3 memory and optional 2 or 4 x SFP and 8 x LAN ports. System Integrators can select different configurations for their network appliances. It offers the best P/P ratio in applications like the UTM, IDS/IPS, VPN, Firewall, Anti-Virus, Anti-Spam, RSA gateway, QoS, streaming.
ANR-IB75N1/A/B uses 80 Plus PSU which reduces energy consumption and helps protect the environment. The software and hardware configurable LAN bypass feature also prevents communication breaks due to power loss or system hang-ups. In addition to Intel long life support chipsets, ANR-IB75N1/A/B is designed with a long-term support of 5 years.

(Software) Static analysis helps manage risk

When it comes to software development, the old adage is best spun in a slightly different way: better "early" than never. Accordingly, static analysis can help those developing in Java to stay one step ahead of potential coding problems.

Today’s software development teams are under immense pressure; the market demands high-quality, secure releases at a constantly increasing pace while security threats become more and more sophisticated. Considering the high cost of product failures and security breaches, it is more important than ever to address these risks throughout the software development process. Potential problems need to be spotted early to prevent release delays or, worse, post-release failures.Fortunately, there are numerous tools to help developers manage these risks, helping to identify potential problems early in the development phase when issues are less disruptive and easier to fix. They are readily accessible to developers and easy to use within many development environments. This applies to developers programming in any language; however, we focus on Java in this discussion (see Sidebar 1).

Sidebar 1: Though Java’s mature ecosystem, numerous IDEs, and abundance of reference materials ease Java application development, they can also bestow a false sense of security upon developers, who should be watchful to mitigate Java’s weaknesses.

Static analysis helps mitigate risk

When considering static analysis tools for Java or otherwise, it is important to understand what these tools are. The term “static analysis” refers to the approach of analyzing a program without executing it. As we’ll see in the next section, static analysis tools can be used to produce reports on anything from coding standard violations to specific errors or vulnerabilities. Simply put, static analysis tools analyze source code to find information useful for managing risk.

One benefit of static analysis is that it can be performed early in the development cycle, often before the application will even execute. It is commonly integrated into an automated build, so that there is virtually no overhead to running frequent analyses. By integrating static analysis into the inner development loop, users maximize the value they get from such tools.

When used in conjunction with a well-designed development process, static analysis tools provide crucial visibility into the state of the software. This enables development teams to understand the level of risk in their code and where the risk resides so they can take action to mitigate or remove it entirely (Table 1). Individual tools generally focus on specific problems faced by software development teams, and teams often use a combination of these tools to get a comprehensive view of their development effort.

Table 1: Static analysis tools typically find specific types of issues, with each type representing a different class of risk and requiring a different type of action.

Developers have traditionally used static analysis tools via a simple IDE integration or as stand-alone tools. While the tools add significant value to the development effort, the proliferation of tools has created efficiency problems as developers spend more and more time using and maintaining different tools and sifting through more and more results. To wisely manage development resources, teams must be able to effectively manage, filter, and prioritize all those issues.

To address these problems, development testing platforms have emerged to unify and manage all of this static analysis information in one place, simplifying the user experience and increasing visibility and efficiency at larger scales while providing relevant access controls and reporting. Development testing platforms are even starting to blur the line between static analysis and other types of analysis by utilizing – during the static analysis process – artifacts generated during earlier program runs. For example, these platforms can use code coverage information from test runs during static analysis to effectively identify missing test cases automatically. The traditional approach to this problem requires significant manual effort based on simple coverage thresholds. By leveraging data from different sources, these platforms are able to significantly reduce the manual effort and time required to accomplish this with other methods.

Selecting static analysis tools for Java

The most popular, free, static analysis tools for Java are probably Checkstyle, PMD, and FindBugs. While they all fall under the “static analysis” umbrella, their strengths are so sufficiently different that many consider the tools to be complementary rather than alternatives.

Checkstyle

Checkstyle is billed as “a development tool to help programmers write Java code that adheres to a coding standard[1],” although it does not strictly limit itself to coding standard enforcement. It provides a documented API for users to define their own custom checks. Typical coding standards utilize basic rules to make code more readable and reduce the likelihood that future code changes will introduce bugs. Standards tend to define conventions about formatting (white space, bracketing, naming, commenting, and so on), inheritance, and visibility. When adequately enforced, well-designed coding standards can help developers reduce risk. Enforcement can be difficult, though, since coding standards generate a lot of violations and there can be significant pressure to ignore noisy rules. With legacy code, this can make enforcing new coding standards unfeasible. While most of the issues identified by Checkstyle do not affect code correctness, robustness, or performance, there is real value in helping developers quickly understand code written by others. It is not always obvious how to quantify the risk represented by these violations and it is problematic to measure risk directly from violation counts, but changes in those counts can be a reasonable proxy for changes in risk.

PMD

PMD is described as “…a source code analyzer. It finds unused variables, empty catch blocks, unnecessary object creation, and so forth[2].” It, too, is evolving and the current checks focus mainly on syntactic oddities that might belie developer mistakes, such as overcomplicated expressions, empty blocks, unused variables, parameters, and class members. It also has a popular module to identify duplicated code. Because it is generally reporting “suspicious code” as opposed to specific coding errors or standards violations, the user will need to carefully select the checks enabled for everyday use. Because enforced rules are selected by the user, this tool can be useful for both legacy and greenfield projects, and it is often easy to correlate these counts with risk. Unfortunately, it might not be obvious whether reported issues should be considered defects or maintenance concerns.

FindBugs

FindBugs is probably the most popular of these tools. It looks for actual bugs in the code, as well as suspicious code and standards violations. Because of the wide range of reported issues, it is important to use a configuration that includes the most relevant checks for the project. This is especially true for legacy projects, as it’s easier to keep new projects clean from the beginning. Like PMD, any team can benefit from using FindBugs and associating issue counts to risk can be straightforward.

Commercial static analysis tools show similar diversity, identifying everything from standards violations to actual defects and security vulnerabilities. To illustrate how a commercial tool might compare to a free tool, I analyzed version 1.496 of the Jenkins job management system (www.jenkins-ci.org) using a proprietary static analysis solution and version 2.0.1 of FindBugs, with all checks enabled. On this code base, 852 unique issues were identified – with only 28 issues identified by both products. The proprietary solution found 197 unique issues, with 188 of those coming from high-impact categories (security and concurrency bugs, resource leaks, and unhandled exceptions like null dereferences). FindBugs found 627 unique issues, with 29 coming from those high-impact categories. In short, each of the tools found significant high-impact issues missed by the others, so using a proprietary solution or FindBugs alone will leave significant risk undetected.

Development testing – Tying it all together

Static analysis tools are a powerful ally in the software development effort for Java developers, as these tools enable developers to gain insight into risk throughout the software development life cycle. They are typically easy to automate, enabling users to spend their time fixing problems rather than running the tools.

When it comes to managing risk, more information is generally better – as long as that information illuminates actual sources of risk that developers care about. When deciding which tools to adopt, remember to consider not just the types of issues that analysis tools identify, but how those tools can work together to provide additional value. Also, be sure to configure them appropriately so that the number of issues doesn’t overwhelm your users.

Modern development testing platforms take testing tools to another level by unifying the data in one place, simplifying the user experience, and creating opportunities to provide even more value.

...
refer to: http://embedded-computing.com/articles/static-helps-manage-risk-java/

All-In-One gaming board with AMD Embedded G-Series T56N APU for appliance

 A new All-in-One Gaming Board, the AMB-A55EG1. AMB-A55EG1 features AMD Embedded G-Series T56N 1.65GHz dual-core APU, two DDR3-1333 SO-DIMM, which provides great computing and graphic performance is suitable for casino gaming and amusement applications. It is designed to comply with the most gaming regulations including GLI, BMM, and Comma 6A. AMB-A55EG1 is specifically designed to be a cost competitive solution for the entry-level gaming market.

AMB-A55EG1 utilizes the functions of an X86 platform, 72-pin Gaming I/O interface, intrusion detection and also various security options, and a complete line of Application Programming Interfaces to create smoother gaming development.

Key features of AMB-A55EG1:
● AMD Embedded G-Series T56N 1.65GHz dual-core APU
● 2 DDR3 SO-DIMM slot support to max 8GB
● 1 VGA port + 1 HDMI port
● 72-pin golden finger interface
● 256KB battery back-up SRAM with battery low monitor
● 2 ccTalk ports
● 1 Gigabit Ethernet port
● 6 USB ports
● 2 SATA ports + 1 mSATA port
● 2 Intrusion Detection door switches
● Hardware security by FPGA + PIC
● 5.1 channels with 2 channel amplifier (6W x 2)

Acrosser AMB-A55EG1 is powered by AMD low power G-Series T56N dual core platform that uses an AMD Radeon HD 6320 graphic controller.  The DirectX® 11 support lets you enjoy awesome graphics performance, stunning 3D visual effects and dynamic interactivity. Discrete-level GPU with OpenGL 4.0 and OpenCL™ 1.1 support device provides the tools to build the designs of tomorrow, today.
In conclusion, AMB-A55EG1 bridges Acrosser’s innovated gaming solutions and AMD Embedded G-Series APU to bring the optimum combination of computing power, graphic performance, and gaming features. Acrosser supports all gaming products in Windows XP Pro, XP embedded and mainstream Linux operation system with complete software development kit (SDK).  In addition, Acrosser’s gaming platforms have a minimum 5-year availability to fulfill the demand of long term supply in gaming industry.

For more information on AMB-A55EG1 or any other products, please contact your local Acrosser sales channel or logon to our website: www.acrosser.com

Product information：
http://www.acrosser.com/Products/Gaming-Platform/All-in-One-Gaming-Board/AMB-A55EG1/AMD-Embedded-G-Series-AMB-A55EG1.html

Contact：
http://www.acrosser.com/inquiry.html