topic Re: strnlen not supported? in LPCXpresso IDE

strnlen not supported?

lpcware — Thu, 16 Jun 2016 00:45:04 GMT

Content originally posted in LPCWare by js-nxp on Sun Dec 11 14:53:02 MST 2011
str[B]n[/B]len NOT strlen is not working even though I have string.h included.

A search here doesn't bring up any results. Do I need to change compiler settings somewhere? I tried changing from "compiler default" to C99 and nothing else works.

And by the way to WHAT does the compiler defaults to? Obviously not C99 as I had several errors in some ported code complaining about the format of a for loop where the variable is declared inside the brackets as being only supported in C99 mode.

Re: strnlen not supported?

lpcware — Thu, 16 Jun 2016 00:45:05 GMT

Content originally posted in LPCWare by Ex-Zero on Sun Dec 11 15:27:50 MST 2011
strlen is included in string.h :eek:

Which library are you using?

C99: See http://support.code-red-tech.com/CodeRedWiki/RedlibAndNewlib?highlight=%28c99%29

Re: strnlen not supported?

lpcware — Thu, 16 Jun 2016 00:45:06 GMT

Content originally posted in LPCWare by rmteo on Sun Dec 11 15:33:21 MST 2011
He is referring to str[COLOR=Red][B]n[/B][/COLOR]len, see http://linux.about.com/library/cmd/blcmdl3_strnlen.htm

Re: strnlen not supported?

lpcware — Thu, 16 Jun 2016 00:45:07 GMT

Content originally posted in LPCWare by TheFallGuy on Sun Dec 11 16:10:45 MST 2011
Don't get confused by the language dialect and the C library - they are different.

C99 in the compiler refers to language dialect/constructs that you can use - such as the for loop initial declaration (for int i=0; i<0; i++).

C99 in the library defines the function calls that are available within the C library (and the header files).

If you want to use C99 libraries, you will need to link with Newlib which provides a complete C99 implementation (Redlib is c90 plus some bits)

The compiler default is 'gnu90' which is c90 plus some GNU language extensions.

You can change the language dialect in the compiler settings dialog.

I don't know if strnlen is c90, c99, or C++ - you should check this yourself. If Newlib doesn't resolve it, then it is most likely an extension.

Re: strnlen not supported?

lpcware — Thu, 16 Jun 2016 00:45:07 GMT

Content originally posted in LPCWare by Ex-Zero on Sun Dec 11 16:23:31 MST 2011
Sorry, should explain my previous post:

#1 As mentioned above, strlen is included in string.h :)

#2 If you want to see if strnlen is supported, just check this files (REDLIB and NEWLIB version, not linux) :mad:

#3 string.h of NEWLIB is including strnlen, so changing library to NEWLIB should include strnlen :)

#4 Made a test meanwhile and NEWLIB is supporting strnlen. So you just have to use NEWLIB :rolleyes:

Re: strnlen not supported?

lpcware — Thu, 16 Jun 2016 00:45:08 GMT

Content originally posted in LPCWare by js-nxp on Sun Dec 11 19:32:55 MST 2011

Quote:
#4 Made a test meanwhile and NEWLIB is supporting strnlen. So you just have to use NEWLIB

GREAT it works. :) It helps when people know where to look for things, I threw myself in the deep end a couple of days ago and everything is still very vague.

So the CMSIS (V2 now with 4.10) still needs to be part of the project but just select the Newlib for the quickstart menu. Getting the hang of things.

Pretty happy I have a RGB GLCD code almost fully ported now and running in 8 bit mode, unfortunately one gets only 32K with the LPC1114/301 and can't include all the pictures in flash as I have with another chip which is 128K.

The next question would be if there is a pin compatible chip that I can swap on the board...not strecthing the frienship I hope. ;)

Re: strnlen not supported?

lpcware — Thu, 16 Jun 2016 00:45:09 GMT

