Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Emulator for app developers #22

Closed
enurseitov opened this issue Aug 17, 2020 · 11 comments
Closed

Emulator for app developers #22

enurseitov opened this issue Aug 17, 2020 · 11 comments
Labels
Backlog Feature Request New feature or user-story you wanna add to flipper

Comments

@enurseitov
Copy link

enurseitov commented Aug 17, 2020

Back in time, there was pebble watch. They had amazing toolset for developers who wanted to create apps or watchfaces for the pebble watch (besides traditional offline SDK):

  • IDE running in browser, exposing you their SDK, with examples and docs
  • live emulator, right in the browser!
  • you could also debug your apps live on the watch: your code was compiled (probably somewhere on the backend), then sent to the pebble app on the phone, which in turn was transferring the app to the watch. And even in reverse: you was able to see debug logs from your watch in the bowser!
  • publish your apps in their app store

Frankly this was the most user-friendly environment for an embedded device I've ever seen.
Maybe it explains why pebble was so popular: there were tons of apps in their app store, entirely driven by community.

Unfortunately, pebble does not exist anymore, however there seem to be sources survived which could give some inspiration. Some facts:

  • they used stm32 MCU
  • they used customized FreeRTOS (not open-source), but there's a open-source re-implementation
  • had quite low-res screen
  • seems like they were using qemu for emulation
@enurseitov enurseitov added the Feature Request New feature or user-story you wanna add to flipper label Aug 17, 2020
@yiiii777
Copy link
Contributor

I personally dislikes any apps in web, why you need any qemu emulation on backend, when you can just compile it offline on your machine, but instead real hardware, link it with emulator, written with SDL? It simple, fast, and not required "brave web world".

@glitchcore
Copy link
Contributor

compile it offline on your machine, but instead real hardware, link it with emulator, written with SDL

this is very good solution for doing some integration tests because you can mock any hardware behaviour and frees you from proceedings with the features of the emulation itself

not required "brave web world".

web page is a simplest UI I can imagine.

We have some experience with building fw for linux and forwarding all UI commands (display transactions, LED state and button events) to/from simple web page.

@neshkeev
Copy link
Contributor

neshkeev commented Aug 27, 2020

I'm thinking about some sort of IDE + QEMU based emulator so it provides developers with the same UX as Android Studio does. We can build everything on top of Intellij IDEA, WDYT? Is it overkill?

@glitchcore
Copy link
Contributor

I think using QEMU is more difficult than create mocked HAL. Also if we have version of FW that don't require any hardware, we can complie it for WebAssembly target and run in web browser, or build it for docker-container-linux and run (how target_lo already does).

Also I think we have two different task:

  1. Create IDE in browser (it is interesting but have not major priority)
  2. Emulate firmware somewhere. On now we can build linux version and run some tests, but terminal version not allow create, for example, display and show any custom UI. Web page is more convinient for this purpose.

@glitchcore
Copy link
Contributor

I'm thinking about some sort of IDE + QEMU based emulator so it provides developers with the same UX as Android Studio does. We can build everything on top of Intellij IDEA, WDYT? Is it overkill?

And what about UI in your case? Maybe I need to see some examples how It may looks like.

@neshkeev
Copy link
Contributor

I think using QEMU is more difficult than create mocked HAL.

You might be right, if we aim to build an MVP quickly then a mocked HAL is reasonable way to go, but for a more mature solution QEMU is a good choice since it provides infrastructure for debugging, network interfaces and other hardware. It also encapsulates the emulated hardware, so, in theory, if there is a new Flipper device's architecture, then we can quickly pick it up since only a new frontend for QEMU is required. I haven't coded any custom frontend for QEMU yet, so this idea is worth exploring first.

Also if we have version of FW that don't require any hardware, we can complie it for WebAssembly target and run in web browser

About a year ago I heard that you cannot place a wasm file on a CDN (content delivery network), correct me if I am wrong.

Create IDE in browser

  1. I have an experience working on code from a web browser (cloud9) and it is really inconvenient: the web browser intercepts shortcuts and, for example, if you press CTRL + W (which defines some shortcut inside of the IDE), then the web browser will close the page rather than executing the action inside the IDE. My solution was to start using Vivaldi as it allows to disable all the predefined web browser shortcuts.
  2. How do you view this idea: does a user start a local server which allows them to work in the IDE from the web browser or the user will have to work on our server through the web browser? I believe the former makes more sense since a connection interruption will cause much pain.

And what about UI in your case?

I looked up for the Android Emulator Architecture, it uses OpenGL to draw UI. We might consider to use Vulkan as it is more modern graphic API which will allow us to draw anything we want.

@glitchcore
Copy link
Contributor

About QEMU: today I learned about Renode and it looks good for emulating (authors compare themselves to QEMU)

@glitchcore
Copy link
Contributor

I have an experience working on code from a web browser (cloud9) and it is really inconvenient

To be fair, I also don't think that write some code in web-browser is a good idea, at least now, when we have limited community of developers and no need hyped and ultra available dev tool.

@glitchcore
Copy link
Contributor

glitchcore commented Aug 29, 2020

I have some plan about emulation and testing process:

  1. For simple case as unit tests or integration test that no require hardware we mock HW and replace RTOS syscalls to POSIX syscalls. We get simple linux app that easy to debug and get flexible control on hardware stubs.
  2. For UI we do:
    • creating web page with display and other UI elements, controls
    • building our FW for linux. All calls, writing data to UI like display or LED, redirects to unix socket writes, and messages from unix socket redirect to firmware (emulates button press, change batt level, insert/remove USB, etc.)
    • webserver that run our linux version fw, pass events from webpage to unixsocket and vice versa.

I implemented this idea in my other commercial project and I have some environment for this. Also it close to huimk project by @DrZlo13

  1. For more HW- and RTOS- specific checks we run real FW in Renode
  2. Eventually we run real FW on remote debug/test bench (Remote debug/test bench #26): flipper board + RPi + some stuff to control and check real hardware.

@glitchcore
Copy link
Contributor

I see that #26 and #22 have very close subject and maybe we should refactor this discussion

This was referenced Aug 31, 2020
@glitchcore
Copy link
Contributor

glitchcore commented Sep 4, 2020

I add https://github.com/Flipper-Zero/flipperzero-firmware-community/wiki/Environment page and create #97 for UI emulator.
This task for FW emulating (QEMU) and for web-based IDE and I place it to backlog.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Backlog Feature Request New feature or user-story you wanna add to flipper
Projects
None yet
Development

No branches or pull requests

4 participants