Interrupt support

[AFoxConsulting]

We recently purchased an EzSBC1 and are finding it quite an intriguing product. With its built-in serial terminal interface it reminds us of the old Intel 8052AH-BASIC or Octagon SBC development systems. A very nice self-contained development platform.

I read a thread here that said support for external interrupts was being added to the EzSBC1 starting with firmware 0.64. This was back in February of 2013. Well, it's now July 2014 and the firmware on this EzSBC1 is at 0.79 and we are wondering where the interrupt support is. Has it been implemented but not documented? We would like to know.

Thank you!

[Andries Pretorius]

I would also appreciate a response to this question Daniel.

Best regards

Andries Pretorius

[Daniel]

This is one of those 'Oops' moments. I remember working on the interrupt handler and testing it. When I look at the revision control notes then I can tell that I made changes to implement interrupts. The issue is, I didn't document what I did and now it is a struggle to figure out how it is supposed to work. I searched through the list of reserved words for things that look like interrupt functions and I found RETI which stands for RETurn from Interrupt.

I tested the instruction and if you type it into the editor in lower case and save the program it is converted to uppercase like all the other reserved words.

I just put it in a small test program and when it is executed I get the message "RETI without Interrupt line # 3". I remember that an interrupt handler was just a normal subroutine that ends in RETI instead of RETURN but I can't remember how I hooked it to an interrupt. INT is already a reserved word so I must have had a different plan. I need to go and figure out what I did and document it.

More soon.
Daniel

[Andries Pretorius]

Thanks for the feedback Daniel.

Andries

[AFoxConsulting]

Maybe you implemented it using an "ON INTx GOSUB" type of command? That's how some other systems do it.

Thanks for looking into it.

[Daniel]

I thought that that is what I did but ONINT isn't a reserved word. I'm wading through the code to figure out what I did but it is slow going. There is about 100k lines of c in the project of which all but about 5k lines is involved in the interpreter. The rest has to do with the editor and the monitor. I haven't worked on the code in some time so I've forgotten some of the structure but it is coming back to me. I will solve this soon.

I found several routines about installing and enabling the interrupt support. It may be that I reverted to an earlier version at some point and lost some code. I have all the versions under revision control since 0.31 so there's a lot of history. I'm beginning to think it will be easier to just re-write the missing section.

[AFoxConsulting]

Hello, Daniel.

How is the interrupt support going? I have a couple of clients who I would love to recommend the EzSBC1 to for their solutions, but they require interrupt support.

[Daniel]

The interrupt support is an embarrassing situation. I implemented it and it introduced a very hard to find set of bugs. I removed it and since then I found the source of the bugs which had nothing to do with the interrupt support but rather that I had run out of keywords. Because the micro doesn't have a lot of RAM I need to be careful how I use the RAM and the tokenizer's RAM use will double if I increase the total number of keywords to more than 128. I have a few undocumented keywords that I'm removing to make room for the interrupt handler and one new keyword for burst mode AD-conversion.

The tokenizer is very complex and some design decisions are hard to modify at this stage in the life of the code base. To simplify the tokenizer I chose to have all tokens be > 128 and then I can store strings and other ASCII by just placing them directly in the memory. When I read the memory to execute the program anything below 128 is literal text and above 128 is a token that needs to be interpreted. This decision is now a major PITA.

I'm working on it now and expect to be done in about a week from now.

Daniel

[AFoxConsulting]

Thank you for responding to this and your hard work, Daniel. As HAL would say, "I still have the utmost confidence in the mission."

[Daniel]

A week has come and gone and I'm still fighting the code. I have the reserved words implemented and it is recognized but I'm struggling with the implementation of the handler. The problem is that there are things happening in the background of the interpreter already such as the 100us timer tick, PWM generation and serial port buffering. I have to add another background 'task' without breaking the other functionality and it is turning out to be harder than I estimated. At least I got round to working on it and am making progress.