 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : CFunctions : Tutorial
Page 1 of 2   |
|||||
| Author | Message | ||||
G8JCF Guru  Joined: 15/05/2014 Location: United KingdomPosts: 676 |
Hi It's been quite a few months since the original CFunction Tutorials document was published, and some of the feedback I received was that the learning curve to create CFunctions was nonetheless very steep. In an attempt to try and help more MMBasic programmers get into creating their own CFunctions, I've embarked on a Ver 2.0 of the CFunctions Tutorials (and also a V2.0 of CFuncGen which generates CFunctions for both PIC32 and STM32 MCUs). Anyway, I would really appreciate some feedback on the "Overview" chapter of the document which attempts to assist MMBasic programmers get into C and understand pointers in particular. 2015-04-30_094418_CFunctionOverview.pdf I don't want to teach anyone how to suck eggs (as my mother used to say to us when she thought us children were being cheeky !!), on the other hand I do want to make it as understandable and as easy as possible for MMBasic programmers to get into creating their own CFunctions. Also, do people think that there needs to be a separate chapter describing in detail how to install/configure MPLAB/X + XC32 for PIC32 (and CooCox + gcc for STM32) from an MMBasic programmers perspective ? Many thanks in advance for your help Peter The only Konstant is Change |
||||
| WhiteWizzard Guru Joined: 05/04/2013 Location: United KingdomPosts: 2794 |
Hi Peter, I have just run my eyes quickly over the document - it looks 'easy' to understand. Give me a few hours and I will give a more thorough feedback. Speak soon . . . . WW For everything Micromite visit micromite.org Direct Email: whitewizzard@micromite.o |
||||
| G8JCF Guru Joined: 15/05/2014 Location: United KingdomPosts: 676 |
Thank you Phil The only Konstant is Change |
||||
Grogster Admin Group  Joined: 31/12/2012 Location: New ZealandPosts: 9063 |
Page 2, under Abstract, second last sentance, missing word - to. Reads: "Hardware and compiler specific details such as interrupts, memory models and optimization are NOT to be discussed." ...at least, that is how I expect it was supposed to read...  Smoke makes things work. When the smoke gets out, it stops! |
||||
| paceman Guru Joined: 07/10/2011 Location: AustraliaPosts: 1328 |
Hi Phil, I think this reads really well - my qualification being that I know zero about 'C'. Here are a couple of quick points though that I think could be clarified. --------------------------- The MMBasic to CFunction interface When MMBasic calls a CFunction and passes arguments through to the CFunctions, what is actually passed to the CFunction is the memory address of each argument - in BASIC parlance, By Reference. I think this statement should be followed by something like the underlined sentence below because it's not mentioned otherwise except at the end in the 'Recipe' section. MMBasic then also requires that the CFunction always returns a 64bit value - which may or may not be used by the MMBasic program. --------------------------- Line 1: long long Add(long long *a, long long *b){ Line 1: says that the function 1) Will return a 64 bit number, ie long long In the description below this you mention that the right curly bracket ends the Cfunction but then why is the left curly bracket at the end of the starting line of the CFunction, instead of at the beginning. Why is this so? --------------------------- So the recipe for writing a CFunction is as follows; 1) The function MUST return a 64 integer result, ie long long, even if that result is not used 2) The arguments to the CFunction MUST be declared as pointers, ie prefixed by * (asterisk) a. There is one exception to the * rule ! If the variable being passed is an array, eg A$, then the arguments to the function in the C code may be alternatively written as vartype varname[], where vartype is the type of the array, eg char for yte/char, long long for 64 bit integer, and varname is the symbolic name of the argument, eg MyPort, a, b, c etc. So for example char A[] declares that the CFunction expects to receive an array called A which contains byte/single character values. This last paragraph 'a' is a bit of a mouthfull without an example - as you've done in the earlier *a + *b stuff. I've read it four or five times and still not sure I've got it. ------------------------- Hope these help, Greg |
||||
| WhiteWizzard Guru Joined: 05/04/2013 Location: United KingdomPosts: 2794 |
I would take the credit for this document but think you really mean Peter!! For everything Micromite visit micromite.org Direct Email: whitewizzard@micromite.o |
||||
| paceman Guru Joined: 07/10/2011 Location: AustraliaPosts: 1328 |
Errr, dead right there Phil, sorry Peter, I even had your avatar photo in my head while I was doing that but still stuffed up. Time I went to bed - it's midnight! Greg |
||||
| G8JCF Guru Joined: 15/05/2014 Location: United KingdomPosts: 676 |
Thanks G, RU up very early or staying up very late 
The Abstract was written by MCHP, I will just drop the 'be', ie it will then read "Hardware and compiler specific details such as interrupts, memory models and optimization are NOT discussed." You've got a sharp eye for detail ! I was thinking some more, and perhaps I need to write a "C for MMBasic programmers" chapter, eg In MMBasic For/Next is For LoopVar=StartValue to EndValue Step StepValue code Next LoopVar In C the same thing would be for(LoopVar=StartValue;LoopVar<EndValue+1;LoopVar=LoopVar+StepValue){ code } Do the same for DIM, DO/WHILE etc If people thought this was a good idea it would be a fairly major undertaking, but maybe worth it. I continue to believe that MMBasic+CFunctions is a hugely approachable and productive environment hence my continuing quest to widen the circle of CFunction creators. Once again, thank you Peter The only Konstant is Change |
||||
| G8JCF Guru Joined: 15/05/2014 Location: United KingdomPosts: 676 |
Thanks P & WW I'll take om board those comments,a do a bit of a rewrite Peter The only Konstant is Change |
||||
| G8JCF Guru Joined: 15/05/2014 Location: United KingdomPosts: 676 |
Hi Greg In Block structured languages like C, the Left Curly Brace defines the start of the block and the Right Curly Brace defines the end of the block. BASIC is a halfway house, if BASIC followed the C style then a User-Defined FUnction would look like Trim(A$) Function > < > Implementation code < End Function Which doesn't read very well !! Now as to whether the Left Curly Brace should be at the end of a function declaration, eg long long MyFunction(ArgA){ or on a line by itself, eg long long MyFunction(ArgA) { has long been the subject of "style wars". Personally I like the { on the same line as the declaration, but I know that many people like the second form because it enables them to more easily match up opening and closing braces by eye. IMHO with the advent of intelligent IDEs which highlight opening and closing braces, the argument about it being easier to line up opening/closing braces is no longer relevant - some C guru is going to argue the contrary, and that argument has been going on for well over 40 years so each to their own.
Peter The only Konstant is Change |
||||
| G8JCF Guru Joined: 15/05/2014 Location: United KingdomPosts: 676 |
Hi Greg, does this make it clearer 2) The arguments to the CFunction MUST be declared as pointers, ie prefixed by * (asterisk) a. There is one exception to the * rule ! If the variable being passed is an array, eg A$, then the arguments to the function in the C code may be alternatively written as vartype varname[], where vartype is the type of the array, eg char for byte/character, long long for 64 bit integer, and varname is the symbolic name of the argument, eg MyPort, a, b, c etc. So for example long long A[] declares that the CFunction expects to receive an array called A which contains 64 bit integer values. For example here's a function which will multiply every element in a 64 bit integer array by a factor. VectorMul(long long Vector[], long long *mulfactor, long long *numelements){ int factor=*mulfactor; int count=*numelements; int i; for(i=0;i<count;i++){ Vector = Vector * factor; } } The only Konstant is Change |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9063 |
Where can I download the full Cfunctions tutorial manual? This looks like an interesting document... Smoke makes things work. When the smoke gets out, it stops! |
||||
| G8JCF Guru Joined: 15/05/2014 Location: United KingdomPosts: 676 |
Hi G Please check your PM inbox Peter The only Konstant is Change |
||||
| paceman Guru Joined: 07/10/2011 Location: AustraliaPosts: 1328 |
Hi Peter, yes it certainly does, examples are a big help. |
||||
| G8JCF Guru Joined: 15/05/2014 Location: United KingdomPosts: 676 |
Thanks Greg, I'll endeavour to put more examples in. Thanks for the feedback, very useful Peter The only Konstant is Change |
||||
| paceman Guru Joined: 07/10/2011 Location: AustraliaPosts: 1328 |
OK, and I can understand the 'style' wars, i.e. start brace at end of first line or on following line. I still don't see why the start brace isn't at the beginning of the first line, i.e. {long long MyFunction(ArgA)
Is it because the long long MyFunction(ArgA) would normally be simply part of the main code of a normal C program, and the 'start brace/code/end brace' stuff just segments what long long MyFunction(ArgA) does? e.g. could you later in a c program just say MyFunction(ArgA) and have that code run? - like an MMBasic function 
|
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 3659 |
It's a combination of C language rules. A statement can generally be a simple one or a compound - meaning more than one (er, actually one is also allowed) statement and the lot of 'em wrapped by { and } A function is defined a bit like a variable: type name but then has arguments and a compound statement, thus: type name(args) compound Any amount of white space (tabs, spaces, newlines etc) is mostly treated the same as a single space so you can put the braces (the { and }) anywhere. I don't know if the C designer (Dennis Ritchie) ever thought about allowing a non-compound statement but it would be a rather terse function even if he did and it's not much hassle to add the braces. I've taken liberties with the detailed rules in the hope of making them simpler to grasp - see the books/standards/etc for real info. John |
||||
| paceman Guru Joined: 07/10/2011 Location: AustraliaPosts: 1328 |
Part of my job was as a Committe Member then Chairman of a Standards Australia and ISO committee for about 20 years. Drafting standards and checking them has probably infiltrated my veins. I've written, checked and re-checked etc. ad nauseum for a long time! If you think it worthwhile I'd be happy to go through your drafts before you send them out. 'Word' has a pretty good system for tracking changes, edits etc and adding comments. The way it works is that the originator sends a draft Word file to the 'editor', the editor makes suggested changes and adds comments to the draft and returns it and the originator can then either use or not use the changes. Suggested deletes, additions, changes to the draft are highlighted clearly. This sequence can be extended to several 'editors' (they're highlighted differently), but doing that in parrallel creates problems in 'knowing where you're at' as you can imagine! Keeping track of version numbers is a major task of Standards authorities in the Committee stage. Well, going by the couple of examples above I'd say it's an excellent idea. Whether it's worth the time and effort required is your call - you've done a lot already. Greg |
||||
| paceman Guru Joined: 07/10/2011 Location: AustraliaPosts: 1328 |
Hi John, Hmmm.... maybe I need to download that copy of K&R, or buy one assuming they're still in print - understanding the rules and formatting is unquestionably 'basic'  . Actually a couple of years ago I invested $72  in a copy of the text Geoff recommends on his site, 'Programming 32-bit Microcontrollers in C' by Lucio Di Jasio. I started getting into it but wasn't set up at the time to run the programs on a generic PIC32 as I progressed etc., which it really required. I've certainly got all the hardware side now but all the new Maxi/MicroMite developments have well and truly diverted me - things move too fast, but but it sure stays interesting!
Greg |
||||
| G8JCF Guru Joined: 15/05/2014 Location: United KingdomPosts: 676 |
Hi Gregg Re C for MMBasic Programmers - Well if a job's worth doing then it's worth doing well ! I'll give it a go and see if I have the patience/skill/knowledge to do such a thing - I was in fact just discussing just this topic with Grogster. Chairman of Standards Australia ! Thank you for so generously offering to help me get the documents right, when I was working, Track Changes with the document circulating all over the bank was de rigueur. I'll certainly take you up on your offer. Thank you Peter The only Konstant is Change |
||||
| Page 1 of 2 |
|||||
 Print this page |
