HELP! What MCU (greater than 8-bits of smarts) is easiest to graduate to?

[dannyf]

Check out the prototype of strcpy().

Also, pick up a C book. Learn to live without "goto".

[SuzyC]

Thanks again, dannyf,


The question boils down to if I can ignore this warning or not!

How do I check out the prototype of strcpy(char*, const char *); //? how does this help?

Another Question:  I used to have sin and cos and log and exp and Abs functions with <math.h> with pic compiler 9.83 pro. How do I get these valuable functions back??

How can I write my code so that it works with strings and math?

[c4757p]

The question boils down to if I can ignore this warning or not!

No. Please don't ignore warnings. Your code will be much better for it. A few of them are unnecessary, but the corrections to make them go away tend to be unobtrusive anyway, and many of them are very helpful.

How do I check out the prototype of strcpy(char*, const char *);

That is the prototype. It's the set of types which the function takes and returns. (Okay, you omitted the return type: char*) The problem is that char and unsigned char are not directly compatible: one has a range -128 to 127, and one has a range 0 to 255. One is not a subset of the other, so you can't directly translate between them.

Just be consistent. Use char everywhere. Why do you need it to be unsigned, anyway? It's not a number per se, it's a code which references a specific character. The sign doesn't matter.

If you have an unsigned integer of size n and you need to convert it to a signed integer to actually do math on it (rather than just actual text), you should either perform a check to make sure it will fit, or convert it to a signed integer of size greater than n. I personally recommend including <inttypes.h> or <stdint.h>, which define type names that include the size as part of the name (uint8_t, uint16_t, int8_t, int16_t, etc) to make this a bit clearer.

[SuzyC]

Thanks C4757p,

I have to write to a 16 char by 7-seg LCD that simulates alphanumeric characters, and the resulting
output of a Conv() routine is to convert ASCII to 7-seg approximations of the correct characters. so values of converted chars to be serially fed to the LCD can(esp. when I include the d.p.) range from 0 to 255.

The question that puzzles me is why are pointers signed numbers since they point to an absolute memory location?

The only real question is how to get my strcpy function to work?

And how do I do some calculations with higher math functions such as sin and tan cos and Abs etc.? I could do them with the old 8-bit PIC compiler!

Do I have to throw away an ability to do floating point transcendental math functions to gain the use of a Cypress mcu?

[c4757p]

Pointers aren't numbers at all - they're number-like, and they can be added, subtracted and converted to formal numbers, but they're definitely not signed integers.

However - in C, a pointer type can (and should) indicate what it points to. A char* isn't a signed pointer, it's a pointer to memory which is to be interpreted as char. If you change the pointer type, you're still pointing to the same memory, but it will be interpreted differently.

Your strcpy function will work if you give it the types it expects. I don't see anything wrong with your code - it will run, despite the warning. Change unsigned char to char and it should work with no warning at all.

If you need to convert them to unsigned 8-bit integers to transmit them to the LCD, this would formally be considered part of encoding them for transmission, and should be done as part of transmission itself, not universally throughout your code. They're just char up until you need them to have a specific format to send them to the LCD. You can "convert" with a cast:

Code: [Select]

// Here's a normal char
char c = 'Q';

// Here it is as unsigned: implicit cast
unsigned char d = c;

// Here it is again as unsigned: explicit cast
do_something ((unsigned char) c);

Store them as char because that's what they are - characters. Convert them when it's time to transmit. I did say not to do this, earlier, but specifically for mathematics - it can change the meaning of the number. What it will do is take the binary encoding of the char and just re-interpret it as an unsigned char. That's exactly what you want to do, so it's okay.

As for the math - I don't know, that might be platform specific. I'm sure you can do it. You might have to tell the compiler to link to the math library - with GCC and similar compilers, this is done by adding -lm as a compile option.

I should include the usual admonition against floating-point math in microcontrollers - but I've definitely encountered a few times when it was quite useful, so if the MCU is powerful enough I really can't complain. Just make sure it really is the best way to accomplish what you want.

[SuzyC]

As I attempt to understand C in its most pure ANSI form, a character array should be allowed to hold any unsigned char (byte) value in that same range.  Why should string functions allow an ASCII character that has a negative value???

This signed char pointer argument idea is  not.completely clear to me.

As far a the pointer goes, I am a bit confused. If there exists a 4K RAM space and a 32K Flash space, then an integer would be required to precise the absolute location of a single byte(char) in memory.  Why point to a char array with a signed number?

[c4757p]

As I attempt to understand C in its most pure ANSI form, a character array should be allowed to hold any unsigned char (byte) value in that same range.  Why should string functions allow an ASCII character that has a negative value???

This signed char pointer argument idea is  not.completely clear to me.

