mikroe basic - Page 1
Forum section: electronics / general

author: Simon
author_rank: Unknown
timestamp: November 06, 2011, 03:31:11 pm
content: So i use mikroe basic. But i have noticed something. If I use the PWM routines I can only get 8 bits resolution and not 10 on chips that support this (12F615 or 16F88). Now i know that for a full 10 bit resolution the chips use one 8 bit register and 2 bits of another register. if I put say 512 in as a value it goes to 100 or 0% (can't remember was a while since i noticed it). It's like the compiler runs the number round and round and gets back to the remaining value out of 255. 255 gives 100% duty 127 gives 50%.I assume at this point that if i want to use 10 bit resolution I need to write straight to the register directly and forget the PWM comands in the compiler.

author: mobbarley
author_rank: Regular Contributor
timestamp: November 08, 2011, 02:54:13 pm
content: I use MikroC and find that their routine for adjusting the PWM chews a lot of program space (or it did pre-MicroC Pro).. I often just set the registers directly - its simple enough but you lose some hardware abstraction.

author: Bored@Work
author_rank: Super Contributor
timestamp: November 08, 2011, 05:21:48 pm
content: MikroE compilers aren't known for their quality. I recommend you look at other options, even if they appear to "suck" at first sight.

author: GrumpyDave
author_rank: Contributor
timestamp: November 08, 2011, 05:28:48 pm
content: What frequency are you running the PWM at?You will probably find 10 bit PWM only works at quite low frequencys.There is usually a formula in the datasheet somewhere to calculate how many control bits you can use for a given clock frequency and prescaler etc...

author: Simon
author_rank: Unknown
timestamp: November 08, 2011, 05:49:32 pm
content: Quote from: BoredAtWork on November 08, 2011, 05:21:48 pmcan you suggest any others ? I suck at programming never mind finding the right tools.I forget the frequency but when 255 produces 100% something is wrong, if anything at 10 bits (1024) it should produce 25%, the resolution does not even come into this it is a misinterpretation by the compiler

author: FreeThinker
author_rank: Frequent Contributor
timestamp: November 08, 2011, 06:00:08 pm
content: Tryhttp://www.oshonsoft.com/and download the pic sim of your choice. It has a very nice basic and a PWM module for stepper control etc. And it's quite cheap.

author: Simon
author_rank: Unknown
timestamp: November 08, 2011, 06:18:42 pm
content: But I'm looking for a compiler not a simulator

author: FreeThinker
author_rank: Frequent Contributor
timestamp: November 08, 2011, 06:30:43 pm
content: Quote from: Simon on November 08, 2011, 06:18:42 pmIt is also a basic complier and generates hex files you can load into your pic as normal

author: Simon
author_rank: Unknown
timestamp: November 08, 2011, 06:35:54 pm
content: ah right, might take a look then, i did come across it before but thought it was a simulator only

author: gregariz
author_rank: Frequent Contributor
timestamp: November 08, 2011, 07:22:46 pm
content: Quote from: Simon on November 08, 2011, 05:49:32 pmAre you doing any math with the numbers? I like their compilers, I think they are the best documented on the market right now but I've had problems with their floating point library and I haven't been able to pinpoint what is going on. I suspect some of their routines don't clean up properly. I run their keypad, lcd and adc routines inbetween doing some simple arithmetic and find that the numbers are not adding up. Quite a few people on their forum have questioned that library, but again no-one has been able to pin down whats going on. I use CCS C quite a bit now.

author: ChrisKiwi
author_rank: Contributor
timestamp: November 09, 2011, 01:14:12 am
content: Quote from: Simon on November 08, 2011, 05:49:32 pmI have used Pic Basic, then upgraded to Pic Basic Pro when it was released seemelabs.comThere is also a forumhttp://picbasic.co.uk/forum/index.phpSome of the people there have done some really good stuff in terms of sample code and templates, particularly around time slicing and interrupts. I don't use it much these days (not for the last two years at least) as I've been working with Microchip C18. If you want to try C I'd suggest HiTech (now owned by Microchip) and this site (note the "c" on the end of microchip)www.microchipc.comwhich has a lot of code examples and FAQ's

author: Simon
author_rank: Unknown
timestamp: November 09, 2011, 06:59:36 am
content: No i was not doing any math. My code was a logical statement the result of which determined if I was going to set a higher or lower duty and I was just literally telling the software which value out of 1024 I wanted the PWM duty to be, but it would not work on a 0-1023 scale only up to 255, 255 = 100% and 511 = 100% and so on so basically the compiler was doing something funny to any value over 255 and was totaly ignoring the 10 bit capability of the PWM module. I think i may look around at other options. I'd love to learn C but I'm a bit cautious as I'm told it is more like assembly. I just want to get the job done.

author: gregariz
author_rank: Frequent Contributor
timestamp: November 09, 2011, 07:09:22 am
content: Quote from: Simon on November 09, 2011, 06:59:36 amI agree, I'm not really a C fan but these days I'll use anything that helps me get jobs done as fast as possible. My biggest gripe with most compilers is the poor level of documentation, examples and tutorials.On that note...http://www.ccsinfo.com/videos/quickStart.asx

author: GrumpyDave
author_rank: Contributor
timestamp: November 09, 2011, 09:35:00 am
content: Quote from: Simon on November 08, 2011, 05:49:32 pmThen maybe you should check the frequency?Why do you think it is the compiler that is at fault? Its sounds like you have 8 bit resolution PWM to me, load 255 into the PWM at 8 bit resolution and you will get 100% (ish).

author: Simon
author_rank: Unknown
timestamp: November 09, 2011, 12:36:11 pm
content: why don't you re-read my post and understand it, what you refer to is a different issue. I am telling the compiler to do one thing and it is doing something else.if I was running at two high a frequency i would get about the right duty rounded to the nearest bit. What is happening here is that the compiler is subtracting 256 from the value if over 255 until it gets a value of 0-255 and uses that. so 256 would give me 1/255 duty. This is the compiler doing math not me.Basically the compiler is just working in 8 bits even though the PWM module is 10 bit - not very impressive. In future i will just write straight to the register.

author: GrumpyDave
author_rank: Contributor
timestamp: November 09, 2011, 01:20:38 pm
content: ok well sorry I did not understand your description properly in the OP. The behaviour of your compiler is described much better by your last post.You have confused me a little with your comment regarding the frequency though.My understanding of the PWM behaviour is that at the max bit depth modulation is at 100%, if the bit depth is lower (e.g. Higher freq) then the modulation scales?For example10 Bit, Equal or rgeater than 1024 = 100%, 512 = 50%8 bit, Equal or rgeater than 255 = 100%, 127 = 50%7 bit, Equal or rgeater than 127 = 100%, 64 = 50%Say you count up from zero with 7 bit depth once it reaches 127 thats 100% and above this just stays at 100% or am I wrong?

author: Simon
author_rank: Unknown
timestamp: November 09, 2011, 05:28:49 pm
content: Quote from: GrumpyDave on November 09, 2011, 01:20:38 pmYes the problem can be a bit difficult to understand and I probably made a better bash at explaining it in my last post. It is a problem that should not be. The maximum frequency is (Fclock/4)/bit depth. So from my understanding on a 10 bit system 1023 is 100% and 511 is 50% and so on. I think that if you try to use a frequency above the maximum the module will do it but will not do it to 10 bits but you have no control here and carry on as normal. For example there is even data of like 6.5 bit depth. I am uncertain how it all works but at the frequencies i was using there would have been no problem with 10 bit depth and 255 should be 25% not 100. I think the issue is that the compiler is not considering the other 2 bits that are in a seperate register from the main PWM duty (8bit) register. All registers are 8 bit. I think what the compiler did was subtract 256 as many times as need be to get a number that is less than 255 and then uses that.

author: Simon
author_rank: Unknown
timestamp: November 09, 2011, 05:30:34 pm
content: Quote from: AcHmed99 on November 09, 2011, 01:22:10 pmYes i posted it on there, when the topic was finally approved after days it got no replies and that was over 2 weeks ago.

author: FreeThinker
author_rank: Frequent Contributor
timestamp: November 10, 2011, 09:20:48 am
content: Hmm! Sounds like a casting error. Did you define a variable for the speed? is it a word or a byte? Could be that the variable is not big enough to hold the value and overflows. Would cause the problem you are having but I would of thought that the compiler would have complained at run time but it could slip through.

author: ChrisKiwi
author_rank: Contributor
timestamp: November 10, 2011, 10:23:01 am
content: Quote from: Simon on November 09, 2011, 06:59:36 amNo, C is nothing like assembly. There are probably two main differences between basic (pic basic at least) and C. In basic all the variables are global, in C you decide which are local (to the functions you write) and which are global. In basic you have gosub's, in C you call functions that can (but don't have to) return values or have values passed to them. The advantage of this is that you can re use your code with out modification because any variable names in the code your reusing don't have to match the names used in your new project because only the values are passed back and forth. For example, you write a function to do an ADC conversion:voidintDoADC_Conversion(charChan,charother_parameters);{put your code here};then, to perform the conversion you would write something like:my_variable=DoADC_Conversion(Channel, any other parameters relating to the adc);So, the above line of code:1. Calls a function "DoADC_Conversion"2. Passes "Channel" and "any other parameters relating to the adc" to the function3. When the conversion is complete the result is returned and stored in "my_variable"There are other advantages in using C, such as more compact code (because you write your own functions rather than using pre-rolled functions that need to cater to many possibilities) - though Pic Basic Pro is quite efficient and things called "pointers" which can access variables in memory more efficiently.I am only scratching the surface ..... butat the end of the day it doesn't really matter what language you use as long as you get a result that works, that your happy with.OK..... are there any code tags we can use? to format code in posts?