Content originally posted in LPCWare by Ex-Zero on Sun Dec 11 22:18:25 MST 2011

Quote:

...a pin compatible chip that I can swap on the board...

There are a lot of chips available: http://www.nxp.com/ps/#/i=71391 :eek:

As you can see there, LPC1227 has 128k flash. :) Unfortunately it's not pin compatible with LPC1114, but also available as LPCXpresso:

http://www.embeddedartists.com/products/lpcxpresso/lpc1227_xpr.php

Re: strnlen not supported?

lpcware — Thu, 16 Jun 2016 00:45:10 GMT

Content originally posted in LPCWare by js-nxp on Sun Dec 11 23:28:05 MST 2011
I think my head is about to pop with just the small chip.:eek:

So the LPC1114 has 32K max, maybe NXP will make the same chip with more flash in the future. Who knows. 64K would just be right for now.

Several of the chips I use have up to 4 different size memories and all pin compatible.

Re: strnlen not supported?

lpcware — Thu, 16 Jun 2016 00:45:10 GMT

Content originally posted in LPCWare by rmteo on Mon Dec 12 08:29:33 MST 2011

Quote: js-nxp

So the LPC1114 has 32K max, maybe NXP will make the same chip with more flash in the future. Who knows. 64K would just be right for now.

For a beginner, 32K is lot of flash to outgrow - perhaps you need to take a different approach. In your first post, you talked about porting some Atmel code for driving TFT LCDs.

I am developing the framework for an HMI (handheld terminal) that incorporates a 320x240 TFT LCD, membrane keypad (25 keys), USART comms, RTC, battery back-up, etc. The application has 9 concurrent tasks that are managed by an RTOS. I have created my own graphic primitives for boxes, buttons, etc.
[IMG]http://www.funbidders.com/my_img/TEST-6BF.jpg[/IMG]
Currently it uses 13,128 bytes of FLASH and 880 bytes of RAM. In fact, the total memory used is small enough (14KB) to fit completely into RAM (my development MCU has 96K RAM). With the application in RAM, downloading during development is super fast and FLASH wear is eliminated. Also, with everything loaded in RAM, debugging is very quick plus you have unlimited hardware breakpoints. The entire application fits into the smallest (16K FLASH, 4K RAM) device of the product family (Cortex-M3 but non-NXP) I am using for this project.
[IMG]http://www.funbidders.com/my_img/TEST-6BD.jpg[/IMG]

Re: strnlen not supported?

lpcware — Thu, 16 Jun 2016 00:45:11 GMT

Content originally posted in LPCWare by js-nxp on Mon Dec 12 13:33:40 MST 2011

Quote:
For a beginner, 32K is lot of flash to outgrow

Not a beginner in all sense of the word :) 30+ years with micros and around 45 years in electronics.

Quote:
perhaps you need to take a different approach.

The overall code is about 13K and will do pretty much all graphics now, the rest is uncopressed pictures data about 45K.

The same program takes just over 60K in an 8 bit AVR, so it is pretty much the same with the the LPC1114, talk of a 50% code size reduction at last week's seminar wasn't quite correct it seems (both using GCC). Of course the data size would be the same in both, once I get everything working I can compare the 2 for actual code size, still having a couple of issues getting the font printing correctly.

I was told by a colleague to explore compression for the data with RLE (or was it REL??) but that will be down the road.

The AVR code running is here http://vimeo.com/33243761 a bit rough but useable. I'll make a better one later on and have the 2 there for comparison.
The M0 runs pretty fast in 8 bit mode interface but it's 48MHz vs 8MHz for the AVR in 16 bit mode.Vimeo seems to still have a bug, need to go into couch mode to view Kentec
3.5" video.

Re: strnlen not supported?

lpcware — Thu, 16 Jun 2016 00:45:11 GMT

Content originally posted in LPCWare by rmteo on Mon Dec 12 13:59:39 MST 2011
Go with the LPC1768/9 and be done with it.