1,418 Comments

1. March 25, 2019 at 1:49 pm

   Tomi Engdahl says:

   Don’t Delay() Use an Arduino Task Scheduler Today!
   https://www.hackster.io/GadgetsToGrow/don-t-delay-use-an-arduino-task-scheduler-today-215cfe

   Task scheduling is a transformative way to write maintainable code for Arduino and other AVRs. No more spaghetti code. C++ tutorial.

   As my Arduino projects became more complex I started to realize the delay() function caused unforeseen problems. While in a delay, the Arduino/AVR can’t process any other code (with a few exceptions). I came across this solution while researching another topic and I thought I would document it for my future projects. Alan Burlison created an eloquent Task Scheduler library that solves the delay issues —but more importantly, it made me rethink how I design my Arduino/AVR projects.

   A very simple Arduino task manager
   http://bleaklow.com/2010/07/20/a_very_simple_arduino_task_manager.html

   The LED chain project I’m working on requires that the AVR microcontroller handles several different tasks:

   Read a rotary encoder and switch
   Drive a seven-segment display
   Drive a radio
   Drive four LED strips each containing twenty LEDs
   Provide logic to tie all the above together

   Normally that sort of multiple-task workload might suggest the use of a RTOS, but the Arduino Pro Mini has only 32Kb of program memory (of which 2Kb is used by the bootloader) and 2Kb of RAM, so every byte is precious. So, whatever we come up with has to be as minimal as possible. OK, let’s see if we can make some assumptions and trade-offs that will help keep things simple and create a small set of C++ classes we can use to implement the task management

   Reply
2. March 29, 2019 at 12:32 pm

   Tomi Engdahl says:

   Top 10 Tips When Designing with Embedded Flash
   https://www.eeweb.com/profile/mehnerta/articles/top-10-tips-when-designing-with-embedded-flash

   These top 10 tips outline the things that engineers need to consider when specifying embedded flash to help make the process simpler

   #10: FOB vs. steady-state performance
   #9: Seeking consistent performance
   #8: Overprovisioning
   #7: Managing static data with RDM and DDR
   #6: Ensuring health
   #5: Improved mapping with hyMap
   #4: Invisible caching trade-offs
   #3: Trading capacity for performance and reliability
   #2: Data in power-failure events
   #1: Defining requirements

   Conclusion
   There is a variety of storage systems and controllers available in terms of interface options and quality levels. If the storage system is vital for your application or holds sensitive data, or if failure would result in costly down-time, you need to choose your controller carefully, so make sure that you fully understand your requirements.

   Reply
3. April 2, 2019 at 12:21 pm

   Tomi Engdahl says:

   Heterogeneous Design Creating Havoc With Firmware Versions
   https://semiengineering.com/heterogeneous-design-creating-havoc-with-firmware-versions/

   Updates, last-minute changes to design add a whole new set of challenges at sign-off.

   Reply
4. April 4, 2019 at 11:02 am

   Tomi Engdahl says:

   Big Shift In Multi-Core Design
   https://semiengineering.com/big-shift-in-multi-core-design/

   System-wide concerns in AI and automotive are forcing hardware and software teams to work together, but gaps still remain.

   Reply
5. April 4, 2019 at 12:23 pm

   Tomi Engdahl says:

   Most Embedded System Failures Can Be Prevented
   Simple steps early in the design process can pay dividends down the road, expert says.
   https://www.designnews.com/electronics-test/most-embedded-system-failures-can-be-prevented/95222925460534?ADTRK=UBM&elq_mid=8083&elq_cid=876648

   Early awareness of problems is the key to circumventing failures of embedded electronics, an expert will tell attendees at the upcoming Embedded Systems Conference in Boston.

   The Three Biggest Culprits

   The most insidious failure mechanism – the one that often blindsides developers – is heat, Hillman said. Unfortunately, thermal issues are typically addressed too late.

   He recommends that developers do “back-of-the-envelope” calculations as early in the design as possible, even before doing simulations or computational fluid dynamics (CFD) studies. “

   In terms of raw numbers, however, the biggest problem may be connectors, Hillman will tell attendees. “When we talk to customers, we hear that connectors are the most common cause of embedded systems failures,” Hillman told us.

   it can be a difficult failure to prevent, since connectors may be specified early and designers may have little choice in the matter. Still, he said, designers should consider such issues as positive retention, strain relief, alignment of pins, and separation of power and ground.

   Finally, he said, embedded designers must weigh the effects of developing their own systems versus buying them from vendors. The majority of engineers do a mixture of both, he said. And if that’s the case, they must be prepared, not only to choose the best vendor, but to clearly define that vendor’s role.

   “You have to decide early on what you need from the vendor,”

   Reply