author: Simon
author_rank: Unknown
timestamp: November 10, 2011, 12:43:04 pm
content: Quote from: FreeThinker on November 10, 2011, 09:20:48 amIt was a word variable. Actually Mikroebasic is awful at picking up errors in code or rather errors that arise from a conflict between the code and the capabilities of the processor or the code conflicting over resources

author: Unknown
author_rank: Unknown
timestamp: November 10, 2011, 04:16:28 pm
content: Language may not matter that much, at least if you compare C to one of the BASIC dialects used for embedded development, the standard BASIC (whatever that is) lacks lots of critical features like many forms of bit manipulation (did it even have a shift operator?), short circuiting logic operators, integer types with defined length (like stdint), pointers, etc. Compiler choice definitely does matter, however, and there appear to be more good C compilers around than good BASIC compilers.

author: Simon
author_rank: Unknown
timestamp: November 10, 2011, 05:16:39 pm
content: Yea i am starting to think that I should consider C. My problem with learning programming languages is that they seem to make explanations too concise and move too quickly, if I can't learn the language the usefulness of the compiler is lost on me.Any suggestions on a good, free and well documented compiler for C ? I did here tell that the micro C one is better than their micro Basic

author: Zero999
author_rank: Super Contributor
timestamp: November 10, 2011, 06:08:39 pm
content: It's probably best to follow a generic C programming tutorial before applying it to MCUs, here's a link to the one I followed before I lost interest in C.http://computer.howstuffworks.com/c.htmGCC is probably the best compiler for practising C on the PC and it has been ported to some MCUs too,

