GabrielTofvesson/ASMThread
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Updated README

Browse Source 
Added description of how the threading works (to some degree)
This commit is contained in:
Gabriel Tofvesson 2019-02-20 17:40:59 +01:00
parent 48b72ea667
commit bb08c2e2a4
1 changed files with 50 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

49
README.md
View File

@ -47,6 +47,53 @@ exited, in which case it is skipped until all other threads have exited. If all
threads have exited, the threading system should reasonably be disabled and the threads have exited, the threading system should reasonably be disabled and the
processor should probably be put into deepsleep indefinitely. processor should probably be put into deepsleep indefinitely.
## Thread design:
### Thread flags:
These bits should _under no circumstances_ be set manually. To change them,
call the relevant exported routines.
From LSB to MSB, the thread flag bits are as follows:
**0:** Thread lock (set to lock, clear to unlock)
**1:** Thread exit (set to inform thread-switch routine that thread should be killed)
**2-7:** Reserved
### Thread frame:
Currently, the thread frame system consists of a single component: a pointer.
The pointer points to the thread stack data. When a thread is first started, it
contains (at least) a complete register mapping. The default mapping is that
all registers except *PC*, *PSR* and *SP* are set to *0*. *PC* is set to the
relevant execution address and *PSR* is set to *0x81000000*. On top of the
stack data, the pointer also contains the relevant stack pointer address at the
lowest address pointed to by the frame. The default value for the stack-pointer
is *STACK_BASE - 0x40*: this because it fits the entirety of the default
register values. When the SysTick ISR exits back to the thread, all registers
are popped into their respective registers, as such, a fresh thread's *SP* will
have the value *STACK_BASE*.
### Threading with other interrupts:
As it stands, thread-switching will be postponed in the case that it is
triggered during another ISR. As such, it is important that the system doesn't
have large amounts of interrupts, as this may impede thread-switching.
You may ask why another ISR should prevent thread-switching. Well, we cannot
trigger a thread-switch in an ISR, since that would mean that the thread
switched to would be considered to be a part of said ISR by the processor,
as such the thread would inherently prevent lower-priority interrupts from
being triggered. Additionally, we cannot be sure how large the ISRs stack is,
so there would be no way of replacing the underlying thread's stack without
potentially affecting (or destroying) the ISRs stack.
A possible solution to this would be to include a flag for ISRs to check if
they blocked a thread-switch and thus allowing ISRs to manually switch threads
ad hoc if SysTick wasn't able to. This would additionally solve the problem
of nested interrupts preventing thread-switching, since the switch would be
delegated to the interrupt of lowest priority (i.e. the one that would
otherwise return to the thread).
## TODOS: ## TODOS:
* Automatic thread-switching after unlock if a switch was missed * Automatic thread-switching after unlock if a switch was missed
* Smarter malloc * Smarter malloc
@ -54,6 +101,8 @@ processor should probably be put into deepsleep indefinitely.
* Faster thread-switching * Faster thread-switching
* Runtime thread-instruction variability * Runtime thread-instruction variability
* Main-thread exiting (auto dsleep) * Main-thread exiting (auto dsleep)
* ISR-friendly thread-switching solution
* Thread-yielding (manual thread-switch trigger)
## Tested platforms: ## Tested platforms:
* Tiva C-series * Tiva C-series