Crappy historical reasons. I agree, characters should be unsigned. There's no reason for a character code to be negative. In reality, it's even worse than this: not specified. char can be equivalent to signed char or unsigned char depending on the platform. Best to just use plain char whenever you're handling actual text, as the C library will be built around whichever they chose, and then use uint8_t and int8_t from inttypes.h when you want numbers. The number of properly coded applications where you both need ASCII characters and knowledge of the signedness of the value in the same variable should be very small.

As far a the pointer goes, I am a bit confused. If there exists a 4K RAM space and a 32K Flash space, then an integer would be required to precise the absolute location of a single byte(char) in memory.  Why point to a char array with a signed number?

The pointer isn't signed, the data to which it points is.

[SuzyC]

C4757p, thanks again.

I think I've cleared up a little of the fog in my mind about pointers and char vars, but I am still a little confused:  If a 'char' is a signed byte by default, then if I write:

static char Buf[40];
char *bp=Buf;

main()

//Then if (for example) if Buf[]="This is a long collection of letters"; and Buf[38]=255; and this char  is a very necessary delimiter character I've created to parse my strings prior to the LCD, then  will strcpy copy this string correctly to another display buffer, correctly, that is  including the Buf[39] value of 255?

[SuzyC]

Does anyone know of where to obtain a free math.h and how to attach them to PSoC Creator?

Sometimes you need a log or a sine value..nothing else will do as well in an algorithm.

It is a surprise to me that adding just one floating point division ate up approx 5% of the Flash space, almost as bad as with the 8-bit compiler!

[c4757p]

Yes, your character 255 will be included. If char is signed on this platform, then it will automatically be converted to the signed equivalent (-1) when stored, and converted back if you read it as unsigned. If you compare it to something, they will both be converted to the same type for comparison.

math.h is part of the standard C library; it ought to be there already! What sort of error are you getting when you try to include it?

Sometimes you need a log or a sine value..nothing else will do as well in an algorithm.

Depending on what you're doing, it can be more efficient sometimes to use a lookup table or an approximation. sin(x) is close to just x for small values, for example. Integer logarithms can be computed by repeated division, which is space-efficient if a division algorithm is already in your code (or the device has a hardware divider), though it's not time-efficient.

It is a surprise to me that adding just one floating point statement ate up approx 5% of the Flash space, almost as bad as with the 8-bit compiler!

The chip likely doesn't actually support floating-point (only a few specialized ARMs do), so the moment you do anything with FP arithmetic, the compiler has to dump in an entire floating-point emulation suite.

[miguelvp]

Not to change the subject, but I just wanted to drop this doc about the PSoC analog capabilities, this doc is the the PSoC 3 and 5 but some of the data should apply to the PSoC 4200.

http://files.em.avnet.com/docs/Cypress-Analog%20Peripherals.pdf

[SuzyC]

C4757p:

Thanks for the very helpful explanations helping me to understand these elementary C issues!

I was in error. I was able to #include <math.h> without a problem!

if I code:

static char Buf[40], *bp=Buf;
//Then
strcpy(bp,"Hey this works!"); //speaks for itself

[dannyf]

You are trying to approach this with a piece-meal approach. I would suggest that that is not the best course for a beginner. Instead, learn to code properly - get a book, or take a class, etc., and learn to approach coding issues systemically - read the compiler manuals, read the library guide, read the IDE manuals, etc.

It is going to be a painful process but in the end you will go further than what you are attempting to do now.

[neslekkim]

Shouldn't this be ok? http://www.cplusplus.com/reference/cstring/strcpy/

[Jeroen3]

A char[] is equal to a char * const. They are both fixed memory location pointers.
Therefore it is unnecessary to use your duplicate approach, using Buf without [] is enough.

A pointer in C has the following format: type *.
Where type can even be void, and the * says it's a pointer to type.
Not going into the const kung-fu here. http://en.wikipedia.org/wiki/Const-correctness

A pointer is always the architecture bus width. On ARM Cortex this is 32 bit. They are never signed, even though there are relative jump instructions available in assembler.
Please note that the type a pointer points to is crucial, You can safely cast a pointer to word type to a pointer to a byte type, but never cast a byte type pointer to a word type pointer since this will generate alignment errors. (you cannot do a 32 bit read/write on unaligned data)
http://en.wikipedia.org/wiki/Word_(computer_architecture)

Pointers are the most difficult part of C, but if you understand them you C potential is endless. 
They are very useful since ARM Cortex can only argument or return 4 elements without stack. And there is a single linear address bus.

[dannyf]

A char[] is equal to a char * const.

"char * const" vs. "const char *': what's the difference?

Define them and play with them.

BTW, "const" is one of those things that almost all embedded compilers got it wrong but everyone has used to such "wrongs".

[SuzyC]

Thanks dannyF for the advice,

I read the info pointed to the links in the last two posts and found them to completely without any ability of my simple mind to even attempt to understand. I remain constantly confused by their pointedly complicated explanations.

