If you write your own LMM kernel* then you could have a dedicated cog to watch for "interrupts". When the watcher cog sees something that is deemed as a trigger, it inserts a special instruction into the code which would be a simple "jump to ISR". Again - this would be slow, but it would be relatively simple and the majority of the work is already done since we already have lots of LMM* kernels in PropGCC (cmm, lmm, xmmc, xmm-split, xmm-single).
*I don't mean specifically PropGCC's LMM - I mean any model that fetches instructions from a shared stack
If you want to exactly simulate interrupts with 2 cogs you would have to come up with a method that allows only one cog to run at a time. Your main cog would run until the interrupt cog needs to run, and then it would have to wait for the interrupt cog to finish before it can continue. This would be difficult to do in the Prop because the main cog would have to continually check to see if the interrupt cog needs to run.
Fortunately, the Teacup code doesn't require that only one cog can run at a time. There are only a few cases, such as when the queue is being manipulated that require dedicated access by a cog. The approach that I took with the Teacup code was to use a lock to protect those areas of the code. The main cog will request the lock for a short period of time when it needs to run a critical code segment. The interrupt cog will hang onto the lock for the entire time that it processes an interrupt. In theory the interrupt cog could work like the main cog, and only lock critical sections of code, but the Teacup code does not currently do that. You would have to identify the critical sections in the interrupt code, and add the locking code yourself. However, I don't think that is necessary.
Also, the 16k of COG memory isn't easily usable unless you can break your application into separate parallel pieces. But it seems like XMM could have solved this problem as long as its performance was good enough. Is the Teacup software structured in a way that XMM would be usable?
I really don't know too much about XMM or the possiblities.
What I do know is that I need more space, especially stack space, and I am looking for any reasonable ideas from those folks who can understand the Teacup project. I recently made a new post, with a new project build archive, within the Teacup port thread, which outlines the current status and known problems. I would certainly appreciate any good advice that might make this a successful project. Here is a link to the most up to date information and project archive: http://forums.parallax.com/showthread.php/159950-The-Teacup-Port-A-Work-In-Progress-3D-Printer-Firmware?p=1324910&viewfull=1#post1324910
This is overly sismple nonsense, but this keeps going through my head:
1) Assign a cog to be the "interupt handler" (IH). When an interupt trigger occures, this cog takes the data, and places it in memory. IH sets a flag so the propssor cog can notice its avaiable, and IH resets the interupt. One cog is probably fast enough to handl all the interupts that the processor will see in this application.
2) Write a HAL for the prop gathers up any interupts, and assignes them to IH. Thoroughly debug this, then compile the remaining applications as ususal.
But again, it still seems easier to implement the teacup functionality on the prop using the teacup code as a cheat sheet for the algorithms. Interupts are a workaround to allow multiple tasks on a single core processor. Interupts on the prop feels like the long way around the block to get mnext door.
Comments
*I don't mean specifically PropGCC's LMM - I mean any model that fetches instructions from a shared stack
Fortunately, the Teacup code doesn't require that only one cog can run at a time. There are only a few cases, such as when the queue is being manipulated that require dedicated access by a cog. The approach that I took with the Teacup code was to use a lock to protect those areas of the code. The main cog will request the lock for a short period of time when it needs to run a critical code segment. The interrupt cog will hang onto the lock for the entire time that it processes an interrupt. In theory the interrupt cog could work like the main cog, and only lock critical sections of code, but the Teacup code does not currently do that. You would have to identify the critical sections in the interrupt code, and add the locking code yourself. However, I don't think that is necessary.
I really don't know too much about XMM or the possiblities.
What I do know is that I need more space, especially stack space, and I am looking for any reasonable ideas from those folks who can understand the Teacup project. I recently made a new post, with a new project build archive, within the Teacup port thread, which outlines the current status and known problems. I would certainly appreciate any good advice that might make this a successful project. Here is a link to the most up to date information and project archive: http://forums.parallax.com/showthread.php/159950-The-Teacup-Port-A-Work-In-Progress-3D-Printer-Firmware?p=1324910&viewfull=1#post1324910
1) Assign a cog to be the "interupt handler" (IH). When an interupt trigger occures, this cog takes the data, and places it in memory. IH sets a flag so the propssor cog can notice its avaiable, and IH resets the interupt. One cog is probably fast enough to handl all the interupts that the processor will see in this application.
2) Write a HAL for the prop gathers up any interupts, and assignes them to IH. Thoroughly debug this, then compile the remaining applications as ususal.
But again, it still seems easier to implement the teacup functionality on the prop using the teacup code as a cheat sheet for the algorithms. Interupts are a workaround to allow multiple tasks on a single core processor. Interupts on the prop feels like the long way around the block to get mnext door.