Interrupts? What interrupts? I thought we were talking about a hardware initiated event switch or vectored jump!
Yup, because there is only one of these, clearly interrupts is incorrect anyway.
Users of other MCU may expect a whole line-up of interrupts, so I'm fine with more precise terminology
You set $1F5 with the address (and optionally initial C/Z). See this example here. Note that, in the case of pin interrupts, you must also first use SETQ to avoid spurious interrupts.I'd expect those currently Hex names would be cleaned up to known Assembler Names Constants, and some clarity that there are 4 pairs of Store/Return available. (IIFC)
1F6 and 1F7 are special in that they are destinations for the hubexec version of the Link instruction (second Link in the instruction set). So they are intended to be used as Link-registers, for example in GCC.
Andy
Chip
In "P2-Hot" we had a CORDIC supporting instruction FRAC.
Was this forgotten or sacrificed for real estate?
I'm just building a road map of where I've come from so as to plan the next exciting P2 journey.
The new instruction set looks good. Plenty of goodies there.
Brian
Chip, without opening up a can of worms, might it be possible to have 2 sets of interrupt tables, one pair for the timer interrupt and one pair for the other interrupts. The intent is to permit a separate timeout over the other interrupts.
So the inserted instruction would be
LINK $1F2,$1F3 WC,WZ and
LINK $1F4,$1F5 WC,WZ
Just set the timeout small. I don't really know why Chip even bothered with the timeout feature. If there is noise/debounce issues then fix it elsewhere.
If you are reading a serial line and the data stops abruptly in the middle, a timeout would break free from the routine.
This is one of the reasons we wanted WAITPxx xxx WC.
IF we use interrupts to read serial input streams then we will want to have a timeout.
If it's simple and a few gates then it might make the timer a separate interrupt vector.
Chip, without opening up a can of worms, might it be possible to have 2 sets of interrupt tables, one pair for the timer interrupt and one pair for the other interrupts. The intent is to permit a separate timeout over the other interrupts.
So the inserted instruction would be
LINK $1F2,$1F3 WC,WZ and
LINK $1F4,$1F5 WC,WZ
Is the LINK instruction identical to the old JMPRET instruction? If so, why not just call it JMPRET?
Is the LINK instruction identical to the old JMPRET instruction? If so, why not just call it JMPRET?
See back a little - LINK is certainly less than ideal, and Chip suggested a likely change to the clearer
CALLD Address, RegD
& I think that has a paired
RETD RegD
OK, so it's similar to "JMPRET RegD, #Address" on P1, and RETD is similar to "JMP RegD". I guess the main difference is that the C and Z flags are saved/restored.
EDIT: So just to be clear, is Address an absolute address or is it the register that contains the absolute address?
OK, so it's similar to "JMPRET RegD, #Address" on P1, and RETD is similar to "JMP RegD". I guess the main difference is that the C and Z flags are saved/restored.
EDIT: So just to be clear, is Address an absolute address or is it the register that contains the absolute address?
The docs say
(jump to 20-bit absolute/relative address, write {C,Z,P[19:0]} to $1F6..$1F9)
Cluso99 said:
If you are reading a serial line and the data stops abruptly in the middle, a timeout would break free from the routine.
This is one of the reasons we wanted WAITPxx xxx WC.
IF we use interrupts to read serial input streams then we will want to have a timeout.
If it's simple and a few gates then it might make the timer a separate interrupt vector.
Opps, when you mentioned interrupts I thought you were talking about the IRQ hold-off timer. Interrupts have no use for timeouts themselves.
As far as I know all instructions that pause/loop will majorly mess with interrupt jitter. The two features are mutually exclusive.
Please don't add multiple simultaneous interrupts. That's is where much of the interrupt complication enters the picture with existing architectures. The current approach is in that 80/20 sweet spot.
Chip
In "P2-Hot" we had a CORDIC supporting instruction FRAC.
Was this forgotten or sacrificed for real estate?
I'm just building a road map of where I've come from so as to plan the next exciting P2 journey.
The new instruction set looks good. Plenty of goodies there.
Brian
You can still do FRAC by doing A/B as $AAAAAAAA00000000/$BBBBBBBB using the QDIV operation. This involves setting B beforehand via SETQ.
Chip,
What is the accuracy/precision of the CORDIC maths?
I ask because I hope it is usable for implementing floating point types in C/C++ to the IEEE 754 standard.
Chip, without opening up a can of worms, might it be possible to have 2 sets of interrupt tables, one pair for the timer interrupt and one pair for the other interrupts. The intent is to permit a separate timeout over the other interrupts.
So the inserted instruction would be
LINK $1F2,$1F3 WC,WZ and
LINK $1F4,$1F5 WC,WZ
It would be simple to accommodate multiple sources with multiple vectors, but I'm worried we would need to start making a more complicated system to handle simultaneous interrupts. Right now, there is no special context of being in an interrupt. A link instruction was inserted, that's all. It seems the hold-off counter solution wouldn't suffice, anymore, with multiple sources. It's hard to think about!
OK, so it's similar to "JMPRET RegD, #Address" on P1, and RETD is similar to "JMP RegD". I guess the main difference is that the C and Z flags are saved/restored.
EDIT: So just to be clear, is Address an absolute address or is it the register that contains the absolute address?
The absolute address is stored in the D register, preceded by the flags: {%0000000000,C,Z,P[19:0]}
OK 33 bits should be good enough for single precision (need only 23). Hopefully somebody smarter than me can use that to get the 53 bits required for doubles.
Then we can get Javascript running on the P II
Chip,
What is the accuracy/precision of the CORDIC maths?
I ask because I hope it is usable for implementing floating point types in C/C++ to the IEEE 754 standard.
It's 32-bit quality, and 64 bit in the case of QMUL (32x32, unsigned) and QSQR (64-bit value to 32-bit root).
OK, so it's similar to "JMPRET RegD, #Address" on P1, and RETD is similar to "JMP RegD". I guess the main difference is that the C and Z flags are saved/restored.
EDIT: So just to be clear, is Address an absolute address or is it the register that contains the absolute address?
The docs say
(jump to 20-bit absolute/relative address, write {C,Z,P[19:0]} to $1F6..$1F9)
The original version that Chip posted says
(jump to S/@, write {C,Z,P[19:0]} to D, 'LINK INA,S/@' = 'JMP S/@')
Is there an updated version of the doc with the new wording? So S is an absolute address between 0 and $1FF, correct? Does that mean that the CALLD instruction can only jump to cog addresses? That wouldn't be too useful for the hubexec mode. I believe the CALLD instruction was intended for C code that uses a link register to store the return address.
Ignore my comment above. I see that there are two version of LINK/CALLD.
Chip, without opening up a can of worms, might it be possible to have 2 sets of interrupt tables, one pair for the timer interrupt and one pair for the other interrupts. The intent is to permit a separate timeout over the other interrupts.
So the inserted instruction would be
LINK $1F2,$1F3 WC,WZ and
LINK $1F4,$1F5 WC,WZ
It would be simple to accommodate multiple sources with multiple vectors, but I'm worried we would need to start making a more complicated system to handle simultaneous interrupts. Right now, there is no special context of being in an interrupt. A link instruction was inserted, that's all. It seems the hold-off counter solution wouldn't suffice, anymore, with multiple sources. It's hard to think about!
Thank you Chip.
As much as I was in favor of a single interrupt per cog I would not want to see that expand into the kind of complications that come with multiple interrupt sources, vectors, and priorities. Besides, with 16 cogs there can be 16 interrupts, without a lot of complications.
is the argument for the pin interrupts a single pin or a pin mask?
IIRC the Smart Pins have a 'pin' pathway to the COG, but that 'pin' pathway can be set to precondition in the Smart Pin cell.It may be a direct pin copy, or it may be a Pin-edge, or a Counter (now in Pin Cell) or some merged signal.
It does make sense to allow the HW Vector to fire from either the buried timer, or the 'Pin' signal (which then allows the more comprehensive Pin Counters to fire INTs, eg for DDS precision )
As for multiple vectors ? - that comes down to the HW costs. Multiple timers is going to be costly.
Maybe the Vector-inserter is simple enough to allow Timer and Pin ? ( but on a first-in basis.)No HW priority management needed.What is the Logic cost of just the event -> Vector insertion part ?
Priority/lowest jitter would be managed by disable of HW Timer -> Sw Timer, and allocate one Vector to Pin.However, having a simple two HW vectors (Timer/Pin) would be flexible.
Chip, without opening up a can of worms, might it be possible to have 2 sets of interrupt tables, one pair for the timer interrupt and one pair for the other interrupts. The intent is to permit a separate timeout over the other interrupts.
So the inserted instruction would be
LINK $1F2,$1F3 WC,WZ and
LINK $1F4,$1F5 WC,WZ
It would be simple to accommodate multiple sources with multiple vectors, but I'm worried we would need to start making a more complicated system to handle simultaneous interrupts. Right now, there is no special context of being in an interrupt. A link instruction was inserted, that's all. It seems the hold-off counter solution wouldn't suffice, anymore, with multiple sources. It's hard to think about!
Fine Chip. We don't want to over complicate things and I am not really a proponent of interrupts anyway. If they are there then we will find ways to use them in special drivers.
Chip, without opening up a can of worms, might it be possible to have 2 sets of interrupt tables, one pair for the timer interrupt and one pair for the other interrupts. The intent is to permit a separate timeout over the other interrupts.
So the inserted instruction would be
LINK $1F2,$1F3 WC,WZ and
LINK $1F4,$1F5 WC,WZ
It would be simple to accommodate multiple sources with multiple vectors, but I'm worried we would need to start making a more complicated system to handle simultaneous interrupts. Right now, there is no special context of being in an interrupt. A link instruction was inserted, that's all. It seems the hold-off counter solution wouldn't suffice, anymore, with multiple sources. It's hard to think about!
Fine Chip. We don't want to over complicate things and I am not really a proponent of interrupts anyway. If they are there then we will find ways to use them in special drivers.
Cluso, I was thinking about your request, as it pertained to serial. Of course, I don't know which serial you were talking about, but I'm going to guess you meant TTL self-clocked asynchronous serial (a UART). With that in mind, it occurs to me that a pin interrupt timeout should not be necessary in the first place. Here's the general approach I'm thinking of:
* Use the interrupt mechanism for read, use the "main" task for write
For the receive routine:1. Read is always started by setting up an interrupt on RX falling edge (presumably the beginning of the start bit).2. Once a falling edge is discovered, switch from pin interrupts to timer interrupts, such that the RX pin is sampled at bittime/2. If the value is not low, then this was not a start bit. Go back to step 1.3. Now, set the timer interrupt to bittime, thereby sampling the bit stream in the middle of each following bit.4. Continue sampling for the number of bits, plus the parity and stop bit(s). If the parity wrong, return to Step 1. If stop bits are low, return to Step 1.5. Otherwise, good data. Store to hub (or to local buffer that the "main" task can transfer later).6. Go back to step 1.
Now, the obvious issue here is that, if you start a read mid-frame, you need a way to correct for this. There are two different approaches I can think of, both of which can be done with the current interrupt approach.
The point is, I don't think you will need a timeout, at least for the "TTL serial". And I think the code itself will be very straight forward. As much as I am still in awe of Chip's one-cog serial driver, I suspect the current simple interrupts will make that sort of legerdemain unnecessary most of the time.
Chip, without opening up a can of worms, might it be possible to have 2 sets of interrupt tables, one pair for the timer interrupt and one pair for the other interrupts. The intent is to permit a separate timeout over the other interrupts.
So the inserted instruction would be
LINK $1F2,$1F3 WC,WZ and
LINK $1F4,$1F5 WC,WZ
It would be simple to accommodate multiple sources with multiple vectors, but I'm worried we would need to start making a more complicated system to handle simultaneous interrupts. Right now, there is no special context of being in an interrupt. A link instruction was inserted, that's all. It seems the hold-off counter solution wouldn't suffice, anymore, with multiple sources. It's hard to think about!
Fine Chip. We don't want to over complicate things and I am not really a proponent of interrupts anyway. If they are there then we will find ways to use them in special drivers.
Cluso, I was thinking about your request, as it pertained to serial. Of course, I don't know which serial you were talking about, but I'm going to guess you meant TTL self-clocked asynchronous serial (a UART). With that in mind, it occurs to me that a pin interrupt timeout should not be necessary in the first place. Here's the general approach I'm thinking of:
* Use the interrupt mechanism for read, use the "main" task for write
For the receive routine:1. Read is always started by setting up an interrupt on RX falling edge (presumably the beginning of the start bit).2. Once a falling edge is discovered, switch from pin interrupts to timer interrupts, such that the RX pin is sampled at bittime/2. If the value is not low, then this was not a start bit. Go back to step 1.3. Now, set the timer interrupt to bittime, thereby sampling the bit stream in the middle of each following bit.4. Continue sampling for the number of bits, plus the parity and stop bit(s). If the parity wrong, return to Step 1. If stop bits are low, return to Step 1.5. Otherwise, good data. Store to hub (or to local buffer that the "main" task can transfer later).6. Go back to step 1.
Now, the obvious issue here is that, if you start a read mid-frame, you need a way to correct for this. There are two different approaches I can think of, both of which can be done with the current interrupt approach.
The point is, I don't think you will need a timeout, at least for the "TTL serial". And I think the code itself will be very straight forward. As much as I am still in awe of Chip's one-cog serial driver, I suspect the current simple interrupts will make that sort of legerdemain unnecessary most of the time.
Yes, I was thinking serial in general as well as async ttl uart. I thought the receive could be done automatically via interrupts, and the Tx in main.
I think there are other potential uses too. I am not so sure about the usefulness of the time delay that Chip has implemented although we will see.
Looking forward to doing some testing. Also the smart pins will be very interesting in seeing their capabilities.
Comments
Yup, because there is only one of these, clearly interrupts is incorrect anyway.
Users of other MCU may expect a whole line-up of interrupts, so I'm fine with more precise terminology
How do you tell it where to jump to on interrupt?
You set $1F5 with the address (and optionally initial C/Z). See this example here. Note that, in the case of pin interrupts, you must also first use SETQ to avoid spurious interrupts.I'd expect those currently Hex names would be cleaned up to known Assembler Names Constants, and some clarity that there are 4 pairs of Store/Return available. (IIFC)
Which make me wonder did $1F6 and $1F7 become sometime special registers. They aren't special on the last instruction set:
-- addressable registers
--
-- addr read write name
--
--
-- 000-1F7 RAM RAM
--
-- 1F8 PTRA RAM+PTRA PTRA
-- 1F9 PTRB RAM+PTRB PTRB
-- 1FA INA RAM INA
-- 1FB INB RAM INB
-- 1FC RAM RAM+OUTA OUTA
-- 1FD RAM RAM+OUTB OUTB
-- 1FE RAM RAM+DIRA DIRA
-- 1FF RAM RAM+DIRB DIRB
1F6 and 1F7 are special in that they are destinations for the hubexec version of the Link instruction (second Link in the instruction set). So they are intended to be used as Link-registers, for example in GCC.
Andy
Thank you sir, that makes sense!
In "P2-Hot" we had a CORDIC supporting instruction FRAC.
Was this forgotten or sacrificed for real estate?
I'm just building a road map of where I've come from so as to plan the next exciting P2 journey.
The new instruction set looks good. Plenty of goodies there.
Brian
So the inserted instruction would be
LINK $1F2,$1F3 WC,WZ and
LINK $1F4,$1F5 WC,WZ
This is one of the reasons we wanted WAITPxx xxx WC.
IF we use interrupts to read serial input streams then we will want to have a timeout.
If it's simple and a few gates then it might make the timer a separate interrupt vector.
So the inserted instruction would be
LINK $1F2,$1F3 WC,WZ and
LINK $1F4,$1F5 WC,WZ
Is the LINK instruction identical to the old JMPRET instruction? If so, why not just call it JMPRET?
Is the LINK instruction identical to the old JMPRET instruction? If so, why not just call it JMPRET?
See back a little - LINK is certainly less than ideal, and Chip suggested a likely change to the clearer
CALLD Address, RegD
& I think that has a paired
RETD RegD
EDIT: So just to be clear, is Address an absolute address or is it the register that contains the absolute address?
EDIT: So just to be clear, is Address an absolute address or is it the register that contains the absolute address?
The docs say
(jump to 20-bit absolute/relative address, write {C,Z,P[19:0]} to $1F6..$1F9)
Cluso99 said:
If you are reading a serial line and the data stops abruptly in the middle, a timeout would break free from the routine.
This is one of the reasons we wanted WAITPxx xxx WC.
IF we use interrupts to read serial input streams then we will want to have a timeout.
If it's simple and a few gates then it might make the timer a separate interrupt vector.
Opps, when you mentioned interrupts I thought you were talking about the IRQ hold-off timer. Interrupts have no use for timeouts themselves.
As far as I know all instructions that pause/loop will majorly mess with interrupt jitter. The two features are mutually exclusive.
In "P2-Hot" we had a CORDIC supporting instruction FRAC.
Was this forgotten or sacrificed for real estate?
I'm just building a road map of where I've come from so as to plan the next exciting P2 journey.
The new instruction set looks good. Plenty of goodies there.
Brian
You can still do FRAC by doing A/B as $AAAAAAAA00000000/$BBBBBBBB using the QDIV operation. This involves setting B beforehand via SETQ.
What is the accuracy/precision of the CORDIC maths?
I ask because I hope it is usable for implementing floating point types in C/C++ to the IEEE 754 standard.
So the inserted instruction would be
LINK $1F2,$1F3 WC,WZ and
LINK $1F4,$1F5 WC,WZ
It would be simple to accommodate multiple sources with multiple vectors, but I'm worried we would need to start making a more complicated system to handle simultaneous interrupts. Right now, there is no special context of being in an interrupt. A link instruction was inserted, that's all. It seems the hold-off counter solution wouldn't suffice, anymore, with multiple sources. It's hard to think about!
EDIT: So just to be clear, is Address an absolute address or is it the register that contains the absolute address?
The absolute address is stored in the D register, preceded by the flags: {%0000000000,C,Z,P[19:0]}
Then we can get Javascript running on the P II
What is the accuracy/precision of the CORDIC maths?
I ask because I hope it is usable for implementing floating point types in C/C++ to the IEEE 754 standard.
It's 32-bit quality, and 64 bit in the case of QMUL (32x32, unsigned) and QSQR (64-bit value to 32-bit root).
EDIT: So just to be clear, is Address an absolute address or is it the register that contains the absolute address?
The docs say
(jump to 20-bit absolute/relative address, write {C,Z,P[19:0]} to $1F6..$1F9)
The original version that Chip posted says
(jump to S/@, write {C,Z,P[19:0]} to D, 'LINK INA,S/@' = 'JMP S/@')Is there an updated version of the doc with the new wording? So S is an absolute address between 0 and $1FF, correct? Does that mean that the CALLD instruction can only jump to cog addresses? That wouldn't be too useful for the hubexec mode. I believe the CALLD instruction was intended for C code that uses a link register to store the return address.Ignore my comment above. I see that there are two version of LINK/CALLD.
So the inserted instruction would be
LINK $1F2,$1F3 WC,WZ and
LINK $1F4,$1F5 WC,WZ
It would be simple to accommodate multiple sources with multiple vectors, but I'm worried we would need to start making a more complicated system to handle simultaneous interrupts. Right now, there is no special context of being in an interrupt. A link instruction was inserted, that's all. It seems the hold-off counter solution wouldn't suffice, anymore, with multiple sources. It's hard to think about!
Thank you Chip.
As much as I was in favor of a single interrupt per cog I would not want to see that expand into the kind of complications that come with multiple interrupt sources, vectors, and priorities. Besides, with 16 cogs there can be 16 interrupts, without a lot of complications.
I guess it has to be a single pin
Maybe could be four puns though
One per byte
IIRC the Smart Pins have a 'pin' pathway to the COG, but that 'pin' pathway can be set to precondition in the Smart Pin cell.It may be a direct pin copy, or it may be a Pin-edge, or a Counter (now in Pin Cell) or some merged signal.
It does make sense to allow the HW Vector to fire from either the buried timer, or the 'Pin' signal (which then allows the more comprehensive Pin Counters to fire INTs, eg for DDS precision )
As for multiple vectors ? - that comes down to the HW costs. Multiple timers is going to be costly.
Maybe the Vector-inserter is simple enough to allow Timer and Pin ? ( but on a first-in basis.)No HW priority management needed.What is the Logic cost of just the event -> Vector insertion part ?
Priority/lowest jitter would be managed by disable of HW Timer -> Sw Timer, and allocate one Vector to Pin.However, having a simple two HW vectors (Timer/Pin) would be flexible.
So the inserted instruction would be
LINK $1F2,$1F3 WC,WZ and
LINK $1F4,$1F5 WC,WZ
It would be simple to accommodate multiple sources with multiple vectors, but I'm worried we would need to start making a more complicated system to handle simultaneous interrupts. Right now, there is no special context of being in an interrupt. A link instruction was inserted, that's all. It seems the hold-off counter solution wouldn't suffice, anymore, with multiple sources. It's hard to think about!
Fine Chip. We don't want to over complicate things and I am not really a proponent of interrupts anyway. If they are there then we will find ways to use them in special drivers.
So the inserted instruction would be
LINK $1F2,$1F3 WC,WZ and
LINK $1F4,$1F5 WC,WZ
It would be simple to accommodate multiple sources with multiple vectors, but I'm worried we would need to start making a more complicated system to handle simultaneous interrupts. Right now, there is no special context of being in an interrupt. A link instruction was inserted, that's all. It seems the hold-off counter solution wouldn't suffice, anymore, with multiple sources. It's hard to think about!
Fine Chip. We don't want to over complicate things and I am not really a proponent of interrupts anyway. If they are there then we will find ways to use them in special drivers.
Cluso, I was thinking about your request, as it pertained to serial. Of course, I don't know which serial you were talking about, but I'm going to guess you meant TTL self-clocked asynchronous serial (a UART). With that in mind, it occurs to me that a pin interrupt timeout should not be necessary in the first place. Here's the general approach I'm thinking of:
* Use the interrupt mechanism for read, use the "main" task for write
For the receive routine:1. Read is always started by setting up an interrupt on RX falling edge (presumably the beginning of the start bit).2. Once a falling edge is discovered, switch from pin interrupts to timer interrupts, such that the RX pin is sampled at bittime/2. If the value is not low, then this was not a start bit. Go back to step 1.3. Now, set the timer interrupt to bittime, thereby sampling the bit stream in the middle of each following bit.4. Continue sampling for the number of bits, plus the parity and stop bit(s). If the parity wrong, return to Step 1. If stop bits are low, return to Step 1.5. Otherwise, good data. Store to hub (or to local buffer that the "main" task can transfer later).6. Go back to step 1.
Now, the obvious issue here is that, if you start a read mid-frame, you need a way to correct for this. There are two different approaches I can think of, both of which can be done with the current interrupt approach.
The point is, I don't think you will need a timeout, at least for the "TTL serial". And I think the code itself will be very straight forward. As much as I am still in awe of Chip's one-cog serial driver, I suspect the current simple interrupts will make that sort of legerdemain unnecessary most of the time.
So the inserted instruction would be
LINK $1F2,$1F3 WC,WZ and
LINK $1F4,$1F5 WC,WZ
It would be simple to accommodate multiple sources with multiple vectors, but I'm worried we would need to start making a more complicated system to handle simultaneous interrupts. Right now, there is no special context of being in an interrupt. A link instruction was inserted, that's all. It seems the hold-off counter solution wouldn't suffice, anymore, with multiple sources. It's hard to think about!
Fine Chip. We don't want to over complicate things and I am not really a proponent of interrupts anyway. If they are there then we will find ways to use them in special drivers.
Cluso, I was thinking about your request, as it pertained to serial. Of course, I don't know which serial you were talking about, but I'm going to guess you meant TTL self-clocked asynchronous serial (a UART). With that in mind, it occurs to me that a pin interrupt timeout should not be necessary in the first place. Here's the general approach I'm thinking of:
* Use the interrupt mechanism for read, use the "main" task for write
For the receive routine:1. Read is always started by setting up an interrupt on RX falling edge (presumably the beginning of the start bit).2. Once a falling edge is discovered, switch from pin interrupts to timer interrupts, such that the RX pin is sampled at bittime/2. If the value is not low, then this was not a start bit. Go back to step 1.3. Now, set the timer interrupt to bittime, thereby sampling the bit stream in the middle of each following bit.4. Continue sampling for the number of bits, plus the parity and stop bit(s). If the parity wrong, return to Step 1. If stop bits are low, return to Step 1.5. Otherwise, good data. Store to hub (or to local buffer that the "main" task can transfer later).6. Go back to step 1.
Now, the obvious issue here is that, if you start a read mid-frame, you need a way to correct for this. There are two different approaches I can think of, both of which can be done with the current interrupt approach.
The point is, I don't think you will need a timeout, at least for the "TTL serial". And I think the code itself will be very straight forward. As much as I am still in awe of Chip's one-cog serial driver, I suspect the current simple interrupts will make that sort of legerdemain unnecessary most of the time.
Yes, I was thinking serial in general as well as async ttl uart. I thought the receive could be done automatically via interrupts, and the Tx in main.
I think there are other potential uses too. I am not so sure about the usefulness of the time delay that Chip has implemented although we will see.
Looking forward to doing some testing. Also the smart pins will be very interesting in seeing their capabilities.