I'm trying to port an existing GCB PIC project to an Arduino Uno board with an ATMega328P. I'm having trouble getting the A-D to work. Here's my code....any help appreciated:
#chip mega328p, 16
'LCD connection settings for Arduino Uno board
#define LCD_IO 4
#define LCD_DB4 PortD.4
#define LCD_DB5 PortD.5
#define LCD_DB6 PortD.6
#define LCD_DB7 PortD.7
#define LCD_RS PORTB.0
#define LCD_NO_RW
#define LCD_Enable PORTB.1
set LCD_RS OFF
'The following code fixes the erratic start-up behavior of the LCD library
'Send command "3" three times with delay
set LCD_DB4 ON
set LCD_DB5 ON
set LCD_DB6 OFF
set LCD_DB7 OFF
for xx = 1 to 3
PulseOut LCD_Enable, 5 10us
Wait 5 ms
next xx
'Set data bus width (Command "2")
set LCD_DB4 OFF
set LCD_DB5 ON
set LCD_DB6 OFF
set LCD_DB7 OFF
Wait 5 10us
PulseOut LCD_Enable, 5 10us
'***START OF PROGRAM***
cls
locate 0,0
PRINT "Program Started."
DIR portc.0 in
dim myVolts as byte
forever:
myVolts = ReadAD(ADC0)
wait 100 ms
locate 1,0
print myVolts
goto forever
Last edit: joe rocci 2014-05-01
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
From memory, the trick is to slow down the ADC with this line:
#define ADSpeed LowSpeed
Please try it, if it works then I will look at adding some conditional code to the A/D library to check the clock speed and drop the default ADC speed.
Last edit: Hugh Considine 2014-05-02
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hugh for the documentation. Help me understand the options so I can write up.
a) What does this control?
ADFormat(type) Choose Left or Right justified
b) What does the impact of these two format commands?
#define Format_Left 0
#define Format_Right 255
c) Is my assumption correct of AD_DELAY? "For correct A/D conversions, the A/D conversion clock (TAD) must be selected to ensure a minimum TAD time as possible but not less that 1.6 us" and the "Acquisition time. Can be reduced in some circumstances - see PIC manual for details"
#define AD_Delay 2 10us
d) We have three choice for Optimisation. What are the guidelines?
#define ADSpeed MediumSpeed
ADFormat was meant to provide a way to get all 10 bits of the ADC result before ReadAD10 existed. It's useless now, so best left undocumented, and could probably even be deleted. Format_Left and Format_Right are meant to be used with ADFormat, so again not needed. Left justified means 8 bits in the high byte, 2 in the low. Right justified means 2 in the high byte, and the remaining 8 in the low byte. It's only supported on PIC. (Same for ADOff.)
AD_Delay is the acquisition delay, as you guess Anobium. ADSpeed controls the source of the clock for the ADC module. It varies from one chip to another. InternalClock is a PIC only option that will drive the ADC from an internal RC oscillator.
I'm not sure exactly what the problem would be with the ADC, could you post the generated assembly please Joe? I've tried a simple program on my Duemilanove to call ReadAD and print the result over the UART, and it works fine. ReadAD(AN0) returns 0 for 0V, 170 for 3.3V and 255 for 5V. Also, do you have an official board or a clone?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hugh
The board is an official Arduino Uno (at least that's what the markings indicate). I have one of those LCD shields that multiplexes 5 buttons to ADC0 by generating different voltages depending on the button pressed. I can see with a voltmeter that the voltage on analog pin 0 is in a valid range and does change when I push buttons, but the program returns 255 no matter what the voltage is.
The .lst file is attached. I assumed that would provide more detail than the .asm.
The adc timing prescaler looks to be a little too fast. The .lst file shows the ADCSRA register bits ADPS2 and ADPS1 bits being set for a prescale of 64. So, this gives (16MHz/64) a 250KHz sample clock. The recommended is between 50-200K. Going to a 128 prescale for a 16MHz clock gives a 125KHz sample clock.
Try adding this line "SET ADPS0 On" to a-d.h in the AVR part:
#IFDEF ADSpeed LowSpeed
SET ADPS2 On
SET ADPS1 On
SET ADPS0 On
#ENDIF
Here is what I had when I was fooling with a-d on the Atmega 168. Can't remember if this was proper working code or not.
#IFDEF AVR
.DEF temp = R16
'Select channel
ADMUX = ADReadPort
'Slect AVcc voltage reference
Set REFS0 On
'Take reading
;#If DEF VAR(ADLAR)
; Set ADLAR On
;#ENDIF
'Set Prescaler to take readings between 50khz to 200khz
;#IFDEF ChipMHz >= 12
ADCSRA = 7
;#ENDIF
;#IFDEF ChipMHz >= 6 AND ChipMHZ < 12
; ADCSRA = 6
;#ENDIF
;#IFDEF ChipMHz >= 3 AND ChipMHZ < 6
; ADCSRA = 5
;#ENDIF
;#IFDEF ChipMHz >= 1 AND ChipMHZ < 3
; ADCSRA = 4
;#ENDIF
;#IFDEF ChipMHz >= .5 AND ChipMHZ < 1
; ADCSRA = 3
;#ENDIF
;#IFDEF ChipMHz >= .25 AND ChipMHZ < .5
; ADCSRA = 2
;#ENDIF
;#IFDEF ChipMHz >= .1 AND ChipMHZ < .25
; ADCSRA = 1
;#ENDIF*/
Set ADEN On
Set ADSC On
Wait While ADSC On
#ENDIF
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I added "SET ADPS0 On" to my code, but that doesn't make any difference. Even if it did, I'd expect changing the timing to affect the accuracy of the value returned, not whether it works at all.
Your example code is interesting for reference, but it doesn't help me if you don't know if it works. At this, point I need to eliminate variables, not introduce new ones.
Thanks anyway
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think I may have found the problem. The reference source (ADMUX.REFSn) bits were not being set correctly. I fixed this back in late September 2013, but somehow the fixed file didn't make it into a release. We'll sort this out soon, for now please try replacing your a-d.h file with the one at http://sourceforge.net/p/gcbasic/code/HEAD/tree/GCBASIC/trunk/include/lowlevel/a-d.h?format=raw and see if that helps!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@Joe. If you are developing for AMTEL then I strongly advise you use the HOT RELEASE.
I am packaging up a HOT RELEASE at the moment that has fixes for AMTEL and other stability issues - this is MUST have for AMTEL and anyone with more than a few variables defined.
So, advice. Get the latest HOT RELEASE and get the next one later this week.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Do you know if anyone has done any work to support AVR in the HI2C library? I wrote my own HW drivers for the PIC, but now that I'm converting to Arduino platform, I'd like to avoid re-inventing that wheel yet again if possible.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I wrote a set of low-level driver functions and some high-level calling functions specifically for the PIC18's MSSP and the SI570 chip. They could be generalized, but present functionality is limited to just what I needed in order to get/set SI570 parameters. I also have some code that calculates the SI570 RFREQ register values, completely ignoring and vastly simplifying how the data sheet says to do it using floats, instead using just integer math and longs. My intention was to finish development of my hardware/software project and then share the whole thing with the ham radio community as an example of how to use much simpler GCB to program Arduino instead of the arcane & tedious native C/C++ language. You can have a look at what I have if you wish, keeping in mind that I'm nowhere near done development and testing yet. I got to the point where I was setting/getting data from the SI570, then I decided to switch to the Arduino platform because of its availability & low-cost. That's where I'm circling now.
Joe
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2014-05-06
Hey Joe,
I don't want you to think I swiped your idea, but Nuts & Volts magazine accepted an article I wrote last month on how to program the Arduino with Great Cow Basic. I'm not sure when the article will appear, though. Just so you know we were working independently.
Thomas Henry
Last edit: Anonymous 2014-05-06
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think someone wrote a similar article in some publication a year or so ago..it might have been QST. Actually, I published a series of pages about how to use GCB with Arduino on my web site (w3jdr.com) in late 2011. My primary intention here though is to gin up some interest by the ham community in using GCB by developing a radio using commonly available modules (Arduino, SI570 boards, etc) as well as some circuits that I'm cooking up myself (mixers, crystal filters, IF stuff, etc).
No matter how it happens, I think GCB is a great development platform that needs more recognition, so I'll look forward to your article.
Joe
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Just curious why all the interest in Arduino when you can program any 8-bit PIC just as easy and many under $2 without the need for oscillator or pull-up?
Is it the shields?
I helped develop the CHIPINO to give PIC users an easy way to use shields but I often just pull the chip out for most designs and reuse the board.
So I don't see the advantage to Arduino for GCB.
I do agree that GCB should get more respect but as soon as you say BASIC, the "it's an interpreter" crowd or the "evil goto's" crowd jumps all over it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm a PIC guy and I'm basically in full agreement with your feelings, but the reality is that Arduinos are taking over the hobby movement worldwide and, by association, so is the AVR. I blame Microchip for this by not having a good hobby platform and a decent free version of their compiler at the time, but the bell is already rung. Arduino processor boards of every type and shape can be had for less than $10 and the universe of 'shields' and other hardware accessories is hard to ignore. That's why I'm embracing the Arduino platform, but I just don't think C is a friendly environment for the programming newbie hobbiest. I want to make systems that are intuitively simple and I think GCB offers that. GCB and Arduino are, for me, the perfect combination of cheap, ubiquitous hardware and good, free, easy to use software.
That's the attraction for me. You obviously have a dog in the fight, so I understand your position.
Joe
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks Joe
Let's face it, Atmel didn't really do anything for the hobbyist either except offer a free C compiler. The Arduino guys did it all. But the free compiler did help.
In my experience, cause I've been studying this Arduino phenomenon for a while, the success of Arduino is the simplified C code and the vast library of example code that resulted. The Arduino guys copied the success of the Basic Stamp. That's what made Arduino take off. It grew even bigger because professionals respect the C language and could quickly write sample code and maybe make a few bucks selling some open source shield while beginners benefitted from simple to use module with loads of free code from the professionals. So to me the simplified C (which copied what BASIC compilers have been doing for a long time) is what made Arduino take off with such a diverse audience from beginner to professional all contributing to a common platform.
GCB being able to program a PIC and AVR with the same commands is completely unique and could be the one common platform that brings the AVR and PIC people together which is why I like where it's going. But it needs lots of free sample code examples and that means more pros writing a lot more code but most can't get past the word "BASIC". So it's an uphill battle.
But we have a great small group of active people on this forum doing some amazing things so I look forward to where this goes and also what you create and share as well as Tom's article.
I'm trying to do the same from the PIC side with my GreatCowBasic.com site.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think you're right about why the success of Arduino, but it really could have been PIC & something like GCB. Consider that Arduino came out of the artist & garment segment from academics who wanted to develop "interactive art" and "wearable electronics"...hence the term "Sketches" for their programs. C is hardly the right entry vehicle for that type of folks, but back then there wasn't much available in the way of good, free, easy to use Basic software for the PIC unless you wanted to be locked into limited hardware like PICAxe and BasicStamp. Those are the ones whose success I never really understood. They're tinker toys compared to a real compiler. What our PIC hobbiest hardware world needs is for the Chinese clone makers to pick up something like your Chipino and run with it....not good for you of course.
I still think there's an avenue for GCB to gain more use and recognition. It's a much better entry vehicle for beginners, and enough power for even professional use. My company has used PicBasic Pro as a microcontroller rapid development tool for years (I introduced it), but I now believe GCB is better in several respects. We also use C and other languages for heavier lifting, but Basic is just fine for many applications.
What GCB mostly needs right now is to clean up and expand the range of application libraries and better documentation. It needs to be a complete packaged development environment that you can download, install and begin using immediately, like Arduino.
Joe
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Tom,
I believe GCB has been around almost as long as Basic Stamp. I remember using it a long time ago but I chose PICBASIC and PICBASIC PRO to start with and wrote the first book on it so we have similar backgrounds in compilers.
GCB just lacked a nice IDE and documentation like you said but the GCB@SYN solved that and the greatly improved help file and all the improved commands make it an excellent hobbyist compiler.
The CHIPINO is open source but I am debating getting the group to agree to full open source commercial use license since the idea of it was never to make money for me. I write books so I just needed a platform to build upon and it fit the shield requirement. Maybe then the chinese will pick it up. The PICkit 2 (or any PIC Programmer) requirement does turn some people off but it offers the user so much more than a bootloader.
As far as GCB being a complete package, remember its still a free compiler so if it wasn't for the contributions of Hugh and Evan (anobium) and Frank and Kent and Tom and a few others contributing their free time to the cause we'd still have a great compiler hidden in a mess of confusing files. Its come so far in a such a short time.
As far as professional use, beware that Arduino and GCB are released under GPU license which means you can use it in commercial applications but your source code has to be made public. PICBASIC PRO doesn't have that requirement and neither do a lot of the C compilers so keep that in mind.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Never intended to imply that I'd use Arduino or GCB "professionally", only that it's becoming capable enough and solid enough that it could be a contender. And you're right, Hugh, Evan, Frank, Kent Tom and others deserve a lot of credit for what it's turned into.
Even though I evaluated GCB@SYN months ago, I just began using it in earnest over the past few weeks. It looks pretty good, though I do find that it hangs up when certain compiling errors occur. It needs documentation on how to make it a 1-click compile/load process with various bootloaders....TinyBld for PIC in my case. It's nice that it ships with a version of GCB in the installation package, but it would be nicer for newbies if there was an "Update" feature that gets and installs the latest version of GCB.
These are things that makes Arduino popular; ie, it's a single download/install, it's plug & play with many versions of hardware, there are lots of examples and it's ready to go in minutes without having to figure out how the parts and pieces go together. I think a handful of enthusiastic guys could pull off something similar with GCB.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think a killer product that's right in line with GCB's PIC/AVR duality would be an Arduino compatible hardware platform that has sockets for a PIC18 family chip and another for an AVR family chip. Of course, you wouldn't use both at the same time, but the concept would seem to hold something for everyone.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Interesting conversation everyone! Just a couple of things I'd like to add.
It's perfectly ok to use GCBASIC to develop commercial products. The GPL restrictions mean that someone couldn't, say, add support for a new family of chips to the compiler and then insist on people paying for the new compiler. But if you spend a lot of time developing something, and then spend 20 seconds with the compiler, whatever is in that hex file is your work. The included libraries are under the LGPL, meaning that any improvements to the libraries should be released as open source, but any code that uses those libraries doesn't have to be.
As for PIC vs AVR, the aim of GCBASIC is to abstract away that stuff. Use whatever you can easily obtain, or whatever is most suitable for a particular project. When I started programming PICs it was with a fairly unpleasant graphical assembly language tool that made it a nightmare to change from one chip to another - even from a 16F819 to a 16F872. When someone writes code in GCBASIC, they've made an investment. It's up to me and everyone else who contributes to the compiler to preserve that investment and make sure that their code is as useful as possible in the future.
Let's see where this goes in a few years time!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm trying to port an existing GCB PIC project to an Arduino Uno board with an ATMega328P. I'm having trouble getting the A-D to work. Here's my code....any help appreciated:
#chip mega328p, 16
'LCD connection settings for Arduino Uno board
#define LCD_IO 4
#define LCD_DB4 PortD.4
#define LCD_DB5 PortD.5
#define LCD_DB6 PortD.6
#define LCD_DB7 PortD.7
#define LCD_RS PORTB.0
#define LCD_NO_RW
#define LCD_Enable PORTB.1
set LCD_RS OFF
'The following code fixes the erratic start-up behavior of the LCD library
'Send command "3" three times with delay
set LCD_DB4 ON
set LCD_DB5 ON
set LCD_DB6 OFF
set LCD_DB7 OFF
for xx = 1 to 3
PulseOut LCD_Enable, 5 10us
Wait 5 ms
next xx
'Set data bus width (Command "2")
set LCD_DB4 OFF
set LCD_DB5 ON
set LCD_DB6 OFF
set LCD_DB7 OFF
Wait 5 10us
PulseOut LCD_Enable, 5 10us
'***START OF PROGRAM***
cls
locate 0,0
PRINT "Program Started."
DIR portc.0 in
dim myVolts as byte
forever:
myVolts = ReadAD(ADC0)
wait 100 ms
locate 1,0
print myVolts
goto forever
Last edit: joe rocci 2014-05-01
From memory, the trick is to slow down the ADC with this line:
Please try it, if it works then I will look at adding some conditional code to the A/D library to check the clock speed and drop the default ADC speed.
Last edit: Hugh Considine 2014-05-02
Hugh for the documentation. Help me understand the options so I can write up.
a) What does this control?
ADFormat(type) Choose Left or Right justified
b) What does the impact of these two format commands?
#define Format_Left 0
#define Format_Right 255
c) Is my assumption correct of AD_DELAY? "For correct A/D conversions, the A/D conversion clock (TAD) must be selected to ensure a minimum TAD time as possible but not less that 1.6 us" and the "Acquisition time. Can be reduced in some circumstances - see PIC manual for details"
#define AD_Delay 2 10us
d) We have three choice for Optimisation. What are the guidelines?
#define ADSpeed MediumSpeed
#define HighSpeed 255
#define MediumSpeed 128
#define LowSpeed 0
e) What does the InternalClock value do?
#define InternalClock 192
Thank you.
Last edit: Anobium 2014-05-02
I tried "#define ADSpeed LowSpeed", but there's no change. The result is 255 no matter what the input voltage.
ADFormat was meant to provide a way to get all 10 bits of the ADC result before ReadAD10 existed. It's useless now, so best left undocumented, and could probably even be deleted. Format_Left and Format_Right are meant to be used with ADFormat, so again not needed. Left justified means 8 bits in the high byte, 2 in the low. Right justified means 2 in the high byte, and the remaining 8 in the low byte. It's only supported on PIC. (Same for ADOff.)
AD_Delay is the acquisition delay, as you guess Anobium. ADSpeed controls the source of the clock for the ADC module. It varies from one chip to another. InternalClock is a PIC only option that will drive the ADC from an internal RC oscillator.
I'm not sure exactly what the problem would be with the ADC, could you post the generated assembly please Joe? I've tried a simple program on my Duemilanove to call ReadAD and print the result over the UART, and it works fine. ReadAD(AN0) returns 0 for 0V, 170 for 3.3V and 255 for 5V. Also, do you have an official board or a clone?
Hugh
The board is an official Arduino Uno (at least that's what the markings indicate). I have one of those LCD shields that multiplexes 5 buttons to ADC0 by generating different voltages depending on the button pressed. I can see with a voltmeter that the voltage on analog pin 0 is in a valid range and does change when I push buttons, but the program returns 255 no matter what the voltage is.
The .lst file is attached. I assumed that would provide more detail than the .asm.
Joe
Just for reference, the corresponding gcb file is attached to this
Joe
The adc timing prescaler looks to be a little too fast. The .lst file shows the ADCSRA register bits ADPS2 and ADPS1 bits being set for a prescale of 64. So, this gives (16MHz/64) a 250KHz sample clock. The recommended is between 50-200K. Going to a 128 prescale for a 16MHz clock gives a 125KHz sample clock.
Try adding this line "SET ADPS0 On" to a-d.h in the AVR part:
#IFDEF ADSpeed LowSpeed SET ADPS2 On SET ADPS1 On SET ADPS0 On #ENDIFHere is what I had when I was fooling with a-d on the Atmega 168. Can't remember if this was proper working code or not.
#IFDEF AVR .DEF temp = R16 'Select channel ADMUX = ADReadPort 'Slect AVcc voltage reference Set REFS0 On 'Take reading ;#If DEF VAR(ADLAR) ; Set ADLAR On ;#ENDIF 'Set Prescaler to take readings between 50khz to 200khz ;#IFDEF ChipMHz >= 12 ADCSRA = 7 ;#ENDIF ;#IFDEF ChipMHz >= 6 AND ChipMHZ < 12 ; ADCSRA = 6 ;#ENDIF ;#IFDEF ChipMHz >= 3 AND ChipMHZ < 6 ; ADCSRA = 5 ;#ENDIF ;#IFDEF ChipMHz >= 1 AND ChipMHZ < 3 ; ADCSRA = 4 ;#ENDIF ;#IFDEF ChipMHz >= .5 AND ChipMHZ < 1 ; ADCSRA = 3 ;#ENDIF ;#IFDEF ChipMHz >= .25 AND ChipMHZ < .5 ; ADCSRA = 2 ;#ENDIF ;#IFDEF ChipMHz >= .1 AND ChipMHZ < .25 ; ADCSRA = 1 ;#ENDIF*/ Set ADEN On Set ADSC On Wait While ADSC On #ENDIFI added "SET ADPS0 On" to my code, but that doesn't make any difference. Even if it did, I'd expect changing the timing to affect the accuracy of the value returned, not whether it works at all.
Your example code is interesting for reference, but it doesn't help me if you don't know if it works. At this, point I need to eliminate variables, not introduce new ones.
Thanks anyway
I think I may have found the problem. The reference source (ADMUX.REFSn) bits were not being set correctly. I fixed this back in late September 2013, but somehow the fixed file didn't make it into a release. We'll sort this out soon, for now please try replacing your a-d.h file with the one at http://sourceforge.net/p/gcbasic/code/HEAD/tree/GCBASIC/trunk/include/lowlevel/a-d.h?format=raw and see if that helps!
That fixed it Hugh...Thanks!
Onward to the next problem now....
Joe
@Joe. If you are developing for AMTEL then I strongly advise you use the HOT RELEASE.
I am packaging up a HOT RELEASE at the moment that has fixes for AMTEL and other stability issues - this is MUST have for AMTEL and anyone with more than a few variables defined.
So, advice. Get the latest HOT RELEASE and get the next one later this week.
Thanks - will do.
Do you know if anyone has done any work to support AVR in the HI2C library? I wrote my own HW drivers for the PIC, but now that I'm converting to Arduino platform, I'd like to avoid re-inventing that wheel yet again if possible.
I have found nothing to help you for AVR.
When did you write the PIC HW drivers? Are you willing to share? I have this on my todo list - and, you could save me a lot of time.
I wrote a set of low-level driver functions and some high-level calling functions specifically for the PIC18's MSSP and the SI570 chip. They could be generalized, but present functionality is limited to just what I needed in order to get/set SI570 parameters. I also have some code that calculates the SI570 RFREQ register values, completely ignoring and vastly simplifying how the data sheet says to do it using floats, instead using just integer math and longs. My intention was to finish development of my hardware/software project and then share the whole thing with the ham radio community as an example of how to use much simpler GCB to program Arduino instead of the arcane & tedious native C/C++ language. You can have a look at what I have if you wish, keeping in mind that I'm nowhere near done development and testing yet. I got to the point where I was setting/getting data from the SI570, then I decided to switch to the Arduino platform because of its availability & low-cost. That's where I'm circling now.
Joe
Hey Joe,
I don't want you to think I swiped your idea, but Nuts & Volts magazine accepted an article I wrote last month on how to program the Arduino with Great Cow Basic. I'm not sure when the article will appear, though. Just so you know we were working independently.
Thomas Henry
Last edit: Anonymous 2014-05-06
Thomas
I think someone wrote a similar article in some publication a year or so ago..it might have been QST. Actually, I published a series of pages about how to use GCB with Arduino on my web site (w3jdr.com) in late 2011. My primary intention here though is to gin up some interest by the ham community in using GCB by developing a radio using commonly available modules (Arduino, SI570 boards, etc) as well as some circuits that I'm cooking up myself (mixers, crystal filters, IF stuff, etc).
No matter how it happens, I think GCB is a great development platform that needs more recognition, so I'll look forward to your article.
Joe
Just curious why all the interest in Arduino when you can program any 8-bit PIC just as easy and many under $2 without the need for oscillator or pull-up?
Is it the shields?
I helped develop the CHIPINO to give PIC users an easy way to use shields but I often just pull the chip out for most designs and reuse the board.
So I don't see the advantage to Arduino for GCB.
I do agree that GCB should get more respect but as soon as you say BASIC, the "it's an interpreter" crowd or the "evil goto's" crowd jumps all over it.
Chuck
I'm a PIC guy and I'm basically in full agreement with your feelings, but the reality is that Arduinos are taking over the hobby movement worldwide and, by association, so is the AVR. I blame Microchip for this by not having a good hobby platform and a decent free version of their compiler at the time, but the bell is already rung. Arduino processor boards of every type and shape can be had for less than $10 and the universe of 'shields' and other hardware accessories is hard to ignore. That's why I'm embracing the Arduino platform, but I just don't think C is a friendly environment for the programming newbie hobbiest. I want to make systems that are intuitively simple and I think GCB offers that. GCB and Arduino are, for me, the perfect combination of cheap, ubiquitous hardware and good, free, easy to use software.
That's the attraction for me. You obviously have a dog in the fight, so I understand your position.
Joe
Thanks Joe
Let's face it, Atmel didn't really do anything for the hobbyist either except offer a free C compiler. The Arduino guys did it all. But the free compiler did help.
In my experience, cause I've been studying this Arduino phenomenon for a while, the success of Arduino is the simplified C code and the vast library of example code that resulted. The Arduino guys copied the success of the Basic Stamp. That's what made Arduino take off. It grew even bigger because professionals respect the C language and could quickly write sample code and maybe make a few bucks selling some open source shield while beginners benefitted from simple to use module with loads of free code from the professionals. So to me the simplified C (which copied what BASIC compilers have been doing for a long time) is what made Arduino take off with such a diverse audience from beginner to professional all contributing to a common platform.
GCB being able to program a PIC and AVR with the same commands is completely unique and could be the one common platform that brings the AVR and PIC people together which is why I like where it's going. But it needs lots of free sample code examples and that means more pros writing a lot more code but most can't get past the word "BASIC". So it's an uphill battle.
But we have a great small group of active people on this forum doing some amazing things so I look forward to where this goes and also what you create and share as well as Tom's article.
I'm trying to do the same from the PIC side with my GreatCowBasic.com site.
Chuck
I think you're right about why the success of Arduino, but it really could have been PIC & something like GCB. Consider that Arduino came out of the artist & garment segment from academics who wanted to develop "interactive art" and "wearable electronics"...hence the term "Sketches" for their programs. C is hardly the right entry vehicle for that type of folks, but back then there wasn't much available in the way of good, free, easy to use Basic software for the PIC unless you wanted to be locked into limited hardware like PICAxe and BasicStamp. Those are the ones whose success I never really understood. They're tinker toys compared to a real compiler. What our PIC hobbiest hardware world needs is for the Chinese clone makers to pick up something like your Chipino and run with it....not good for you of course.
I still think there's an avenue for GCB to gain more use and recognition. It's a much better entry vehicle for beginners, and enough power for even professional use. My company has used PicBasic Pro as a microcontroller rapid development tool for years (I introduced it), but I now believe GCB is better in several respects. We also use C and other languages for heavier lifting, but Basic is just fine for many applications.
What GCB mostly needs right now is to clean up and expand the range of application libraries and better documentation. It needs to be a complete packaged development environment that you can download, install and begin using immediately, like Arduino.
Joe
Kind of got off topic, sorry forum readers.
Tom,
I believe GCB has been around almost as long as Basic Stamp. I remember using it a long time ago but I chose PICBASIC and PICBASIC PRO to start with and wrote the first book on it so we have similar backgrounds in compilers.
GCB just lacked a nice IDE and documentation like you said but the GCB@SYN solved that and the greatly improved help file and all the improved commands make it an excellent hobbyist compiler.
The CHIPINO is open source but I am debating getting the group to agree to full open source commercial use license since the idea of it was never to make money for me. I write books so I just needed a platform to build upon and it fit the shield requirement. Maybe then the chinese will pick it up. The PICkit 2 (or any PIC Programmer) requirement does turn some people off but it offers the user so much more than a bootloader.
As far as GCB being a complete package, remember its still a free compiler so if it wasn't for the contributions of Hugh and Evan (anobium) and Frank and Kent and Tom and a few others contributing their free time to the cause we'd still have a great compiler hidden in a mess of confusing files. Its come so far in a such a short time.
As far as professional use, beware that Arduino and GCB are released under GPU license which means you can use it in commercial applications but your source code has to be made public. PICBASIC PRO doesn't have that requirement and neither do a lot of the C compilers so keep that in mind.
Chuck
Never intended to imply that I'd use Arduino or GCB "professionally", only that it's becoming capable enough and solid enough that it could be a contender. And you're right, Hugh, Evan, Frank, Kent Tom and others deserve a lot of credit for what it's turned into.
Even though I evaluated GCB@SYN months ago, I just began using it in earnest over the past few weeks. It looks pretty good, though I do find that it hangs up when certain compiling errors occur. It needs documentation on how to make it a 1-click compile/load process with various bootloaders....TinyBld for PIC in my case. It's nice that it ships with a version of GCB in the installation package, but it would be nicer for newbies if there was an "Update" feature that gets and installs the latest version of GCB.
These are things that makes Arduino popular; ie, it's a single download/install, it's plug & play with many versions of hardware, there are lots of examples and it's ready to go in minutes without having to figure out how the parts and pieces go together. I think a handful of enthusiastic guys could pull off something similar with GCB.
and on a related note........
I think a killer product that's right in line with GCB's PIC/AVR duality would be an Arduino compatible hardware platform that has sockets for a PIC18 family chip and another for an AVR family chip. Of course, you wouldn't use both at the same time, but the concept would seem to hold something for everyone.
Interesting conversation everyone! Just a couple of things I'd like to add.
It's perfectly ok to use GCBASIC to develop commercial products. The GPL restrictions mean that someone couldn't, say, add support for a new family of chips to the compiler and then insist on people paying for the new compiler. But if you spend a lot of time developing something, and then spend 20 seconds with the compiler, whatever is in that hex file is your work. The included libraries are under the LGPL, meaning that any improvements to the libraries should be released as open source, but any code that uses those libraries doesn't have to be.
As for PIC vs AVR, the aim of GCBASIC is to abstract away that stuff. Use whatever you can easily obtain, or whatever is most suitable for a particular project. When I started programming PICs it was with a fairly unpleasant graphical assembly language tool that made it a nightmare to change from one chip to another - even from a 16F819 to a 16F872. When someone writes code in GCBASIC, they've made an investment. It's up to me and everyone else who contributes to the compiler to preserve that investment and make sure that their code is as useful as possible in the future.
Let's see where this goes in a few years time!