- Aug 19, 2019
-
-
trilader authored
-
trilader authored
-
rahix authored
Delaying BLE startup by a bit seems to resolve the lockup issue we observed. This might need further attention in the future. Signed-off-by:
Rahix <rahix@rahix.de>
-
rahix authored
Signed-off-by:
Rahix <rahix@rahix.de>
-
- Aug 18, 2019
-
-
rahix authored
Add RGB values from styleguide as easily accessible values. Signed-off-by:
Rahix <rahix@rahix.de>
-
Jannis Rieger authored
-
rahix authored
Without resetting the FPU we get spurious failures in Pycardium. These manifest in many different forms, ranging from HardFaults and triggered assertions to "syntax errors" in loaded scripts while said script does not contain any. These failures stem from the FPU still containing state from the last loaded payload and thus sometimes corrupting stack locations where the previous payload had floating point state. Closes #72. Signed-off-by:
Rahix <rahix@rahix.de>
-
- Aug 17, 2019
-
-
torben authored
-
torben authored
-
genofire authored
-
rahix authored
Signed-off-by:
Rahix <rahix@rahix.de>
-
rahix authored
Co-authored-by:
fleur <spacecarrot@fleurshax.net> Signed-off-by:
Rahix <rahix@rahix.de>
-
rahix authored
Signed-off-by:
Rahix <rahix@rahix.de>
-
genofire authored
-
- Aug 16, 2019
-
-
schneider authored
-
schneider authored
-
Hauke Mehrtens authored
This adds BLE a characteristic which allows to set the current time. The time is set in milliseconds since 1.1.1970 as 64 bit value. Signed-off-by:
Hauke Mehrtens <hauke@hauke-m.de>
-
Hauke Mehrtens authored
This allows to set the current time in milliseconds. Signed-off-by:
Hauke Mehrtens <hauke@hauke-m.de>
-
rahix authored
Signed-off-by:
Rahix <rahix@rahix.de>
-
rahix authored
Signed-off-by:
Rahix <rahix@rahix.de>
-
rahix authored
The new LEDs implementation already does gamma correction so it is unnecessarily duplicated here now. This commit also adds a short hello message on the serial and sets the dim factor for the LEDs to a value where the LED effect is more visible. Signed-off-by:
Rahix <rahix@rahix.de>
-
rahix authored
When a load fails early and core 1 continues to loop in the reset stub, Epicardium might lock up when sending an interrupt and waiting for the API_CALL_MEM->int_id to be reset. Signed-off-by:
Rahix <rahix@rahix.de>
-
rahix authored
Signed-off-by:
Rahix <rahix@rahix.de>
-
- Aug 15, 2019
-
-
schneider authored
-
rahix authored
This changeset implements a proper lifecycle of the core 1 payload. The implementation faces some difficulties because there is no way to properly reset just core 1. Instead, we chose a cooperative approach: To perform a reset, core 1 jumps to a reset-stub and is then fed a new IVT location which it uses to "restart" with a new payload. The jump to the reset-stub is either voluntary by a call to epic_exit() or epix_exec(), or involuntary by Epicardium issuing a "reset" interrupt. This is a special API interrupt whose handler is pre-implemented in the API-caller lib. Additionally, this changeset contains support for defining which python script Pycardium should execute on startup. This way, scripts can issue the start of one another using `epic_exec("script-name.py")`. Finally, this changeset also changes the power-button behavior. Pressing the power button will now excert the following behavior: - `<400 ms`: Return back to menu - `<1 s`: Reset card10 - `>1 s`: Poweroff Signed-off-by:
Rahix <rahix@rahix.de>
-
Hauke Mehrtens authored
This adds basic file transfer support over BLE. The central provides a filename and then can transfer chunks of data which are written to the file. Signed-off-by:
Hauke Mehrtens <hauke@hauke-m.de>
-
rahix authored
Pressing the power button will now excert the following behavior: - `<400 ms`: Return back to menu - `<1 s`: Reset card10 - `>1 s`: Poweroff Signed-off-by:
Rahix <rahix@rahix.de>
-
rahix authored
Signed-off-by:
Rahix <rahix@rahix.de>
-
rahix authored
Signed-off-by:
Rahix <rahix@rahix.de>
-
rahix authored
This commit introduces a lifecycle for core 1. Based on the new loading system, a few APIs are made available to control the payload running on core 1. These are: 1. From core 1 (Pycardium, L0dable): - `epic_exec(name)` API Call: Request loading of a new payload by name. If the file does not exist, the call will return with an error code. Otherwise, control will go to the new payload. - `epic_exit(retcode)` API Call: Return from payload unconditionally. This call should be called whenever a payload is done or when it has hit an unrecoverable error. On `epic_exit`, Epicardium will reset the core back into the menu. 2. From inside Epicardium: - `epic_exec(name)`: This is **not** the same as the API call, as it needs a different implementation underneath. It will load a new payload and wait until this load actually completed (synchroneous). - `return_to_menu()`: Return core 1 to the menu script no matter what it is currently doing. This call is asynchroneous and will return immediately after scheduling the lifecycle task. This task will then take care of actually performing the load. Signed-off-by:
Rahix <rahix@rahix.de>
-
rahix authored
Signed-off-by:
Rahix <rahix@rahix.de>
-
rahix authored
Also add a mutex around API calls in preparation for future changes. Signed-off-by:
Rahix <rahix@rahix.de>
-
rahix authored
This commit introduces a way to control core 1. This is archieved by a predefined API-Interrupt: The reset interrupt. When triggered, it will bring the core back into its default state and wait for a new vector address from Epicardium. Once this vector address is transferred, it will start the new payload. This method only works as long as core 1 is responsive to the API interrupts. Cases where this might not be the case: - During times where core 1 has interrupts disabled - When in a higher priority exception handler - When core 1 has corrupted its IVT Signed-off-by:
Rahix <rahix@rahix.de>
-
rahix authored
Signed-off-by:
Rahix <rahix@rahix.de>
-