author: gregariz
author_rank: Frequent Contributor
timestamp: November 10, 2011, 06:13:18 pm
content: Quote from: Simon on November 10, 2011, 05:16:39 pmHi-Tech Chttp://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en542849

author: FreeThinker
author_rank: Frequent Contributor
timestamp: November 12, 2011, 05:27:35 pm
content: If you are prepared to move to a pic 18 chip a very good program is swordfishhttp://www.sfcompiler.co.uk/swordfish/index.htmlThe free version is only limited by the amount of ram it will program but this is large enough to program fully the smaller size pics. It went very quiet for a long time on the forum as Dave Barker the developer stopped development for a while due to work commitments but now seems to be back in harness and updating frequently. It's a nice program and has a strong forum. Limited to Pic 18xx as far as I recall.

author: Simon
author_rank: Unknown
timestamp: November 12, 2011, 05:51:02 pm
content: hm, something to consider. I hear that 18F pics can be no less expensive than the 16F series. I wonder why swordfish does not support "lower" level pics.I'm at a cross roads, i have a project based on a pic. All of the hardware is sorted but I need to study my chosen pic and write the software.If swardfish is that good at abstracting the hardware i guess that I can stop studying my pic inside out as the plan was to learn about the registers so that I could use crappy mikroe basic and control registers myself instead of letting the compiler screw it up for me.