There are no schools nearby in my area that will offer a course in C-language, except maybe C# or C++ for Windows database development or working with MSOFFICE apps, so I learn by discovering each trip wire as I come across it. And thanks to gentlemen like you and all the others on forums I can get some pointers to  help clarify and repair some of the small holes in the fat heap of my self-learned knowledge.  There are so few as crazy as myself that will peek and poke around into tiny mcu IC's in this big great world of ours. So I must fix my problems as I C them.

The real issue here is what works perfectly with one compiler doesn't make the same sense to another, and I didn't have a problem with syntax until I switched!

I still can't understand the reasoning for standardizing ANSI-wise for strcpy() to want only to play with signed char strings!

[Jeroen3]

I still can't understand the reasoning for standardizing ANSI-wise for strcpy() to want only to play with signed char strings!

In the early ages of computers there were only 127 characters defined in ASCII. Then the füññÿ languages wanted computers as well.

You're an embedded programmer. You see char, so you use it as byte pointers.
If you don't like casting, try this: memcpy( destination, source, strlen( source ))
Memcpy accepts all types of pointers.

[nctnico]

Actually I prefer to use snprintf or a protected string copy function for strings. One of the problems with the standard string functions is that they don't check for buffer overflows (does the source fit inside the destination string?).

[SuzyC]

Hi Guys! This is an update to my goal to find a mo' better MCU than the PIC16F88x I had maxed-out in performance.

At the time of my last post I had decided on buying (4) CY8CKIT--049-42xx kits as what seemed the best choice among many.

Unfortunately, this PSOC chip is truly a POS.

Although the chip is full of promises of many functions, it is severely crippled by allowing me to choose only a max of 4  functions(UDBs).

The ADC converter only supports 8-inputs single ended at 11 bits but only offers a 1.5K input impedance, requiring buffer op-amps on each input.

I needed 4 PWM's for my MMMMM motor control. I can only get one 16-bit PWM after adding a counter and ADC and boot module.

The PSOC4 documentation for most UDB (functional blocks such as PWM ADC etc) are so very vague and poorly explained that it required hours upon hours to experiment,  trying to understand how to get these functional blocks to work.
For instance the PWM requires code to turn off and on the PWM just to set  Duty Cycle to zero, else the DCyC reverts to 100% when it should be 0, (PWM single output compare match for PWM Duty Cycle) for a simple single-output PWM.

The PSOC4 48-MHz clock does not deliver speed. A simple GPIO On--GPIO  Off takes 1.4uSec to toggle one pin. To turn on or off a pin requires a method: GPIOpinWrite(1); GPIOpinWrite(0); iinstead of a simple bitx=1;  bitx=0; using a fast one or two machine language instruction  to achieve.

The clock is +-2% to +-5% accuracy making an external clock necessary for precise timing.

But the worst surprise is the 4 UDB limit which makes the chip useless except for the most trivial of useful intent!

What now?

The 16F88x chip is buy far the champion compared to to the PSOC POS. The PIC is yet the best pick!

[nctnico]

I recently looked for a chip for a project with dual edge PWM. I ended up with the LPC11E6x series from NXP which also has a fast 12bit ADC. Maybe it's worth checking out.

[SuzyC]

nctnico: Thanks for your speedy reply an d help.

I am going to check this LPC chip out.

[dannyf]

Unfortunately, this PSOC chip is truly a POS.

Many of the issues you mentioned are in the datasheet and a thorough reading of it would have helped, before your purchase. But you were in such a favor then, ...,

As to the PIC, I use it a lot as well. It is the favorite of mine among the low-end PIC chips.

I would suggest that you go back to why you need another chip, and lay out what you need in the next chip. That should narrow down the potential candidates significantly.

Outputing a few pwm is a walk in the park for most of the modern chips.

[Spikee]

I would also like to see a upgraded psoc 4 chip. With one usb integrated (slave only is good enough), maybe a rtc and a few extra ubd's.
Even if the single quantity cost goes to 3/4 euro it would still be worth it.

Now you have to chose between a 0.86 usd part (psoc 4) or the psoc 5LP which costs ~9 usd .

[miguelvp]

Don't have a lot of time to look into things (like the performance issues) until later, because I'm at work, but as far as PWMs check out these two projects:

http://www.element14.com/community/thread/25186/l/psoc-4-pioneer-kit-community-project039--two-pwms-for-the-price-of-one
http://www.element14.com/community/message/84542/l/psoc-4-pioneer-kit-community-project059-but-wait-there-s-more-single-pwm-with-3-outputs

There might be other gems within the 100 total projects:
http://www.element14.com/community/thread/23736/l/100-projects-in-100-days

Also you can use the udb editor, I haven't investigated much on that so I have to wait until I'm off and hopefully I have time this afternoon.