--- In l..., Giuseppe Marullo wrote:
>
> Hi Daniel and Martin and others,
> thanks for all your help.
>
> I have 24MHz of clock (Fosc), AFAIK the maximum supported by LPC2138 is
> 60MHz. So 48MHz (desired CCLK) should be the maximum frequency, right?
>
> CCLK = M x Fosc or
> CCLK = Fcco / (2 x P)
>
> So M = 2
>
> PO /(CCLKx2)
>
> P can vary between 156e6/(CCLKx2) = 1.625 and 320e6/CCLKx2)= 3.333, so
> the only selectable P must be 2.
>
> Value for PCON [6:5/4:0] >
> [10 0001] = 0x21
>
> APBDIV is set for Same clock, so:
>
> SCB_VPBDIV = mainBUS_CLK_FULL;
>
> Now, the question:
>
> why this:
>
> #define mainCOM_TEST_BAUD_RATE ( ( unsigned long ) 115200 )
>
> Gets me with 230k baud instead of 115k? Surely it is my fault, simply I
> don't understand why.
>
Have you looked at how the baudrate is calculated in Serial.c?
What about the definition:
#define configCPU_CLOCK_HZ ( unsigned long ) 58982400 )
in FreeRTOSConfig.h?
Did you change configCPU_CLOCK_HZ to match your 48MHz setup?
I still don't know how you got twice the baudrate but I do know how you
could get a little bit off.
As to getting UART1 to work, that will be trivial once you get the various
clocks and dividers working.
Richard
LPC2138 another try on freertos
Started by ●December 2, 2009
Reply by ●December 16, 20092009-12-16
Reply by ●December 16, 20092009-12-16
Richard,
>#define configCPU_CLOCK_HZ ( unsigned long ) 58982400 )
>in FreeRTOSConfig.h?
>Did you change configCPU_CLOCK_HZ to match your 48MHz setup?
Yes, I did:
#define configCPU_CLOCK_HZ ( ( unsigned long ) 48000000 )
>Have you looked at how the baudrate is calculated in Serial.c?
I tried to follow the code, nothing special configCPU_CLOCK_HZ is used to get the UART clock (16x).
I don't know much about FreeRTOS but it does seem it is the right way.
I could live with the baud rate for now, I need to know about the printf...is it possible to use with the output on the uart?
Actually I can't debug either, so printf is the bare minimum.
Giuseppe
>#define configCPU_CLOCK_HZ ( unsigned long ) 58982400 )
>in FreeRTOSConfig.h?
>Did you change configCPU_CLOCK_HZ to match your 48MHz setup?
Yes, I did:
#define configCPU_CLOCK_HZ ( ( unsigned long ) 48000000 )
>Have you looked at how the baudrate is calculated in Serial.c?
I tried to follow the code, nothing special configCPU_CLOCK_HZ is used to get the UART clock (16x).
I don't know much about FreeRTOS but it does seem it is the right way.
I could live with the baud rate for now, I need to know about the printf...is it possible to use with the output on the uart?
Actually I can't debug either, so printf is the bare minimum.
Giuseppe
Reply by ●December 17, 20092009-12-17
--- In l..., Giuseppe Marullo wrote:
> I could live with the baud rate for now, I need to know about the printf...is it possible to use with the output on the uart?
> Actually I can't debug either, so printf is the bare minimum.
>
> Giuseppe
>
Yes, you can use printf(). But I believe you have to implement various stubs in syscalls to create stdout.
Look at www.jcwren.com/arm for code that implements EVERYTHING on an LPC2148. This code revolves around FreeRTOS and it's excellent.
HOWEVER, many people don't want to implement syscalls and especially don't want to use stdio (or any part of newlib, for that matter). Both printf and sprintf bring along a lot of code and require a heap and its management.
You can always write things like putc(), puts(), puthexWord(), puthexByte(), putDec(), etc. They are trivial to code, require no heap and are easy to debug. I ALWAYS write these for a new chip right after I get the UART working. I almost never use JTAG so I need them for debugging.
Conversion functions like itoa() come right out of "The C Programming Language" by Kernighan & Ritchie.
Richard
> I could live with the baud rate for now, I need to know about the printf...is it possible to use with the output on the uart?
> Actually I can't debug either, so printf is the bare minimum.
>
> Giuseppe
>
Yes, you can use printf(). But I believe you have to implement various stubs in syscalls to create stdout.
Look at www.jcwren.com/arm for code that implements EVERYTHING on an LPC2148. This code revolves around FreeRTOS and it's excellent.
HOWEVER, many people don't want to implement syscalls and especially don't want to use stdio (or any part of newlib, for that matter). Both printf and sprintf bring along a lot of code and require a heap and its management.
You can always write things like putc(), puts(), puthexWord(), puthexByte(), putDec(), etc. They are trivial to code, require no heap and are easy to debug. I ALWAYS write these for a new chip right after I get the UART working. I almost never use JTAG so I need them for debugging.
Conversion functions like itoa() come right out of "The C Programming Language" by Kernighan & Ritchie.
Richard
Reply by ●December 17, 20092009-12-17
>Yes, you can use printf(). But I believe you have to
implement various stubs in syscalls to create stdout.
Ouch, short answer is no then....
Giuseppe
Ouch, short answer is no then....
Giuseppe
Reply by ●December 17, 20092009-12-17
--- In l..., Giuseppe Marullo wrote:
>
> >Yes, you can use printf(). But I believe you have to implement various stubs in syscalls to create stdout.
>
> Ouch, short answer is no then....
>
> Giuseppe
>
I don't think the answer is no. But, for me, it is a bit of sophistication that I neither need nor want.
OTOH, there is an rprintf.c file in the Group's Files folder that implements a subset and doesn't require the heap or syscalls.
You might try to Google for 'ARM7 printf'. The very first response "ARM Projects" apparently shows you just what is needed for stdio printf().
There's an explanation over here: http://openhardware.net/Embedded_ARM/NewLib_Stubs
I think you should try to find out why the baud rate is incorrect. This problem will perpetuate itself when you start dealing with timers.
In fact, try to set up a timer to blink the LED at some frequency and see if it works out properly.
Richard
>
> >Yes, you can use printf(). But I believe you have to implement various stubs in syscalls to create stdout.
>
> Ouch, short answer is no then....
>
> Giuseppe
>
I don't think the answer is no. But, for me, it is a bit of sophistication that I neither need nor want.
OTOH, there is an rprintf.c file in the Group's Files folder that implements a subset and doesn't require the heap or syscalls.
You might try to Google for 'ARM7 printf'. The very first response "ARM Projects" apparently shows you just what is needed for stdio printf().
There's an explanation over here: http://openhardware.net/Embedded_ARM/NewLib_Stubs
I think you should try to find out why the baud rate is incorrect. This problem will perpetuate itself when you start dealing with timers.
In fact, try to set up a timer to blink the LED at some frequency and see if it works out properly.
Richard
Reply by ●December 20, 20092009-12-20
>I think you should try to find out why the baud rate
is incorrect. This problem will perpetuate itself when you start dealing with
timers.
I have found the problem, it really took me time because I was fooled by the fact that the board needs to be powered down some seconds between each test. I don't have any reset button...
Well, I tried the spreadsheet into the files section and apparently the only one combination I should use is M=2 and P=4 (and not M=2 and P=2), with APBDIV= 1 and it gives me 115200 baud. So far so good (not much testing but...).
>I don't think the answer is no. But, for me, it is a bit of sophistication that I neither need nor want.
Sorry, I was meaning to say it is far from my expertise...I am still reading the doc you referenced
Ok now:
1) Is it possible to use gbd/insight to debug this demo? I am unable to do it, really out of clue here. I got an errors:
C:\temp\FreeRTOS\Demo\ARM7_LPC2106_GCC.test2/LPC2106_flash.gdb:8: Error in sourced command file:
Memory access error while loading section startup.
And then I get lost into integer.c and some isr routine, shouldn't it start with a breakpoint in main.c ? Do I have to disable interrups or what?
This is my gdb file:
target remote localhost:3333
monitor soft_reset_halt
monitor arm7_9 sw_bkpts disable
monitor arm7_9 force_hw_bkpts enable
monitor mww 0xE01FC040 0x0001
monitor mdw 0xE01FC040
break main
load
continue
2) Any clue on how to port it in Eclipse? I will try but I guess is not trivial
TIA,
Giuseppe
On 12/17/2009 3:59 PM, rtstofer wrote:
>
> --- In l..., Giuseppe Marullo wrote:
>
>>
>>> Yes, you can use printf(). But I believe you have to implement various stubs in syscalls to create stdout.
>>>
>> Ouch, short answer is no then....
>>
>> Giuseppe
>>
>>
> I don't think the answer is no. But, for me, it is a bit of sophistication that I neither need nor want.
>
> OTOH, there is an rprintf.c file in the Group's Files folder that implements a subset and doesn't require the heap or syscalls.
>
> You might try to Google for 'ARM7 printf'. The very first response "ARM Projects" apparently shows you just what is needed for stdio printf().
>
> There's an explanation over here: http://openhardware.net/Embedded_ARM/NewLib_Stubs
>
> I think you should try to find out why the baud rate is incorrect. This problem will perpetuate itself when you start dealing with timers.
>
> In fact, try to set up a timer to blink the LED at some frequency and see if it works out properly.
>
> Richard
>
I have found the problem, it really took me time because I was fooled by the fact that the board needs to be powered down some seconds between each test. I don't have any reset button...
Well, I tried the spreadsheet into the files section and apparently the only one combination I should use is M=2 and P=4 (and not M=2 and P=2), with APBDIV= 1 and it gives me 115200 baud. So far so good (not much testing but...).
>I don't think the answer is no. But, for me, it is a bit of sophistication that I neither need nor want.
Sorry, I was meaning to say it is far from my expertise...I am still reading the doc you referenced
Ok now:
1) Is it possible to use gbd/insight to debug this demo? I am unable to do it, really out of clue here. I got an errors:
C:\temp\FreeRTOS\Demo\ARM7_LPC2106_GCC.test2/LPC2106_flash.gdb:8: Error in sourced command file:
Memory access error while loading section startup.
And then I get lost into integer.c and some isr routine, shouldn't it start with a breakpoint in main.c ? Do I have to disable interrups or what?
This is my gdb file:
target remote localhost:3333
monitor soft_reset_halt
monitor arm7_9 sw_bkpts disable
monitor arm7_9 force_hw_bkpts enable
monitor mww 0xE01FC040 0x0001
monitor mdw 0xE01FC040
break main
load
continue
2) Any clue on how to port it in Eclipse? I will try but I guess is not trivial
TIA,
Giuseppe
On 12/17/2009 3:59 PM, rtstofer wrote:
>
> --- In l..., Giuseppe Marullo wrote:
>
>>
>>> Yes, you can use printf(). But I believe you have to implement various stubs in syscalls to create stdout.
>>>
>> Ouch, short answer is no then....
>>
>> Giuseppe
>>
>>
> I don't think the answer is no. But, for me, it is a bit of sophistication that I neither need nor want.
>
> OTOH, there is an rprintf.c file in the Group's Files folder that implements a subset and doesn't require the heap or syscalls.
>
> You might try to Google for 'ARM7 printf'. The very first response "ARM Projects" apparently shows you just what is needed for stdio printf().
>
> There's an explanation over here: http://openhardware.net/Embedded_ARM/NewLib_Stubs
>
> I think you should try to find out why the baud rate is incorrect. This problem will perpetuate itself when you start dealing with timers.
>
> In fact, try to set up a timer to blink the LED at some frequency and see if it works out properly.
>
> Richard
>
Reply by ●December 20, 20092009-12-20
--- In l..., Giuseppe Marullo wrote:
>
> 2) Any clue on how to port it in Eclipse? I will try but I guess is not trivial
>
> TIA,
>
> Giuseppe
Can't help with GDB but there are a few Eclipse demos with the FreeRTOS distribution.
The absolute best code out there is still at www.jcwren.com/arm and I know for a fact that it can be built using Eclipse and GNUARM. I haven't looked at the distribution in a while but I don't recall having any particular problem importing it into Eclipse. You probably just put the source tree under your workspace and then tell Eclipse to import an existing project.
I use that demo code as a reference for just about everything.
Richard
>
> 2) Any clue on how to port it in Eclipse? I will try but I guess is not trivial
>
> TIA,
>
> Giuseppe
Can't help with GDB but there are a few Eclipse demos with the FreeRTOS distribution.
The absolute best code out there is still at www.jcwren.com/arm and I know for a fact that it can be built using Eclipse and GNUARM. I haven't looked at the distribution in a while but I don't recall having any particular problem importing it into Eclipse. You probably just put the source tree under your workspace and then tell Eclipse to import an existing project.
I use that demo code as a reference for just about everything.
Richard