author: Unknown
author_rank: Unknown
timestamp: November 12, 2011, 05:56:56 pm
content: I'm not sure if abstracting the hardware is feasible in small embedded applications, this is not a PC with a general purpose OS where overhead is quite acceptable.

author: FreeThinker
author_rank: Frequent Contributor
timestamp: November 12, 2011, 06:24:41 pm
content: Quote from: Simon on November 12, 2011, 05:51:02 pmFrom memory I think it has to do with the construction of the chip and the way memory is addressed make the lower series chips totally incompatible. I'm in a similar situation in that I have a perfectly good pic 16xx dev board that meet my needs for the moment but I'm considering getting a 18xx dev board. Note that swordfish will link into mplabs or labcentres (isis) simulators so that you can run you code in simulation mode. (IF you can get Isis to simulate correctly.....but that's another story)

author: Simon
author_rank: Unknown
timestamp: November 12, 2011, 07:07:09 pm
content: might be something to do with the memory on lower chips being "paged" ? but 18f is still 8 bit so I can't see how the memory is not paged unless it has bigger registers.swordfish does not look promissing, no intuitive at all and not much in the way of help

author: FreeThinker
author_rank: Frequent Contributor
timestamp: November 12, 2011, 07:29:59 pm
content: Quote from: Simon on November 12, 2011, 07:07:09 pmSwordfish will NOT teach you basic! but too say there is not much in the way of help is silly take look at this from the program help menuLCD LibraryModule and FilenameLCDLCD.basInterfaceSubroutines and Functionssub Cls ()sub Command (pCommand as byte)sub MoveCursor (pLine, pCol as byte)compound sub Write (WriteItem)compound sub WriteAt (pLine, pCol, WriteItem)Compile OptionsLCD_DATALCD_RSLCD_ENLCD_COMMAND_USLCD_DATA_USLCD_INIT_DELAYLCD_RWOverviewSupports Hitachi HD44780 LCD controllerCircuit DiagramExample Code// LCD...#option LCD_DATA = PORTD.4#option LCD_RS = PORTE.0#option LCD_EN = PORTE.1// import LCD library...include "LCD.bas"include "utils.bas"// refresh speed...const UpdateMS = 50// initialise bit patterns...// programmable characters are available that use codes $00 to $07.// Create the bit patterns that make up the bars in the LCD's CGRAM.// The vertical bars are made up of 8 identical bit patternsconst CGRAM(32) as byte = ($00,$00,$00,$00,$00,$00,$00,$00, // base bar$10,$10,$10,$10,$10,$10,$10,$00, // 8 x %10000 = |$14,$14,$14,$14,$14,$14,$14,$00, // 8 x %10100 = ||$15,$15,$15,$15,$15,$15,$15,$00) // 8 x %10101 = |||// output byte pRepValue times...noinline sub Rep(pValue, pRepValue as byte)dim Index as byteIndex = 0while Index < pRepValueLCD.Write(pValue)inc(Index)wendend sub// display the bar...noinline sub Bargraph(pLine, pBarValue as byte)const BASE_BAR = 0 // ASCII value of 0 bar (blank)const FULL_BAR = 3 // ASCII value of ||| barconst BAR_WIDTH = 16 // Max width in characters of barconst MAX_BAR_COUNT = BAR_WIDTH * 3 // Max bar countsdim NumberOfBars as bytedim Balance as bytedim BalanceChar as byteNumberOfBars = pBarValue / 3Balance = pBarValue mod 3MoveCursor(pLine,1)Rep(FULL_BAR,NumberOfBars)Write(Balance)Rep(BASE_BAR,BAR_WIDTH - (NumberOfBars + Min(Balance,1)))end sub// loop indexdim Index as bytedim ValueA, ValueB,FadeA, FadeB as byte// clear screen...ADCON1 = $07 // PORTE as digital (LCD)Write(CGRAM)// display the barwhile truefor Index = 0 to 48Bargraph(1,Index)Bargraph(2,48 - Index)delayms(UpdateMS)nextfor Index = 48 to 0 step -1Bargraph(1,Index)Bargraph(2,48 - Index)delayms(UpdateMS)nextInterfacesub Cls()Clears the LCD display area--------------------------------------------------------------------------------sub Command (pCommand as byte)pCommand - the command to be sent to the LCD. Valid arguments include cmdCGRAM, cmdDDRAM, cmdClear, cmdHome, cmdCursorOff, cmdCursorOn, cmdBlinkOn, cmdBlinkOff, cmdMoveLeft and cmdMoveRightIssues a command to the LCD display--------------------------------------------------------------------------------sub MoveCursor(pLine, pCol as byte)pLine - the LCD linepCol - the LCD columnMoves the LCD cursor to position co-ordinates Line, Column--------------------------------------------------------------------------------compound sub Write (WriteItem)WriteItem - a string, char, byte or byte arrayWrites a string, char, byte or byte array to the LCD display at the current cursor position.--------------------------------------------------------------------------------compound sub WriteAt (pLine, pCol, WriteItem)pLine - the LCD linepCol - the LCD columnWriteItem - a string, char, byte or byte arrayMoves the LCD cursor to position co-ordinates Line, Column and then writes a string, char, byte or byte array to the LCD display.Compile Options#option LCD_DATAThe LCD_DATA option sets the port or port pin for the LCD data bus. If a port name is given, without a pin qualifier, then the library defaults to a 8 bit data bus. Specifying a port pin will force the LCD library into 4 bit data mode. Valid pin qualifiers include 0 and 4. If the LCD_DATA option is not used, it defaults to PORTB.4--------------------------------------------------------------------------------#option LCD_RSThe LCD_RS option sets the LCD RS pin. If the LCD_RS option is not used, it defaults to PORTB.3--------------------------------------------------------------------------------#option LCD_ENThe LCD_EN option sets the LCD EN pin. If the LCD_EN option is not used, it defaults to PORTB.2--------------------------------------------------------------------------------#option LCD_COMMAND_USThe LCD_COMMAND_US option sets the delay value after a command write. Values can be ranged between 1 and 65535. If the LCD_COMMAND_US option is not used, it defaults to 2000.--------------------------------------------------------------------------------#option LCD_DATA_USThe LCD_DATA_US option sets the delay value after a data write. Values can be ranged between 1 and 255. If the LCD_DATA_US option is not used, it defaults to 50.--------------------------------------------------------------------------------#option LCD_INIT_DELAYThe LCD_INIT_DELAY option sets the delay (ms) before the module is initialised. Values can be ranged between 0 and 1000. If LCD_INIT_DELAY option is not used, it defaults to 100.--------------------------------------------------------------------------------#option LCD_RWThe LCD_RW is used to defince an optional device busy flag, rather than using fixed delaysAnd that's just one Module And the source code is available!! Just how much help do you need?Plus of course there is the downloadable docs and the user forum.?

author: Simon
author_rank: Unknown
timestamp: November 12, 2011, 07:38:56 pm
content: yea I was just wondering simply how to choose my pic, or is everything done in code ? I'll do some digging later

author: FreeThinker
author_rank: Frequent Contributor
timestamp: November 12, 2011, 08:13:57 pm
content: Quote from: Simon on November 12, 2011, 07:38:56 pmCheck out the samples file for some good info.The PIC is set by a simple Device statement// if device and clock are omitted, then the compiler defaults to// 18F452 @ 20MHz - they are just used here for clarity...Device = 18f452Clock = 20I think ALL the 18fxx series up to 18 pins will run without limitation as they only have limited ram on board (note this is NOT programming memory but on board RAM for variables etc)

author: mobbarley
author_rank: Regular Contributor
timestamp: November 13, 2011, 11:20:31 am
content: I am not sure if this answers your question because I have only ever used MikroC -MC provides the function:void PWM1_Set_Duty(unsigned short duty_ratio);As the input to the function is a short it only supports 0-255 / 8bit.To get 10bit you need to set the registers manually - Bruno's generator is really handy:http://www.micro-examples.com/public/microex-navig/doc/097-pwm-calculator.html

author: Simon
author_rank: Unknown
timestamp: November 13, 2011, 12:18:13 pm
content: well to be honest that is crap on mikroe's part and I will avoid all of their compilers from now on. what is the point of a compiler that limits the functionality of the pic, surely the objective of having a compiler for a higher level language is to bring those functions closer to the programmer unlike with assembler but if it does it half heartedly and I have to bear in mind limitations it is a waste of time.They never did answer my question on the forum either. I guess answering me would have revealed too much of their inadequacy

author: ChrisKiwi
author_rank: Contributor
timestamp: November 14, 2011, 12:27:36 am
content: Quote from: Simon on November 13, 2011, 12:18:13 pmThis is another advantage of C, you write your own functions, so there is no limitation to functionality except for the PIC it's self and your own skill level. Of course this implies that the learning cure is a bit steeper than Basic, which is true, however there are many forums and other sources of "help" online. C probably brings the functionality closer to the programmer than any form of Basic for this very reason. With Basic you have to conform to another persons way of doing things (the person that wrote the function), with C you are free to do as you see fit.

author: Simon
author_rank: Unknown
timestamp: November 14, 2011, 07:39:27 am
content: I think i will convert my project to a non MCU design and look at programs. I'm not looking for anything spectacular. I'm not very good at programming so want something simple but also usable.

author: GrumpyDave
author_rank: Contributor
timestamp: November 14, 2011, 11:54:06 am
content: Quote from: Simon on November 12, 2011, 07:07:09 pmYes Memory is still paged in 18F devices.the main difference is the 18F series has a larger stack and so accomodates C easier than lower series PICs.I really think you should look at C its actually quite easy to get a PIC to do stuff without using any advanced code.Either Hi-tech C or C18 there are many tutorials and examples around the net on using PIC with these compilers.Check outhttp://www.micro-examples.com/public/microex-navig/doc/097-pwm-calculator.htmlfor a code example of PIC PWM using C.

author: Zero999
author_rank: Super Contributor
timestamp: November 17, 2011, 06:15:43 pm
content: I've never used it beofre but there's the free, open source GCBASIC.http://gcbasic.sourceforge.net/

author: Simon
author_rank: Unknown
timestamp: November 17, 2011, 08:27:58 pm
content: can anyone else vouch for great cow basic ?

author: Bloch
author_rank: Unknown
timestamp: November 19, 2011, 09:49:34 am
content: Quote from: ChrisKiwi on November 14, 2011, 12:27:36 amOh that why C is god// bestPls dont spreadFUDIt is possible to write you own functions i Basic to.Let us say that Simon learn a NEW programing language you suggest C.He will now have to learn how to program in CThen he will need to learn how the particular PIC works wirh PWM (setup/options)And let us say that hi is now a master of C so there is no errors and all works.C is the best !!Or he just change his Basic program (My guess very little change is needed)Is Basic better ?In my opinion this shows exactly why you should learn ASM first, then high-level language.

author: Simon
author_rank: Unknown
timestamp: November 19, 2011, 09:51:52 am
content: well I tried ASM and nearly gave electronics up altogether. ASM is poorly documented and anyone explaining it is so far ahead that they forget how to teach someone that has no knowledge. I find basic does what I want. Those trying to say that asm is the only way are also spreading FUD

author: Bloch
author_rank: Unknown
timestamp: November 19, 2011, 10:15:20 am
content: If you like Basic then continue use that.If not then there are allot of other possibilities.I love Pascal. It is a more controlling / help make god codeQuoteI dont like C this link sums it uphttp://www.kuro5hin.org/story/2004/2/7/144019/8872Use that you like but dont change programming language just for a bad lib. in some compiler.

author: Zero999
author_rank: Super Contributor
timestamp: November 19, 2011, 11:33:02 am
content: Quote from: Simon on November 17, 2011, 08:27:58 pmIt's free so why not give it a go?Quote from: Simon on November 19, 2011, 09:51:52 amAll of the instructions are listed in the datasheet for the device you want to use.QuoteSee the tutorials linked below:http://www.gooligum.com.au/tut_baseline.htmlFailing that, I could have a go at teaching it to you, if you like?QuoteGoing by this thread BASIC isn't doing what you want.QuoteI don't think anyone has said that here.Assembly isn't the only way to go but knowing it certainly helps you understand the hardware.

author: Simon
author_rank: Unknown
timestamp: November 19, 2011, 11:59:38 am
content: well it seems that Mikroe basic is not doing what i want because it was created by people who just want to sell a product. I find it fairly easy to write basic.I think I have a slightly better grasp of how assembly works now that I start to understand the hardware and the registers.

author: FreeThinker
author_rank: Frequent Contributor
timestamp: November 20, 2011, 04:40:05 pm
content: Quote from: Simon on November 19, 2011, 11:59:38 amAssembly (on any cpu/mpu) is non intuitive and incredibly frustrating at first. It's main advantage is it's speed compactness and closeness to the hardware (no complier limitations). In C variables can be Global and seen by the whole program or local and only availible to the calling function. Why? It's simply the way the data is stored, in ram for a global but on the stack for a local. Understanding this will make your programming a lot more intuitive and pleasurable. Not to say you need to PROGRAM in Asm but a fundamental understanding of the structure of the hardware and how it moves data around will be a big plus.

author: Mechatrommer
author_rank: Super Contributor
timestamp: November 20, 2011, 06:21:40 pm
content: Quote from: FreeThinker on November 20, 2011, 04:40:05 pmits just a concept (in computer science?) and "local" only available to the "called" function.Quote from: FreeThinker on November 20, 2011, 04:40:05 pmclever compiler should store "local variables" of frequently called function(s) in ram or even in registers.

author: Unknown
author_rank: Unknown
timestamp: November 20, 2011, 06:43:12 pm
content: Regardless of the advantage of one higher level language (BASIC, Pascal) over C, the major advantage of C is that there are high-quality compilers used by lots of professionals available for almost any platform, something that's clearly not the case for BASIC.Knowledge of assembly helps with programming in higher languages, but it's quite rare to actually have to write a significant amount of assembly. Most things can be accomplished in C, unless you're desperate for the last byte of ROM or clock cycle. In my opinion, the most frequent use of assembly knowledge is while debugging, where stepping through assembly will give a more reliable view than stepping through the source code if you use an optimizing compiler, since lines of source may disappear or switch places. Not sure about the return on investment of learning assembly for a hobbyist programmer, however.

author: FreeThinker
author_rank: Frequent Contributor
timestamp: November 21, 2011, 08:30:35 am
content: Quote from: Mechatrommer on November 20, 2011, 06:21:40 pmThat would make the whole concept of C untenable. The reason local variables are 'thrown away' is so that you can write reuseable code and not worry about variable name conflicts. I'm no C expert and my explanation is probably technically flawed and of necessity, brief but the general concept holds true.

author: Mechatrommer
author_rank: Super Contributor
timestamp: November 21, 2011, 10:26:18 am
content: yes your concept holds true from high level language POV. except there's no fancy "global, local, subroutines, OOP, classing etc fancy high level language concept" at the hardware level, its all will be translated to raw opcodes, registers, ram, stack, binary manipulation etc.

author: FreeThinker
author_rank: Frequent Contributor
timestamp: November 21, 2011, 03:17:00 pm
content: Quote from: Mechatrommer on November 21, 2011, 10:26:18 amJust not true I'm afraid. True there is no machine code opcode for a local or global variable but the mechanism they work on is tied very tightly to the cpu structure. A Global variable would be an address in Ram (or Rom) would (normally) be fixed and is allocated for the at run time. A local on the other hand is never assigned an address (unless you class the stack pointer) and only exists while the function is running.A function call may pass 3 parameters a,b and c. These are pushed on to the stack along with the return address and the function called. Inside the function the parameters are popped off the stack used and finally the function exited by popping the return address into the program counter. The parameters a,b, and c STILL exist on the stack but the stack pointer is now pointing to something else ( the return address in this case) and so are invisible to the system. It is possible to manipulate the stack and indeed you do at times need to do so but it is thwart with danger and will lead to instability or crashes if not done correctly. As an aside 'Stack Fishing' was a very effective method of finding Registration numbers of software used by the reverse engineering community at one time as the reg number was pushed on the stack along side the user entered number then popped off and compared resulting in a pass fail. They then simply back tracked through the stack to get the number....Simples (Sic)!

author: DerekG
author_rank: Frequent Contributor
timestamp: April 04, 2015, 09:52:14 pm
content: Quote from: Simon on November 19, 2011, 11:59:38 amJust to revive an old thread - Simon, did you eventually go with another Basic interpreter, move to C, or did you learn assembly?