6. April 5, 2019 at 1:22 pm

   Tomi Engdahl says:

   3 Reasons UX/UI Is Important for Hardware Products
   https://www.designnews.com/design-hardware-software/3-reasons-uxui-important-hardware-products/113312185860558?ADTRK=UBM&elq_mid=8093&elq_cid=876648

   As engineers, we must embrace the idea that a well-designed user experience and user interface can be the key to the success or failure of a hardware product.

   While we often think about user experience (UX) and user interface (UI) in the context of software, let’s not forget how crucial UX/UI can be in the development of hardware products. Sometimes UX/UI is the only or main differentiator in a company’s products and can be the key to the success or failure of a product.

   As engineers, particularly those involved in projects invoking Department of Defense (DoD) specifications, UI in the hardware world is often perceived as meeting human interface specifications. And while this certainly is part of the UI story, the total story of UX and UI is much greater than meeting government specification, which are driven by the need for operational efficiency.

   The full UX/UI portfolio is not just functional, but a tie into the emotional attachment to a product.

   Here are some reasons why UX/UI considerations are important when developing hardware products:

   1.) Well-Designed Products Work Better
   2.) Great Design Makes Users Feel Good About Using the Products
   3.) Good Design Builds Brand Loyalty

   Reply
7. April 5, 2019 at 6:39 pm

   Tomi Engdahl says:

   Technical Documentation in Software Development: Types, Best Practices, and Tools
   https://www.altexsoft.com/blog/business/technical-documentation-in-software-development-types-best-practices-and-tools/

   Technical documentation in software engineering is the umbrella term that encompasses all written documents and materials dealing with software product development. All software development products, whether created by a small team or a large corporation, require some related documentation. And different types of documents are created through the whole software development lifecycle (SDLC).

   Reply
8. April 18, 2019 at 10:07 am

   Tomi Engdahl says:

   Beware the Hidden Costs of a Free Embedded RTOS
   https://www.designnews.com/electronics-test/beware-hidden-costs-free-embedded-rtos/82887530360616?ADTRK=UBM&elq_mid=8208&elq_cid=876648

   If you’re basing your selection of a real-time operating system (RTOS) solely on initial cost, then you may be in for a rude awakening.

   Engineers who select an embedded RTOS simply because its free can end up spending more money in the long run, contends Jacob Beningo, an embedded software consultant at the Beningo Embedded Group. Moreover, they can fail certifications and end up having security issues.

   “You have to stop looking at cost as the only data point, and really evaluate all the features and the ecosystem,” Beningo said. “When you’re selecting your RTOS, you need to do your engineering due-diligence to make sure you select something that meets all your needs.”

   Reply
9. April 18, 2019 at 1:02 pm

   Tomi Engdahl says:

   In a video, Mentor’s Colin Walls digs into power management in embedded software with a particular look at the Power Pyramid model.

   Video about embedded power management
   https://www.mentor.com/embedded-software/blog/post/video-about-embedded-power-management-6481fc88-bc9a-4441-bab6-fbb5b20b97d8?cmpid=10168

   Reply
10. April 18, 2019 at 1:06 pm

    Tomi Engdahl says:

    Target: 50% Reduction In Memory Power
    https://semiengineering.com/target-50-reduction-in-memory-power/

    Is it possible to reduce the power consumed by memory by 50%? Yes, but it requires work in the memory and at the architecture level.

    Reply
11. April 18, 2019 at 1:07 pm

    Tomi Engdahl says:

    Optimization Challenges For Safety And Security
    https://semiengineering.com/optimization-challenges-for-safety-and-security/

    The road to optimized tradeoff automation is long. Changing attributes along the way can make it even more difficult.

    Reply
12. April 18, 2019 at 1:12 pm

    Tomi Engdahl says:

    Finding Code Problems Before High-Level Synthesis
    https://semiengineering.com/finding-code-problems-before-high-level-synthesis/

    Making sure C++ models are correct before simulation.

    Reply
13. April 18, 2019 at 1:26 pm

    Tomi Engdahl says:

    New Approaches To Security
    https://semiengineering.com/new-approaches-to-security/

    Data analytics, traffic patterns and restrictive policies emerge as ways to ensure that systems are secure.

    Reply
