You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The updated WARDuino virtual machine, has an extended debugger API, support for asynchronous callbacks, networking primitives, improved testing, and wider platform support. This paper represent the research side of the new version, and gives the first comprehensive overview of the virtual machine.
8
12
9
-
EDWARD is the novel <i>out-of-place</i> debugger for WARDuino, developed to simplify debugging concurrent programs. The EDWARD debugger allows developers to debug programs largely on their own laptop—thereby enabling more advanced debugging techniques—while using a remote microcontroller as a zombie that can still provide realtime peripheral data. Asynchronous events on the remote zombie are captured by the local debugger, and a new set of debugging instructions give developers control over the timings of the events. [-> EDWARD reference](/reference/edward/)
EDWARD is the novel <i>out-of-place</i> debugger for WARDuino, developed to simplify debugging concurrent programs. The EDWARD debugger allows developers to debug programs largely on their own laptop—thereby enabling more advanced debugging techniques—while using a remote microcontroller as a zombie that can still provide realtime peripheral data. Asynchronous events on the remote zombie are captured by the local debugger, and a new set of debugging instructions give developers control over the timings of the events.
14
20
15
-
WARDuino was the first WebAssembly virtual machine to target microcontrollers, such as the ESP32s, and included a remote debugger and support for partial over-the-air reprogramming of the devices. [-> WARDuino reference](/reference/)
WARDuino was the first WebAssembly virtual machine to target microcontrollers, such as the ESP32s, and included a remote debugger and support for partial over-the-air reprogramming of the devices.
Copy file name to clipboardExpand all lines: warduino/guide/latch.md
+2-1Lines changed: 2 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -2,7 +2,8 @@
2
2
title: Latch
3
3
next: Developer's Guide
4
4
---
5
-
# Testing: Latch framework
5
+
6
+
# Testing on Hardware
6
7
7
8
**<spanstyle="font-variant: small-caps;">Latch</span> (Large-scale Automated Testing on Constraint Hardware)** is a novel testing framework for running large scale unit and integration tests in constrained environments.
Copy file name to clipboardExpand all lines: warduino/reference/contributing.md
+41-1Lines changed: 41 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -19,4 +19,44 @@ html.dark .low {
19
19
background-color: rgba(46, 160, 67, 0.15);
20
20
border-color: rgba(46, 160, 67, 0.4);
21
21
}
22
-
</style>
22
+
</style>
23
+
24
+
## ✨ How Can I Contribute?
25
+
26
+
If you want to help with development, issues on the [roadmap](https://github.com/orgs/TOPLLab/projects/1) with low priority are a good starting point.
27
+
28
+
Any sort of contribution is welcome! Including, but not limited to:
29
+
30
+
- Report a bug you identified
31
+
- Write code which enhances the system or fixes an issue
32
+
- PRs that port WARDuino to new platforms, and tutorials to use WARDuino on new boards
33
+
34
+
## 🎨 Style Guide
35
+
36
+
### Commit Messages
37
+
38
+
- Capitalize the first line and each paragraph
39
+
- Use present tense (_"Add feature ..."_ instead of _"Added feature ..."_)
40
+
- Use the imperative mood (_"Fix delay ..."_ instead of _"Fixes delay ..."_)
41
+
- Do not end the subject line with a period
42
+
- Use the body to explain what and why you have done something, refer to issues and PRs if you want
43
+
44
+
Check out the [guidelines for commit messages](https://gist.github.com/robertpainsi/b632364184e70900af4ab688decf6f53) for more examples and recommendations.
45
+
46
+
### Branches
47
+
48
+
- Follow a simple naming scheme that clearly describes the topic you are working on
49
+
50
+
### Pull Requests
51
+
52
+
- Use the description field to describe what you are introducing or changing in your branch
53
+
- Try to make small PRs that fix/introduce a single item
54
+
55
+
### Merge Branches
56
+
57
+
- You cannot push directly to `main`, please create a branch with your changes and open a PR to request code review before merging
58
+
- You can use a ["Draft" PR](https://github.blog/2019-02-14-introducing-draft-pull-requests/) if your work is not done yet
59
+
- Verify that all status checks are passing
60
+
- Click "Ready to Review" to request merging your branch into `main`
61
+
- Since PRs should introduce a single cohesive change to the code, the preferred merge method is [Squash and merge](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/about-pull-request-merges#squash-and-merge-your-commits)
0 commit comments