2018-04-11 06:14 AM
Hi All,
We at
are building virtual devices to help embedded software developers ship better code faster. Our mission is to make it fast and easy to automate testing and adopt agile and continuous integration methodologies for embedded systems by hardware virtualization. Our virtual device allows users to run the same firmware executable they run on their hardware device and with our Python SDK, we allow writing test scripts and seamless integration to CI/CD tools and testing frameworks.We've started working on support for the STM32 family that will be rolled out later this month. I'd appreciate hearing your thoughts on what matters to you and which device you'd like us to roll out first. Please take the time to answer this short survey so we'll know how to prioritize -
. Note that Jumper is free for the basic plan and that the first 100 people that will answer this survey will get 80% discount on the pro plan for the first six months.It would be great having you on board and getting your feedback!
Thanks,
Yaniv
#virtual-device #test-automation #emulation #simulation-software #continuous-integration2018-04-12 04:40 AM
If you just simulate the mcu and don't offer wide support for other devices, you would be at a significant disadvantage vs. the real hardware or other simulators - I use Proteus for example.
I think within stm, the f1 and f0 are really nice devices and have a large following. The f4s are catching up as well. F3 has a limited appeal to mixed signal users. I haven't seen a project with f2.
Hope that helps.
2018-04-12 07:49 AM
Thanks for this info! We are not only simulating the MCU but also external peripherals and also provide a modeling framework on an open source model so the community will be able to enjoy from a growing library of peripherals. On top of the virtual device, we also enable environment simulation, communication simulation and complete system tests.
Can you share your use case of using simulation? What made you start with it?
It would be great to have you on board or just evaluate us and hear your feedback!!!
2018-04-12 10:24 AM
Pretty much all of my code is simulated first. I write mostly on turbo C or keil C51 for their small size and then migrate the code to the target through a middle layer, often with a simple recompilation and the code is good to go.
I think there is a large market for such simulation, especially if you can provide a large collection of quality external parts. This will allow the users to iron out most of the bugs in a virtual environment before committing to real hardware.
However, you have to convince people to use your service. Because for every user, using your service is an investment of their time and learning, ... You have to convince people that you will provide a quality service, and you will be around in the foreseeable future for them to get a return on their investment.
It is much harder to make that a case for a commercial user than it is to a school, I. A learning environment. So maybe that's where you focus your effort at least initially.
2018-04-17 08:25 AM
Thanks for your response and totally agree with you. Looking into Proteus, I was wondering about your use case with it. It looks like a tool for pre-hardware development and local simulation and less for test automation. Can you share how do you perform test automation?
Thanks!!!
2018-04-17 07:16 PM
it can be challenging to simulate non-mechanism parts, like a lever, or a position sensor in a typical automation project.
the value of a system like proteus is for you to get your code tested virtually so you can work out the bugs quickly, before the whole thing is realized on real parts.
often times non-electric parts can be simulated using electrical components. A stove for example can be simulated with a r/c network, or with a heater element in proteus.
that's not to say that simulation is everything. But it can be a very useful tool in today's world.