14. April 18, 2019 at 1:28 pm

    Tomi Engdahl says:

    Mullistava tekniikka pakkaa koodin tiheämpään
    http://etn.fi/index.php?option=com_content&view=article&id=9381&via=n&datum=2019-04-18_13:54:55&mottagare=30929

    Periaate toimii Javan lisäksi kaikilla muillakin objektiorientoituneilla kielillä, kuten Pythonilla tai Go-kielellä. Lisätehoa saataisiin käyttöön kaikilla ohjelmia ajavilla koneilla, eikä ohjelmista tarvitsisi muuttaa koodiriviäkään.

    Reply
15. April 19, 2019 at 8:18 pm

    Tomi Engdahl says:

    How the Boeing 737 Max Disaster Looks to a Software Developer
    https://spectrum.ieee.org/aerospace/aviation/how-the-boeing-737-max-disaster-looks-to-a-software-developer

    The Boeing 737 Max has been in the news because of two crashes, practically back to back and involving brand new airplanes. In an industry that relies more than anything on the appearance of total control, total safety, these two crashes pose as close to an existential risk as you can get.

    Apparently the 737 Max pitched up a bit too much for comfort on power application as well as at already-high angles of attack. It violated that most ancient of aviation canons and probably violated the certification criteria of the U.S. Federal Aviation Administration. But instead of going back to the drawing board and getting the airframe hardware right (more on that below), Boeing relied on something called the “Maneuvering Characteristics Augmentation System,” or MCAS.

    Boeing’s solution to its hardware problem was software.

    “Cheap way to prevent a stall when the pilots punch it,” or CWTPASWTPPI, system. Hmm. Perhaps MCAS is better, after all.

    MCAS is certainly much less expensive than extensively modifying the airframe to accommodate the larger engines.

    the major selling point of the 737 Max is that it is just a 737, and any pilot who has flown other 737s can fly a 737 Max without expensive training, without recertification, without another type of rating.

    It all comes down to money, and in this case, MCAS was the way for both Boeing and its customers to keep the money flowing in the right direction.

    That’s probably also the reason why the documentation about the MCAS system was kept on the down-low.

    Angle-of-attack sensors look like wind vanes because that’s exactly what they are.

    Long ago there was a joke that in the future planes would fly themselves

    On the 737, Boeing not only included the requisite redundancy in instrumentation and sensors, it also included redundant flight computers—one on the pilot’s side, the other on the copilot’s side.

    their main job is to fly the plane when commanded to do so and to make sure the human pilots don’t do anything wrong when they’re flying it. The latter is called “envelope protection.”

    When MCAS senses that the angle of attack is too high, it commands the aircraft’s trim system

    In the 737 Max, like most modern airliners and most modern cars, everything is monitored by computer, if not directly controlled by computer. In many cases, there are no actual mechanical connections (cables, push tubes, hydraulic lines) between the pilot’s controls and the things on the wings, rudder, and so forth that actually make the plane move.

    With computer oversight there is a loss of natural sense in the controls. In the 737 Max, there is no real “natural feel.”

    Indeed, not letting the pilot regain control by pulling back on the column was an explicit design decision.

    MCAS is implemented in the flight management computer, even at times when the autopilot is turned off, when the pilots think they are flying the plane.

    The flight management computer is a computer.

    It’s full of lines of code. And that’s where things get dangerous.

    Those lines of code were no doubt created by people at the direction of managers. Neither such coders nor their managers are as in touch with the particular culture and mores of the aviation world

    In the 737 Max, only one of the flight management computers is active at a time—either the pilot’s computer or the copilot’s computer. And the active computer takes inputs only from the sensors on its own side of the aircraft.

    In the Boeing system, the flight
 management computer does not “look 
