Has anyone had any luck getting both I2C connections to work with the
LPC2148?
I've got I2C0 working fine now and I tried to set up I2C1 the same way
(with the different pins of course) and I'm having some issues with it.
I'm going to go try to analyze it with a scope but if anyone has any tips
for that one I'd appreciate it.
LPC2148 Both I2C Connections
Started by ●April 6, 2013
Reply by ●April 6, 20132013-04-06
--- In l..., "nickdesantis54" wrote:
>
> Has anyone had any luck getting both I2C connections to work with the LPC2148?
>
> I've got I2C0 working fine now and I tried to set up I2C1 the same way (with the different pins of course) and I'm having some issues with it.
>
> I'm going to go try to analyze it with a scope but if anyone has any tips for that one I'd appreciate it.
>
I don't know where you are with your interrupt routines and I don't know which toolchain you are using but a couple of years ago it seemed that using GCC with the interrupt controller was often problematic. Nested interrupts absolutely wouldn't work because interrupts were disabled while the handler was running. There were also issues with the prolog and epilog on interrupt handlers.
So, some clever fellow came up with what came to be called an 'interrupt wrapper'. No, I'm not the guy...
You can read about the discussion back here:
http://tech.groups.yahoo.com/group/lpc2000/message/56129
I have uploaded a file:
ARM2106BlinkingLED.zip
This is specific to the LPC2106 but it should be a trivial port to the LPC2148. I'm not sure anything needs to be done. Basically, the code in crt.s is changed to properly handle the VIC. With this wrapper in place, all interrupt handlers become standard C functions. No qualifiers like __irq or any of that stuff. Just plain ordinary C functions.
You can keep your crt.s, all you have to do is make it look a lot like the one I posted. BTW, make sure to reserve enough stack space. I'm not sure that 32 bytes is enough. Given that several interrupts can nest, I would add quite a bit to the IRQ stack.
I don't know that this will help but one thing it does is make the interrupt handlers portable across toolchains.
Richard
>
> Has anyone had any luck getting both I2C connections to work with the LPC2148?
>
> I've got I2C0 working fine now and I tried to set up I2C1 the same way (with the different pins of course) and I'm having some issues with it.
>
> I'm going to go try to analyze it with a scope but if anyone has any tips for that one I'd appreciate it.
>
I don't know where you are with your interrupt routines and I don't know which toolchain you are using but a couple of years ago it seemed that using GCC with the interrupt controller was often problematic. Nested interrupts absolutely wouldn't work because interrupts were disabled while the handler was running. There were also issues with the prolog and epilog on interrupt handlers.
So, some clever fellow came up with what came to be called an 'interrupt wrapper'. No, I'm not the guy...
You can read about the discussion back here:
http://tech.groups.yahoo.com/group/lpc2000/message/56129
I have uploaded a file:
ARM2106BlinkingLED.zip
This is specific to the LPC2106 but it should be a trivial port to the LPC2148. I'm not sure anything needs to be done. Basically, the code in crt.s is changed to properly handle the VIC. With this wrapper in place, all interrupt handlers become standard C functions. No qualifiers like __irq or any of that stuff. Just plain ordinary C functions.
You can keep your crt.s, all you have to do is make it look a lot like the one I posted. BTW, make sure to reserve enough stack space. I'm not sure that 32 bytes is enough. Given that several interrupts can nest, I would add quite a bit to the IRQ stack.
I don't know that this will help but one thing it does is make the interrupt handlers portable across toolchains.
Richard
Reply by ●April 6, 20132013-04-06
--- In l..., "rtstofer" wrote:
> You can keep your crt.s, all you have to do is make it look a lot like the one I posted. BTW, make sure to reserve enough stack space. I'm not sure that 32 bytes is enough. Given that several interrupts can nest, I would add quite a bit to the IRQ stack.
>
> I don't know that this will help but one thing it does is make the interrupt handlers portable across toolchains.
Considering the number of registers that are stacked, I would increase the IRQ stack size to about 64 times the number of interrupt sources. It looks like 8 regs are stacked (32 bytes) per interrupt and I would prefer to have a LOT of empty stack once interrupts can nest.
Richard
> You can keep your crt.s, all you have to do is make it look a lot like the one I posted. BTW, make sure to reserve enough stack space. I'm not sure that 32 bytes is enough. Given that several interrupts can nest, I would add quite a bit to the IRQ stack.
>
> I don't know that this will help but one thing it does is make the interrupt handlers portable across toolchains.
Considering the number of registers that are stacked, I would increase the IRQ stack size to about 64 times the number of interrupt sources. It looks like 8 regs are stacked (32 bytes) per interrupt and I would prefer to have a LOT of empty stack once interrupts can nest.
Richard
Reply by ●April 6, 20132013-04-06
I appreciate the replies... I actually figured out what my problem was and it
was very simple. Turns out I was calling the stop function for the I2C0 line in
the state machine for I2C1, so I fixed that and boom it works!
Now I'm not worried about not graduating any more!
Thanks to everyone who has given me any help over the past month or two!
--- In l..., "rtstofer" wrote:
>
> --- In l..., "rtstofer" wrote:
>
> > You can keep your crt.s, all you have to do is make it look a lot like the one I posted. BTW, make sure to reserve enough stack space. I'm not sure that 32 bytes is enough. Given that several interrupts can nest, I would add quite a bit to the IRQ stack.
> >
> > I don't know that this will help but one thing it does is make the interrupt handlers portable across toolchains.
> Considering the number of registers that are stacked, I would increase the IRQ stack size to about 64 times the number of interrupt sources. It looks like 8 regs are stacked (32 bytes) per interrupt and I would prefer to have a LOT of empty stack once interrupts can nest.
>
> Richard
>
Now I'm not worried about not graduating any more!
Thanks to everyone who has given me any help over the past month or two!
--- In l..., "rtstofer" wrote:
>
> --- In l..., "rtstofer" wrote:
>
> > You can keep your crt.s, all you have to do is make it look a lot like the one I posted. BTW, make sure to reserve enough stack space. I'm not sure that 32 bytes is enough. Given that several interrupts can nest, I would add quite a bit to the IRQ stack.
> >
> > I don't know that this will help but one thing it does is make the interrupt handlers portable across toolchains.
> Considering the number of registers that are stacked, I would increase the IRQ stack size to about 64 times the number of interrupt sources. It looks like 8 regs are stacked (32 bytes) per interrupt and I would prefer to have a LOT of empty stack once interrupts can nest.
>
> Richard
>
