 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 : Micromite PlugIn Feature
  Page 3 of 4   |
|||||
| Author | Message | ||||
G8JCF Guru  Joined: 15/05/2014 Location: United KingdomPosts: 676 |
d = get contents of whatever a points at and then increment a then add (+) contents of whatever B points at and then increment b. The increment depends on the type of a and b, which in the code you looked at was a char, ie one byte, so a++ would increment by 1. Pointer arithmetic/manipulation is one of "darker" areas of C but the most powerful area, get it wrong and you end up really mangling memory but get it right and it's so fast/powerful. Basic doesn't really have pointers although VB does have VarPtr, and MMBasic's Peek and Poke statements when used with Poke Var A,offset,value are in fact using pointer manipulation, the Var A means the address of A (equiv to *A) and offset is then added to get to the actual memory address to be operated on. *a means using the address of variable a ++ is a post increment operator % is modulus C is a brilliant language, really good for systems programming, but I would never use it for business/text/gui stuff, it's far too low level (which of course is why it's so good for systems programming). BTW, I updated my code example to make it simpler to follow (I hope). The previous version would allow for arbitrary length unsigned integers whereas the version now in the post only allows for 32 bit integers. OK ? Peter PS here's the original C code which Phil is referring to void main_c(unsigned char *a, unsigned char *b, unsigned char *c) { unsigned int cy; unsigned int d; d=*a++ + *b++; cy=d / 0x100; *c++ = d % 0x100; d=*a++ + *b++ + cy; cy=d / 0x100; *c++ = d % 0x100; d=*a++ + *b++ + cy; cy=d / 0x100; *c++ = d % 0x100; d=*a++ + *b++ + cy; cy=d / 0x100; *c++ = d % 0x100; } The only Konstant is Change |
||||
| WhiteWizzard Guru Joined: 05/04/2013 Location: United KingdomPosts: 2927 |
So '++ is a post increment operator ' means increment then operate OR operate then increment? If the first then shouldn't it be 'increment pre operate'. Post increment operator logically means increment after operate! No wonder I'm confused 
So the increment of 'a' and 'b' are added together - correct? OR 'a' and 'b' added first and then a and b are incremented after the addition? And I assume *a actually means the contents at the address of variable 'a' rather than just the address of variable 'a'? (why would you add addresses?) I'm so glad you simplified your example to become *c=*a+*b (just like Basic  )
Now I C! WW |
||||
| mindrobots Newbie  Joined: 21/05/2014 Location: United StatesPosts: 32 |
Increment AFTER operate a = 1 b = 2 c = a++ + b++ after the last expression, c = 3, a = 2, b = 3 a = 1 b = 2 c = ++a + ++b afterwards, c = 5, a = 2, b = 3 same for decrement --i means decrement i BEFORE using it in the expression i-- means decrement i AFTER using it in the expression |
||||
Grogster Admin Group  Joined: 31/12/2012 Location: New ZealandPosts: 9502 |
I think I DID write C, but I was so drunk at the time, that I don't remember how I did it, or how to help others decipher it. 
Joking aside, I guess it is like many a language - very hard when you are new to it, but it SHOULD get easier as you continue to play around with it. Me, I'm sticking to MMBASIC - C is just a tad too much gobble-de-gook for me right now!!!  Smoke makes things work. When the smoke gets out, it stops! |
||||
| G8JCF Guru Joined: 15/05/2014 Location: United KingdomPosts: 676 |
Post increment means AFTER one has done the operation then increment, pre-increment also exists, eg ++a, but tends to be used much less often. so is correct for all practical purposes. *a does indeed mean the contents of whatever a is pointing at. eg if MMBasic placed variable A at address 0x10 then *A would mean get the contents of memory address 0x10, and if it said *A++, it would mean get the contents of Address 0x10 and then increment A to point at address 0x11. As I said pointer arithmetic is one of "darker" areas of C and indeed many if not most modern languages and language writers tend to frown upon if not positively discriminate and often outright ban Pointers as being bad/evil things, and as I said in the wrong hands, pointers can cause havoc in memory and result in core dumps/system-resets, but when it comes to messing about in the bowels of a processor/operating-system one can't get away from pointers. Pointers are often the only practicable way of passing data between incompatible environments, eg MMBasic and machine code, copying data into and out-of fixed address buffers, ie ByVal, is really time-consuming, and inefficient. Why would you add addresses ? Oh, there are a whole host of reasons why ! But jump tables, task stack frames are but a few which come to mind ! Pointers are truly wonderous things and once you get into C you will wonder how you ever managed to do without them :) !!!! @Geoff can we have Varptr please ? OK ? Peter The only Konstant is Change |
||||
bigmik Guru Joined: 20/06/2011 Location: AustraliaPosts: 2946 |
Hi John, Geoff, All, Gee this thread doubled in size after I went to bed.. Yes the firmware Geoff originally posted did bring up a message that debugging information was detected and removed (using MPlab IPE) but burned like any other `mite. I did have to do another 350 odd MB download to get an IPE that supported the MX170 chip.. I really feel there should have been a simple data file update instead of the whole shebang. However when I did the install it gave me the option of the IDE and/or the IPE so I only updated my IPE which worked seemlessly. Regards, Mick Mick's uMite Stuff can be found >>> HERE (Kindly hosted by Dontronics) <<< |
||||
Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3272 |
Peter, I know that you are familiar with ByPic Basic but, for reasons explained below, I did not want to replicate exactly what ByPic did. Plugins work a little differently in the Micromite than in ByPic Basic. In the latter the bytes are copied into a portion of RAM and then executed in RAM. In the Micromite a portion of flash is reserved for the plugin and that area is programmed when the whole program is saved. The reason why I used flash is that executing out of RAM is a real challenge for the programmer and requires position independent code. But I could not get the XC32 compiler to reliably create true position independent code (ie -fPIC does not work properly). The ByPic examples uses an earlier generation compiler running under the old MPLAB and it still has problems (which is why you had to use some special tricks in your converter). Having multiple plugins also requires position independent code. Finally, the MX170 has plenty of flash and locating the plugin into flash gives the programmer a much more stable base to work on. It is also faster. Expanding the amount of flash allocated to a plugin is not a problem. I only went for 1K initially because I figured that the plugin should only be used for small niche tasks that required speed or hardware access. I realise that creating the plugin facility could open a whole can of worms. Some people may want to test the limits and create entire subsystems with the full programming facilities of the C language and access to MMBasic, memory, the hardware, etc. But that is not possible, MMBasic is not an operating system. So I am trying to emphasise to everyone that a plugin is suitable only for small tasks that required speed or hardware access such as twiddling the I/O for your PIC32 programmer, which was the motivator for me to add a plugin facility. Your integer library is another example. Geoff Geoff Graham - http://geoffg.net |
||||
| Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3272 |
Hey, I just hit a thousand posts !! Time to break out the Champagne. Geoff Graham - http://geoffg.net |
||||
| bigmik Guru Joined: 20/06/2011 Location: AustraliaPosts: 2946 |
Keep the Champers on ice till I get there Geoff. 
Mick Mick's uMite Stuff can be found >>> HERE (Kindly hosted by Dontronics) <<< |
||||
| Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3272 |
OK, serious proposition: If ever you get over to Perth I will have a chilled bottle ready. For any European readers, that is like going from London to Athens. Geoff Geoff Graham - http://geoffg.net |
||||
TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 6224 |
Except there aren't as many wineries to go past in Oz. Jim VK7JH MMedit |
||||
panky Guru Joined: 02/10/2012 Location: AustraliaPosts: 1111 |
Geoff, you continue to amaze with the developments you release - thanks and very well done. On a wider note, if you have time (and inclination  ), could you give us all a few paragraphs on the sort of enhancements you have in mind for the future. NOT, repeat NOT in any way looking for any specific target enhancements, just your ideas for future direction.
Thanks again for a wonderful project, Doug. ... almost all of the Maximites, the MicromMites, the MM Extremes, the ArmMites, the PicoMite and loving it! |
||||
| G8JCF Guru Joined: 15/05/2014 Location: United KingdomPosts: 676 |
Hi Geoff Sorry to be a pain about plugins, but you said from the ByPIC tutorial on plugins, it says I assume that MMBasic variables are all located in RAM, and MMBasic doesn't have constants, whereas ByPIC also locates variables in RAM but can locate constants in Flash. The main problem for me is that only having 1 entry point means that one will have to create a jump/decision table/tree in the plugin which will consume precious bytes so hopefully you can increase the number of words or reconsider your decision. I hope I'm not coming across as being difficult or obtuse, I just want MMBasic to be the very best PIC32 environment possible, and a really flexible callable C capability would mean that almost nothing would then be out of bounds. Thank you for MMBasic Peter The only Konstant is Change |
||||
| Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3272 |
Sorry Peter, your input is great, my comments were intended more for general consumption. I agree that multiple plugins would be better. The issue is getting position independent code to work so I need to explore that further. Another possibility would be to scan the plugin's code and relocate it on the fly... time to pull out the MIPS manual (agghh). Geoff Geoff Graham - http://geoffg.net |
||||
| micronut Newbie Joined: 03/09/2014 Location: United StatesPosts: 37 |
I just came across this thread. Geoff thank you for all your hard work. The plugin looks exciting. Once I get back from my vacation I'll have to get back into C since my C knowledge is a little rusty . |
||||
| akashh Senior Member  Joined: 19/01/2014 Location: IndiaPosts: 115 |
Sounds cool, Goeff! I was doing a little research and came across this link: http://www.microchip.com/forums/m678400.aspx The relevant part is by GusBricker: I don't know whether you tried it but it seemed to work for him... Akash |
||||
| G8JCF Guru Joined: 15/05/2014 Location: United KingdomPosts: 676 |
@akashh The compiler switches look to be the same as those specified for ByPIC plugins see http://www.bypic.co.uk/index.php/Plugin_-_Running_C 73 Peter The only Konstant is Change |
||||
| Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3272 |
Thanks for the info. I did try the same switches and they made no difference. Probably because he was using an earlier generation compiler. Geoff Geoff Graham - http://geoffg.net |
||||
| G8JCF Guru Joined: 15/05/2014 Location: United KingdomPosts: 676 |
Hi I'm writing a MMBasic plugin for the 4 phase clock part of the uMite MMBasic programmer, and I find that it's best to have NO extra switches in MPLABX, and also no special linker script. If I use the switches, I end up sometimes with JALR instructions which break the whole position independence aspects. So without the extra switches, XC32 generates JAL and J instructions which are absolute address based of course, but when I run MMBasicPluginMaker to generate the Plugin Data statements, ALL of the JAL and J instructions are automatically converted into BAL and B instructions which are fully position independent. Since the Plugin is limited to 1K perhaps 2K or 3K in the future, there is no need for JAL/JALR/J instructions anywhere in the plugin. Anyway, apart from that, I can report that writing Plugins is great fun ! If you are using MMBasicPluginMaker be sure to click Auto-Generate so that every time you do a Build, MMBasicPluginMaker will automatically generate the main_plugin.bas file, and if you use notepad++ and have main_plugin.bas open in notepad++, then notepad++ will automatically detect that main_plugin.bas has changed and will offer to reload it leaving you with just a CTRL+A in notepad++ and then a CTRL+V in MMEdit to paste in the new Plugin Data statement. Peter The only Konstant is Change |
||||
| plasma Guru Joined: 08/04/2012 Location: GermanyPosts: 437 |
Please forgive my Ignorance but will this work on Micromite MX 150? |
||||
| Page 3 of 4 |
|||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