across” at the other instruments. It 
believes only the instruments on its side. It doesn’t go old-school. It’s modern. It’s software.

    This means is that if a particular angle-of-attack sensor goes haywire—which happens all the time in a machine that alternates from one extreme environment to another, vibrating and shaking all the way—the flight management computer just believes it.

    It gets even worse. There are several other instruments that can be used to determine things like angle of attack, either directly or indirectly, such as the pitot tubes, the artificial horizons, etc. All of these things would be cross-checked by a human pilot to quickly diagnose a faulty angle-of-attack sensor.

    Like someone with narcissistic personality disorder, MCAS gaslights the pilots. And it turns out badly for everyone. “Raise the nose, HAL.” “I’m sorry, Dave, I’m afraid I can’t do that.”

    In the MCAS system, the flight management computer is blind to any other evidence that it is wrong, including what the pilot sees with his own eyes and what he does when he desperately tries to pull back on the robotic control columns that are biting him, and his passengers, to death.

    In the old days, the FAA had armies of aviation engineers in its employ.

    As airplanes became more complex and the gulf between what the FAA could pay and what an aircraft manufacturer could pay grew larger, more and more of those engineers migrated from the public to the private sector. Soon the FAA had no in-house ability to determine if a particular airplane’s design and manufacture were safe. So the FAA said to the airplane manufacturers, “Why don’t you just have your people tell us if your designs are safe?”

    The airplane manufacturers said, “Sounds good to us.”

    Thus was born the concept of the “Designated Engineering Representative,” or DER. DERs are people in the employ of the airplane manufacturers, the engine manufacturers, and the software developers who certify to the FAA that it’s all good.

    It is astounding that no one who wrote the MCAS software for the 737 Max seems even to have raised the possibility of using multiple inputs

    But I do know that it’s indicative of a much deeper problem. The people who wrote the code for the original MCAS system were obviously terribly far out of their league and did not know it. How can they can implement a software fix, much less give us any comfort that the rest of the flight management software is reliable?

    So Boeing produced a dynamically unstable airframe, the 737 Max. That is big strike No. 1. Boeing then tried to mask the 737’s dynamic instability with a software system. Big strike No. 2. Finally, the software relied on systems known for their propensity to fail (angle-of-attack indicators) and did not appear to include even rudimentary provisions to cross-check the outputs of the angle-of-attack sensor against other sensors, or even the other angle-of-attack sensor. Big strike No. 3.

    None of the above should have passed muster. None of the above should have passed the “OK” pencil of the most junior engineering staff, much less a DER.

    That’s not a big strike. That’s a political, social, economic, and technical sin.

    it seems that with the 737 Max, Boeing has changed philosophies about human/machine interaction as quietly as they’ve changed their aircraft operating manuals.

    The 737 Max saga teaches us not only about the limits of technology and the risks of complexity, it teaches us about our real priorities. Today, safety doesn’t come first—money comes first, and safety’s only utility in that regard is in helping to keep the money coming. The problem is getting worse because our devices are increasingly dominated by something that’s all too easy to manipulate: software.

    Hardware defects, whether they are engines placed in the wrong place on a plane or O-rings that turn brittle when cold, are notoriously hard to fix. And by hard, I mean expensive. Software defects, on the other hand, are easy and cheap to fix. All you need to do is post an update and push out a patch. What’s more, we’ve trained consumers to consider this normal

    I believe the relative ease—not to mention the lack of tangible cost—of software updates has created a cultural laziness within the software engineering community. Moreover, because more and more of the hardware that we create is monitored and controlled by software, that cultural laziness is now creeping into hardware engineering—like building airliners.

    Boeing is in the process of rolling out a set of software updates to the 737 Max flight control system, including MCAS.

    Nowhere is this problem more acutely felt than in systems designed to augment or improve safety. Every increment, every increase in complexity, ultimately leads to decreasing rates of return and, finally, to negative returns. Trying to patch and then repatch such a system in an attempt to make it safer can end up making it less safe.

    This is the root of the old engineering axiom “Keep it simple, stupid” (KISS) and its aviation-specific counterpart: “Simplify, then add lightness.”

    Now software stands between man and machine, and no one seems to know exactly what is going on. Things have become too complex to understand.

    In the 737 Max case, the rules were also followed. The rules said you couldn’t have a large pitch-up on power change and that an employee of the manufacturer, a DER, could sign off on whatever you came up with to prevent a pitch change on power change. The rules didn’t say that the DER couldn’t take the business considerations into the decision-making process. And 346 people are dead.

    Reply
16. April 30, 2019 at 12:07 pm

    Tomi Engdahl says:

    Sovellusinsinöörin rooli pienenee
    http://www.etn.fi/index.php/13-news/9414-sovellusinsinoorin-rooli-pienenee

    Nykysuunnittelija on tottunut hakemaan tietoa netin kautta ja ostamaan tarvitsemansa komponentit verkkokaupasta. On selvää, että perinteisen sovellusinsinöörin tai FAE-insinöörin rooli pienenee koko ajan, sanovat myyntiään nopeasti kasvattaneen Mouser Electronicsin Euroopan nokkamiehet Mark Burr-Lonnon (vas.) ja markkinointijohtaja Graham Maggs.

    Reply
17. April 30, 2019 at 12:55 pm

    Tomi Engdahl says:

    The Case For Embedded FPGAs Strengthens And Widens
    https://semiengineering.com/embedded-fpga-becomes-a-viable-option/

    Combining the flexibility of a FPGA with the performance and cost benefits of an SoC is pushing this technology well into the mainstream.

    Reply
