| .. |
|
a1x
|
Build support for platform-specific shared memory logic. Not logic yet in place
|
2014-09-24 07:38:11 -06:00 |
|
arm
|
ELF relocations. Some relocation types do not have a named symbol associated with them. The design did not account for that case
|
2014-09-09 16:52:51 -06:00 |
|
armv6-m
|
Move common/up_signal_dispatch.c to armv6-m, armv7-m, and armv7-a. The armv7-a version needs to be different to handle the case where we are dispatch kernel mode signals when running under a user mode group
|
2014-09-16 13:35:29 -06:00 |
|
armv7-a
|
This completes the implementation of shared memory support
|
2014-09-24 09:27:17 -06:00 |
|
armv7-m
|
Move common/up_signal_dispatch.c to armv6-m, armv7-m, and armv7-a. The armv7-a version needs to be different to handle the case where we are dispatch kernel mode signals when running under a user mode group
|
2014-09-16 13:35:29 -06:00 |
|
c5471
|
There used to be two ways to pass parameters to new tasks, depending upon the configuration: Either (1) argv[] as created as an array with each string strdup'ed. Or (1) argv[] array and strings were created on the stack before the new task was started. Now, there is only one way, way (1). Way (2) might be slightly more compact, but this is not worth carry the complexity of two different ways of doing the same thing.
|
2014-09-01 15:39:34 -06:00 |
|
calypso
|
There used to be two ways to pass parameters to new tasks, depending upon the configuration: Either (1) argv[] as created as an array with each string strdup'ed. Or (1) argv[] array and strings were created on the stack before the new task was started. Now, there is only one way, way (1). Way (2) might be slightly more compact, but this is not worth carry the complexity of two different ways of doing the same thing.
|
2014-09-01 15:39:34 -06:00 |
|
common
|
More naming changes to get the stm3240g-eval/nxterm configuration building again
|
2014-09-20 15:53:28 -06:00 |
|
dm320
|
There used to be two ways to pass parameters to new tasks, depending upon the configuration: Either (1) argv[] as created as an array with each string strdup'ed. Or (1) argv[] array and strings were created on the stack before the new task was started. Now, there is only one way, way (1). Way (2) might be slightly more compact, but this is not worth carry the complexity of two different ways of doing the same thing.
|
2014-09-01 15:39:34 -06:00 |
|
imx
|
There used to be two ways to pass parameters to new tasks, depending upon the configuration: Either (1) argv[] as created as an array with each string strdup'ed. Or (1) argv[] array and strings were created on the stack before the new task was started. Now, there is only one way, way (1). Way (2) might be slightly more compact, but this is not worth carry the complexity of two different ways of doing the same thing.
|
2014-09-01 15:39:34 -06:00 |
|
kinetis
|
There used to be two ways to pass parameters to new tasks, depending upon the configuration: Either (1) argv[] as created as an array with each string strdup'ed. Or (1) argv[] array and strings were created on the stack before the new task was started. Now, there is only one way, way (1). Way (2) might be slightly more compact, but this is not worth carry the complexity of two different ways of doing the same thing.
|
2014-09-01 15:39:34 -06:00 |
|
kl
|
There used to be two ways to pass parameters to new tasks, depending upon the configuration: Either (1) argv[] as created as an array with each string strdup'ed. Or (1) argv[] array and strings were created on the stack before the new task was started. Now, there is only one way, way (1). Way (2) might be slightly more compact, but this is not worth carry the complexity of two different ways of doing the same thing.
|
2014-09-01 15:39:34 -06:00 |
|
lpc17xx
|
There used to be two ways to pass parameters to new tasks, depending upon the configuration: Either (1) argv[] as created as an array with each string strdup'ed. Or (1) argv[] array and strings were created on the stack before the new task was started. Now, there is only one way, way (1). Way (2) might be slightly more compact, but this is not worth carry the complexity of two different ways of doing the same thing.
|
2014-09-01 15:39:34 -06:00 |
|
lpc31xx
|
There used to be two ways to pass parameters to new tasks, depending upon the configuration: Either (1) argv[] as created as an array with each string strdup'ed. Or (1) argv[] array and strings were created on the stack before the new task was started. Now, there is only one way, way (1). Way (2) might be slightly more compact, but this is not worth carry the complexity of two different ways of doing the same thing.
|
2014-09-01 15:39:34 -06:00 |
|
lpc43xx
|
There used to be two ways to pass parameters to new tasks, depending upon the configuration: Either (1) argv[] as created as an array with each string strdup'ed. Or (1) argv[] array and strings were created on the stack before the new task was started. Now, there is only one way, way (1). Way (2) might be slightly more compact, but this is not worth carry the complexity of two different ways of doing the same thing.
|
2014-09-01 15:39:34 -06:00 |
|
lpc214x
|
There used to be two ways to pass parameters to new tasks, depending upon the configuration: Either (1) argv[] as created as an array with each string strdup'ed. Or (1) argv[] array and strings were created on the stack before the new task was started. Now, there is only one way, way (1). Way (2) might be slightly more compact, but this is not worth carry the complexity of two different ways of doing the same thing.
|
2014-09-01 15:39:34 -06:00 |
|
lpc2378
|
There used to be two ways to pass parameters to new tasks, depending upon the configuration: Either (1) argv[] as created as an array with each string strdup'ed. Or (1) argv[] array and strings were created on the stack before the new task was started. Now, there is only one way, way (1). Way (2) might be slightly more compact, but this is not worth carry the complexity of two different ways of doing the same thing.
|
2014-09-01 15:39:34 -06:00 |
|
nuc1xx
|
There used to be two ways to pass parameters to new tasks, depending upon the configuration: Either (1) argv[] as created as an array with each string strdup'ed. Or (1) argv[] array and strings were created on the stack before the new task was started. Now, there is only one way, way (1). Way (2) might be slightly more compact, but this is not worth carry the complexity of two different ways of doing the same thing.
|
2014-09-01 15:39:34 -06:00 |
|
sam34
|
Only SAM4 family has RTTDIS bit in the MR register. SourceForge bug #33 from Fabien Comte
|
2014-09-17 07:42:12 -06:00 |
|
sama5
|
Build support for platform-specific shared memory logic. Not logic yet in place
|
2014-09-24 07:39:06 -06:00 |
|
samd
|
There used to be two ways to pass parameters to new tasks, depending upon the configuration: Either (1) argv[] as created as an array with each string strdup'ed. Or (1) argv[] array and strings were created on the stack before the new task was started. Now, there is only one way, way (1). Way (2) might be slightly more compact, but this is not worth carry the complexity of two different ways of doing the same thing.
|
2014-09-01 15:39:34 -06:00 |
|
stm32
|
STM32 CAN correction suggested by Max Holtzberg
|
2014-09-24 08:23:05 -06:00 |
|
str71x
|
There used to be two ways to pass parameters to new tasks, depending upon the configuration: Either (1) argv[] as created as an array with each string strdup'ed. Or (1) argv[] array and strings were created on the stack before the new task was started. Now, there is only one way, way (1). Way (2) might be slightly more compact, but this is not worth carry the complexity of two different ways of doing the same thing.
|
2014-09-01 15:39:34 -06:00 |
|
tiva
|
There used to be two ways to pass parameters to new tasks, depending upon the configuration: Either (1) argv[] as created as an array with each string strdup'ed. Or (1) argv[] array and strings were created on the stack before the new task was started. Now, there is only one way, way (1). Way (2) might be slightly more compact, but this is not worth carry the complexity of two different ways of doing the same thing.
|
2014-09-01 15:39:34 -06:00 |
|
.gitignore
|
.dSYM only needs to be in the same .gitignore files as .exe
|
2013-05-30 15:02:04 -06:00 |
|
Makefile
|
The 'make export' target needs to bundle up the user C startup file (crt0), not the kernel head object
|
2014-09-04 13:31:34 -06:00 |
