mikroe basic

[FreeThinker]

If you are prepared to move to a pic 18 chip a very good program is swordfish http://www.sfcompiler.co.uk/swordfish/index.html The 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.

[Simon]

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.

[alm]

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.

[FreeThinker]

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.

From 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)

[Simon]

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

[FreeThinker]

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

Swordfish 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 menu

LCD Library


Module and Filename


LCD

LCD.bas
 

Interface
 Subroutines and Functions
sub Cls ()
sub Command (pCommand as byte)
sub MoveCursor (pLine, pCol as byte)
compound sub Write (WriteItem)
compound sub WriteAt (pLine, pCol, WriteItem)
 


Compile Options
 

LCD_DATA
LCD_RS
LCD_EN
LCD_COMMAND_US
LCD_DATA_US
LCD_INIT_DELAY
LCD_RW
 

Overview
Supports Hitachi HD44780 LCD controller

Circuit Diagram



Example 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 patterns 

const 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 byte

   Index = 0

   while Index < pRepValue

      LCD.Write(pValue)

      inc(Index)

   wend

end 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 ||| bar

   const BAR_WIDTH = 16                // Max width in characters of bar

   const MAX_BAR_COUNT = BAR_WIDTH * 3 // Max bar counts

 

   dim NumberOfBars as byte

   dim Balance as byte

   dim BalanceChar as byte

 

   NumberOfBars = pBarValue / 3

   Balance = pBarValue mod 3

   

   MoveCursor(pLine,1)

   Rep(FULL_BAR,NumberOfBars) 

   Write(Balance)

   Rep(BASE_BAR,BAR_WIDTH - (NumberOfBars + Min(Balance,1)))

end sub

 

// loop index

dim Index as byte

dim ValueA, ValueB,FadeA, FadeB as byte

 

// clear screen...

ADCON1 = $07 // PORTE as digital (LCD)

Write(CGRAM)

   

// display the bar

while true

   for Index = 0 to 48

      Bargraph(1,Index)

      Bargraph(2,48 - Index)

      delayms(UpdateMS)

   next

   for Index = 48 to 0 step -1

      Bargraph(1,Index)

      Bargraph(2,48 - Index)

      delayms(UpdateMS)

   next
 
 
Interface

sub 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 cmdMoveRight

Issues a command to the LCD display
 


--------------------------------------------------------------------------------


sub MoveCursor(pLine, pCol as byte)

pLine - the LCD line

pCol - the LCD column

Moves the LCD cursor to position co-ordinates Line, Column
 


--------------------------------------------------------------------------------


compound sub Write (WriteItem)

WriteItem - a string, char, byte or byte array

Writes 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 line

pCol - the LCD column

WriteItem - a string, char, byte or byte array

Moves 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_DATA


The 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_RS

 

The LCD_RS option sets the LCD RS pin. If the LCD_RS option is not used, it defaults to PORTB.3
 


--------------------------------------------------------------------------------


#option LCD_EN

 

The LCD_EN option sets the LCD EN pin. If the LCD_EN option is not used, it defaults to PORTB.2
 


--------------------------------------------------------------------------------


#option LCD_COMMAND_US

 

The 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_US

 

The 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_DELAY

 

The 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_RW

 

The LCD_RW is used to defince an optional device busy flag, rather than using fixed delays

And 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. ?

[Simon]

yea I was just wondering simply how to choose my pic, or is everything done in code  ? I'll do some digging later

[FreeThinker]

yea I was just wondering simply how to choose my pic, or is everything done in code  ? I'll do some digging later

Check 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 = 18f452
Clock = 20
I 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)

[mobbarley]

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

[Simon]

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

[ChrisKiwi]

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

This 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.

[Simon]

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.

[GrumpyDave]

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

Yes 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 out http://www.micro-examples.com/public/microex-navig/doc/097-pwm-calculator.html for a code example of PIC PWM using C.

[Zero999]

I've never used it beofre but there's the free, open source GCBASIC.
http://gcbasic.sourceforge.net/

[Simon]

can anyone else vouch for great cow basic ?

[Bloch]

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

This 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.

Oh that why C is god/ / best

Pls dont spread FUD

It 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 C

Then 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.

[Simon]

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

[Bloch]

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 code

small and efficient language intended to encourage good programming practices using structured programming and data structuring.

I dont like C this link sums it up http://www.kuro5hin.org/story/2004/2/7/144019/8872

Use that you like but dont change programming language just for a bad lib. in some compiler.

[Zero999]

can anyone else vouch for great cow basic ?

It's free so why not give it a go?

well I tried ASM and nearly gave electronics up altogether. ASM is poorly documented

All of the instructions are listed in the datasheet for the device you want to use.

and anyone explaining it is so far ahead that they forget how to teach someone that has no knowledge.

See the tutorials linked below:
http://www.gooligum.com.au/tut_baseline.html

Failing that, I could have a go at teaching it to you, if you like?

I find basic does what I want.

Going by this thread BASIC isn't doing what you want.

Those trying to say that asm is the only way are also spreading FUD

I 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.

[Simon]

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.

[FreeThinker]

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.

Assembly (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.

[Mechatrommer]

In C variables can be Global  and seen by the whole program or local and only availible to the calling function.

its just a concept (in computer science?) and "local" only available to the "called" function.

Why? It's simply the way the data is stored, in ram for a global but on the stack for a local.

clever compiler should store "local variables" of frequently called function(s) in ram or even in registers.

[alm]

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.

[FreeThinker]

In C variables can be Global  and seen by the whole program or local and only availible to the calling function.

its just a concept (in computer science?) and "local" only available to the "called" function.

Why? It's simply the way the data is stored, in ram for a global but on the stack for a local.

clever compiler should store "local variables" of frequently called function(s) in ram or even in registers.

That 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.

[Mechatrommer]

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.