18. April 30, 2019 at 12:56 pm

    Tomi Engdahl says:

    Leverage object-oriented industrial programming
    https://www.controleng.com/articles/leverage-object-oriented-industrial-programming/

    Plants and equipment are assembled from objects, so controls architecture should be too. New tools help industrial programmers deliver the productivity of object-oriented programming (OOP) without the complexity.

    New object-oriented industrial programming (OOIP) techniques deliver the productivity gains of object-oriented programming (OOP) while maintaining the ease-of-use and reliability required for industrial controls applications.

    OOP for industrial controls

    The industrial controls and computer science communities tend to differ on OOP interpretation. To understand OOIP, it’s important to note its key differences with OOP.

    OOP:

    Includes the full suite of computer science OOP features
    Is primarily text-based
    Is typically the domain of highly educated computer scientists.

    OOIP:

    Has the ability to instantiate function blocks (FB) into other FBs using the concepts of encapsulation, instantiation, and abstraction
    Is primarily graphics-based
    Is usable by controls engineers and plant technicians with minimal training.

    Reply
19. April 30, 2019 at 12:56 pm

    Tomi Engdahl says:

    Rushing To The Edge
    https://semiengineering.com/rushing-to-the-edge/

    Why the next big thing is unnerving tech giants and pushing design in new directions.

    Reply
20. May 2, 2019 at 10:40 am

    Tomi Engdahl says:

    Tips and Tricks for Successful IoT Software Development
    https://www.electronicdesign.com/iot/tips-and-tricks-successful-iot-software-development?NL=ED-005&Issue=ED-005_20190501_ED-005_463&sfvc4enews=42&cl=article_1_b&utm_rid=CPG05000002750211&utm_campaign=25234&utm_medium=email&elq2=2f6494670b8e40d89a4cc27c5bb6ea50

    Ideally, you need an approach that results in software that drives IoT solutions for the future, while keeping the users’ evolving needs in mind and delivering on the promise and benefits of connectivity.

    How is this accomplished?

    Test Often, Gather Feedback, Iterate

    Testing and gathering critical feedback is what makes product development a success. You want to get a version of the software into as many users’ hands as soon as possible and be prepared to address their feedback.

    An iterative, cross-platform software collaboration, born out of the agile methodology, is more advantageous due to its flexibility and direct connection to the end user. An iterative approach is micro-goal driven, with an easy process in place to adjust to changing requirements. This improves your team’s ability to accurately and efficiently manage costs, and it provides the quickest route to market.

    Unlike waterfall, where there is a sequential, straight-line process, agile addresses every component in the stack in a series of continuous, quick-moving sprints that deliver an improved, market-ready product faster. The project moves in manageable pieces. There are no surprises lurking at the end of the process.

    Communication is vital to the collaborative and iterative agile approach. Developers should be in ongoing contact with the customer through daily scrums, biweekly planning meetings and biweekly reviews.

    Reply
21. May 2, 2019 at 11:47 am

    Tomi Engdahl says:

    Safety-Critical Coverage
    https://semiengineering.com/safety-critical-coverage/

    Verification in automotive, medical and industrial designs.

    Reply
22. May 2, 2019 at 11:48 am

    Tomi Engdahl says:

    Redefining Expectations for Test
    https://semiengineering.com/redefining-expectations-for-test-2/

    How to tackle testing automotive and AI systems

    Reply
23. May 2, 2019 at 12:06 pm

    Tomi Engdahl says:

    Leverage object-oriented industrial programming
    https://www.controleng.com/articles/leverage-object-oriented-industrial-programming/

    Plants and equipment are assembled from objects, so controls architecture should be too. New tools help industrial programmers deliver the productivity of object-oriented programming (OOP) without the complexity.

    Reply
24. May 3, 2019 at 12:10 pm

    Tomi Engdahl says:

    5 Lessons to Learn from the Boeing 737 MAX Fiasco
    https://www.designnews.com/electronics-test/5-lessons-learn-boeing-737-max-fiasco/132367532460732?ADTRK=UBM&elq_mid=8499&elq_cid=876648

    Although it will be months before we have full reports about the 737 MAX crashes, we don’t have to wait to draw lessons from those incidents.

    Lesson #1 – Don’t compromise your product to save or make money short-term

    Lesson #2 – Identify and mitigate single points of failure

    Lesson #3 – Don’t assume your user can handle it

    Lesson #4 – Highly tested and certified systems have defects

    Lesson #5 – Sensors and systems fail

    Reply
