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
>
> 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 rtstofer●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...
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 nickdesantis54●April 6, 20132013-04-06
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.