25. May 5, 2019 at 7:14 am

    Tomi Engdahl says:

    Traditional development methods do not scale into the IoT sphere. Strong inter-dependencies and blurred boundaries among components in the edge device stack result in fragmentation, slow updates, security issues, increased cost, and reduced reliability of platforms.

    Source: https://www.brighttalk.com/webcast/6793/355702?utm_source=facebook_ad&utm_medium=social&utm_campaign=CY19_IOT_Ubuntu+Core_WBN_DevOpsJourney

    Reply
26. May 5, 2019 at 7:19 am

    Tomi Engdahl says:

    What is a developer journal?
    https://opensource.com/article/19/4/what-developer-journal?sc_cid=7016000000127ECAAY

    Solve your future problems faster by logging the most useful things you’ve already learned.

    Reply
27. May 5, 2019 at 7:31 am

    Tomi Engdahl says:

    SOFTWARE DEVELOPMENT OF TOMORROW COMES WITH ETHICAL CHALLENGES
    https://blog.taiste.fi/en/software-development-of-tomorrow-comes-with-ethical-challenges?utm_source=facebook&utm_medium=promotedpost&utm_campaign=website&utm_content=ethicalchallenges

    As technology grows more and more powerful, tech companies need to prepare for sometimes unexpected ethical issues.

    Here are four things to consider when seeking to build ethically sound digital services.

    1. RESPONSIBILITY ISSUES MUST BE MADE VISIBLE

    2. TRANSPARENCY CAN BE INCREASED VIA PUBLIC STATEMENTS AND EXTERNAL CERTIFICATES

    3. POWER IS ALWAYS AN IMPORTANT ISSUE AND MUST BE USED RESPONSIBLY

    4. KEEPING THE LINE BETWEEN HUMAN AND DIGITAL TRANSPARENT IS TRICKY

    WHAT ARE THE BUILDING BLOCKS OF THE CURRENT ETHICS DISCUSSION IN TECH?
    By following the discussion around the topics above, it seems that the current ethical principles are drawn from the following sources: human rights, laws and regulations such as GDPR – and last but not least, the social responsibility of individual companies.

    Besides the official regulations, we need to start building an environment of trust when it comes to technology. This could even be seen as an expansion of the ethics courses currently offered by our public schools.

    Reply
28. May 27, 2019 at 8:45 am

    Tomi Engdahl says:

    Revolutionize Your Design and Test Workflow

    In the 1990s, agile software development profoundly transformed software development. Agile is far more than a process; it’s a new way to work. Today, a similar transformation is happening in test and measurement: TestOps. Learn about TestOps and how to accelerate your product development workflow.

    https://connectlp.keysight.com/EU_PathWave-Test?cmpid=70741

    Reply
29. May 27, 2019 at 1:20 pm

    Tomi Engdahl says:

    JEDEC’s Soft Reset Offers Significant Benefits to Embedded Developers
    https://www.eeweb.com/profile/paul-hill/articles/jedecs-soft-reset-offers-significant-benefits-to-embedded-developers

    The industry standards body JEDEC has defined a serial reset protocol that avoids the need for a dedicated reset pin.

    Reply
30. May 28, 2019 at 9:44 am

    Tomi Engdahl says:

    GitHub Adds New Tools to Help Developers Secure Code
    https://www.securityweek.com/github-adds-new-tools-help-developers-secure-code

    Microsoft-owned GitHub on Thursday announced the introduction of several new security tools and features designed to help developers secure their code.

    The code hosting service in 2017 launched a new security feature designed to warn developers if the software libraries used by their projects contain any known vulnerabilities. Since the introduction of the security alerts has resulted in significantly fewer vulnerable code libraries on the platform, GitHub has continued to make improvements and it has now announced even more enhancements as a result of a partnership with WhiteSource.

    The partnership helps GitHub broaden coverage of security flaws in open source projects and allows it to provide even more details that should help developers assess and address vulnerabilities.

    Another new tool is Dependency Insights, which helps enterprises gain full visibility into their dependencies — including vulnerabilities and licenses — and better understand their exposure.

    Reply
31. May 28, 2019 at 10:56 am

    Tomi Engdahl says:

    TestOps: How to automate your software pipeline at the speed of DevOps
    https://www.opcito.com/blogs/testops-how-to-automate-your-software-pipeline-at-the-speed-of-devops

    TestOps is a combination of Test and Operations (Ops) which is a more evolved version of traditional testing to assure the quality of services. Testing is done on one side, and once complete, the testers effectively throw the delivery over the fence to the operations team who deploy it into production.

    Now, as an alternative to this approach testers need to focus on the live production site to upgrade the quality and have faster results.

    TestOps has innovated the way to carry out testing, combining both the Development Team and Testing Team to have the same role as that of ops. They contribute to speed up the process and support boost the reliability and quality of the product.

    TestOps: What Does This Mean
    Traditionally, devs and testers worked in a clean almost-no-overlap environment. Developers have always been limited to conduct unit testing but, now they are made to build bug-free code and run functional test cases. This made it easier for the testers to focus more on production and high context scenario. Testers now focus on collecting and identifying the right data. They need to set up tools to run the tests in production, check the data, and analyze it.

    TestOps in Product Engineering
    https://www.sogeti.com/solutions/high-tech–global-engineering/products-and-engineering-services/testops/

    Reply
32. May 31, 2019 at 7:53 am

    Tomi Engdahl says:

    The rapidly increasing complexity of today’s designs, combined with schedule pressure to deliver innovative products to market as quickly as possible, strains engineering resources to the limit, often to the point of breaking. As a result, 17% of all projects get canceled, and another 28% miss their target release date.

    Integrated Verification: A Shift-Left Solution for a More Efficient Design Flow
    https://www.mentor.com/pcb/resources/overview/integrated-verification-a-shift-left-solution-for-a-more-efficient-design-flow-4b0ef026-5ade-4525-82ce-21a1c1fa0d3d?uuid=4b0ef026-5ade-4525-82ce-21a1c1fa0d3d&clp=1&contactid=1&PC=L&c=2019_05_29_ebs_xp_sl_integrated_verificat

    Reply
33. May 31, 2019 at 8:29 am

    Tomi Engdahl says:

    How the C/C++ <> Shift Operators Work
    By Max Maxfield | Friday, May 24, 2019
    https://www.eeweb.com/profile/max-maxfield/articles/how-the-c-c-shift-operators-work

    The ways in which the shift operators perform their magic may seem a little daunting when you are first exposed to them, but things are not as bad as they seem.

    Many beginners are confused about the way in which the <> (shift right) operators work in programming languages like C/C++. In this column, all (well, quite a lot) will be revealed, but before we plunge head first into the fray with gusto and abandon, we first need to make sure that we all understand some basic concepts.

    Reply
34. September 8, 2019 at 8:07 pm

    Tomi Engdahl says:

    “The dramatic increase in computing power found in microcontrollers means that embedded versions of Python, such as CircuitPython and MicroPython, are becoming increasingly popular among makers.”

    Reply
35. September 12, 2019 at 5:21 am

    Tomi Engdahl says:

    A high-speed network driver written in C, Rust, Go, C#, Java, OCaml, Haskell, Swift, Javascript, and Python.

    Ixy is an educational user space network driver for the Intel ixgbe family of 10 Gbit/s NICs (82599ES aka X520, X540, X550, X552, …). Its goal is to show that writing a super-fast network driver can be surprisingly simple.

    https://github.com/ixy-languages/ixy-languages

    Reply
36. September 13, 2019 at 3:08 pm

    Tomi Engdahl says:

    Trusting the tools: An agile approach to tool qualification for DO-178C
    http://mil-embedded.com/articles/trusting-tools-agile-approach-tool-qualification-do-178c/

    Reply
37. September 14, 2019 at 9:43 am

    Tomi Engdahl says:

    Memory Management Approach for Swapless Embedded Systems
    https://www.linuxjournal.com/article/8502

    Reply
38. September 15, 2019 at 3:14 pm

    Tomi Engdahl says:

    Start tinkering with the Circuit Playground Express
    Learn what you can do with these tiny gadgets and a bit of Python code.
    https://opensource.com/article/19/7/circuit-playground-express

    Reply
39. September 22, 2019 at 6:55 am

    Tomi Engdahl says:

    Async.h – asynchronous, stackless subroutines in C
    https://higherlogics.blogspot.com/2019/09/asynch-asynchronous-stackless.html?m=1

    The async/await idiom is becoming increasingly popular. The first widely used language to include it was C#, and it has now spread into JavaScript and Rust. Now C/C++ programmers don’t have to feel left out, because async.h is a header-only library that brings async/await to C!

    (Discussion on HN – http://bit.ly/30jr4S1)

    Reply
40. September 29, 2019 at 1:38 pm

    Tomi Engdahl says:

    https://hackaday.com/2019/09/24/asynchronous-routines-for-c/

    Reply
41. September 29, 2019 at 1:39 pm

    Tomi Engdahl says:

    https://hackaday.com/2019/09/24/who-could-possibly-need-an-fpga-with-9m-logic-cells-and-35b-transistors/

    Reply
42. September 29, 2019 at 1:52 pm

    Tomi Engdahl says:

    https://hackaday.com/2019/09/17/linux-fu-shell-scripts-in-c-c-and-others/

    Reply
43. September 29, 2019 at 1:54 pm

    Tomi Engdahl says:

    https://hackaday.com/2019/09/13/peek-into-the-compilers-code-lots-of-compilers/

    Reply
44. September 29, 2019 at 1:55 pm

    Tomi Engdahl says:

    https://hackaday.com/2019/09/12/frequency-counting-a-different-way/

    Reply
45. September 29, 2019 at 2:04 pm

    Tomi Engdahl says:

    Everything You Wanted To Know About Padauk MCUs And More
    https://hackaday.com/2019/09/09/everything-you-wanted-to-know-about-padauk-mcus-and-more/

    At this point you’d need to have lived underneath a rock somewhere on the dark side of the Moon to not have heard about these amazing, 3-cent microcontrollers. A number of places have pitched in on them, but comprehensive reviews, let alone a full-blown review of the entire ecosystem surrounding these Padauk MCUs have been scarce. Fortunately, [Jay Carlson] has put in a lot of effort to collect everything you could possibly want to know about anything Padauk.

    The most important take-away is that these MCUs do not have any kind of communication peripherals. UARTs, I2C, and SPI all have to be done in software. They’re not very great at low-power or battery-powered applications due to high power usage.

    https://jaycarlson.net/2019/09/06/whats-up-with-these-3-cent-microcontrollers/

    Reply
46. September 29, 2019 at 2:08 pm

    Tomi Engdahl says:

    Watt-A-Live INA209 Power Monitor Shield Wing
    https://hackaday.io/project/166326-watt-a-live-ina209-power-monitor-shield-wing

    A 6.4A-20nA current/voltage/power monitor based on the TI INA209 with dedicated GND usable as Shield, Wing, Breakout or Breadboard

    The Watt-A-Live is a versatile embedded power monitor based on the Texas Instruments INA209 with full connectivity to the unit under test. It measures the load current through a shunt resistor and has separate GND connections to the power supply and the load to make it a true power monitor.
    It is designed as an Adafruit Feather Wing and Arduino Shield.

    Reply
47. September 29, 2019 at 2:12 pm

    Tomi Engdahl says:

    The Augmented Reality Breadboard Of The Future
    https://hackaday.com/2019/05/27/the-augmented-reality-breadboard-of-the-future/

    There’s little danger that the breadboard will loose its relevance going forward, but if [Andrea Bianchi] and her team have anything to say about it, it might learn some impressive new tricks. Developed at the Korean Advanced Institute of Science and Technology, VirtualComponent uses augmented reality and some very clever electronics to transform the classic breadboard into a powerful mixed-reality tool for testing and simulating circuits. It’s not going to replace the $3 breadboard you’ve got hiding at the bottom of your tool bag, but one day it might be standard equipment in electronics classrooms.

    https://github.com/makinteract/VirtualComponent

    Reply
48. September 29, 2019 at 2:15 pm

    Tomi Engdahl says:

    SerialPlot Does Exactly What You Think It Does
    https://hackaday.com/2019/05/30/serialplot-does-exactly-what-you-think-it-does/

    The serial port remains a hacker staple, being one of the easiest ways to move a little bit of data from one machine to another. All manner of projects use the interface, and often, sensors are connected and their data read over such connections. In these cases, it can be useful to plot said data, and SerialPlot is a tool that can do just that.

    SerialPlot is capable of reading data over several serial ports at once, and plotting it for your viewing pleasure. It’s capable of interpreting data in a variety of integer and float formats, and plotting multiple channels in a synchronised manner.

    https://bitbucket.org/hyOzd/serialplot/src/default/

    Reply
49. September 29, 2019 at 2:15 pm

    Tomi Engdahl says:

    Visualizing How Signals Travel In A PCB
    https://hackaday.com/2019/05/29/visualizing-how-signals-travel-in-a-pcb/

    Reply
50. September 29, 2019 at 2:16 pm

    Tomi Engdahl says:

    Drag And Drop Files On Select Arduino Boards
    https://hackaday.com/2019/05/29/drag-and-drop-files-on-select-arduino-boards/

    Historically, getting files on to a microcontroller device was a fraught process. You might have found yourself placing image data manually into arrays in code, or perhaps repeatedly swapping SD cards in and out. For select Arduino boards, that’s no longer a problem – thanks to the new TinyUSB library from Adafruit

    https://www.youtube.com/watch?v=0bWba0PU4-g

    Reply