Why would you want to use C when BASIC is so much simpler...

kenjj · **Posted:** Thu Feb 25, 2010 8:19 pm

Have a quick look at this thread at AVR Freaks forum:
http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&p=458391

After reading this you'll appreciate the Studio package even more. It hides all this esoteric minutea about use of NULL, pointers, malloc, and other irrelevant [ ! ] that gets between you and programming the ATOM. Both the PIC in the ATOM and the AVRs these guys work with are small 20, 28 and 40-pin embedded processors. You'd think they were writing bloatware for Windows for their desktops with their Gigahertz clocks and GigaByte memory banks. Jeez! This is the [ ! ] the BasicMicro programmer has to deal with to arrive at a simpler compiler that lets you write simpler code to blink LEDs and drive your robot around the house. Like the job is so easy you want to saddle yourself with endless rules of syntax and [ ! ] memory allocation in a "structured" language? Eventually, if you want to program embedded parts for a living you'll have to learn to use this hairy horse manure, but 'til then: Studio, man! And it's FREE!
'Nuff said.

KurtEck · **Joined:** Tue Nov 21, 2006 9:34 am **Posts:** 502

Ken,

Personally I find this post misguided. I had a much longer response, but my session timed out and I lost it... Personally I would much rather program in C, but do very much appreciate the products by Basic Micro. I also would really rather not get into language wars.

The current version of basic has pointers and as such the concept of NULL. As for malloc, but the majority of the time on small processors I don't use it, the choice is yours. As for generating efficient code that runs on an AVR processor, C does just fine. One of the best servo controllers is the Lynxmotion SSC-32 which is written in C.

Also there are several free C compilers such as the GNU toolchain that are available. Likewise there are several free and capable IDES available for the AVR, such as WinAvr and AVR Studio.

Likewise there are a code libraries available for the AVR that make developing code for the AVRS pretty simple. One example is Webbotlib, which includes functions for: Servos (both software and hardware PWM), timers, I2c, EEPROM, LED, Motors, SPI, UARTS, switches, devices, camera, lcds, a2d... The sources for this are open source and are free. Whenever you have questions about how things work, you can look at the source code and each version of the library has an up to date PDF which describes the functions that are contained in the header files. The developer of this library is also working on a GUI app that you can choose which board you have, which devices you have and which pins it is connected to and it will generate all of the boiler plate software. Note: these tools run on Windows as well as a Mac and Unix/Linux based hosts.

Again I am not putting down the products by Basic Micro. I like them and have several of them and I spend a lot of my time developing software for them. (Hopefully soon on an Arc32). I also will continue to help out others, review documents, work on sample code, etc. However I personally think it is a mistake to underestimate the capabilities of some of the other platforms

Kurt

kenjj · **Posted:** Fri Feb 26, 2010 1:02 am

I hate that timeout thing. I've been burned more times on that...
Kurt, I posted this as much to get a rise as anything else. But, I mean really, we're talking embedded processors here. I don't need a Saturn5 to get to work, a VW bug will do. These guys are kubbitzing on the proper use of the friggin' semicolon. I don't knock C(++), or assembler, or any other language. They all have their time and place. Some troubleshooting problems call for a pricey oscilloscope, nothing less will get the job done. But I use a digital multimeter to read voltages most times because that is all most jobs call for, a quick voltage check. And I even plan to get into embedded C soon. I honest to God can't concieve of going into all this gobbledegook about whether the source code extension is a lowercase "c" or an uppercase "C" and gets saved as this, that or the other. KISS.
Your opinion may vary.
Peace is the ONLY way!

KurtEck · **Joined:** Tue Nov 21, 2006 9:34 am **Posts:** 502

Ken,
You succeeded (in getting a rise)

I will delete my post later today. Personally I think this whole post is misguided and mixing things up, but that is me.

The C compiler could care less where you put the ; or { or variable naming conventions or the like. These issues can be important if you are doing software with a group of people. It makes it easier for people to read and update your code. Note there are several tools out there to help you with this like (cb). If you only do code for your own use, you can do it any which way you want. Your comments about .c vs .C again make no difference except if for example you are running on a Unix/Linux based machine where file names are case sensitive. IF BM had a compiler that ran on UNIX you would have the same issues.

Both languages have quirks, which I don't want to get into. Both can/do crash the processor. Both can write reasonably efficient programs that run on Micro-controllers.

The real question is, what market place does BM wish to be in. If they want to be in the simple basic programs market that are robust and idiot proof and compete against Basic Stamps. Do they compete against Arduino and other ATMega based boards or ARM processors, or ... where most of code is developed in C and you have full freedom to use every feature of the board... They are trying to play the middle ground, which is great but a hard place to be. The low end processors keep getting more capable and the higher end is getting much better support libraries and the like which make it easy for beginners to work there... Personally I think they can do both! But it is up to them.

To continue to work at the lower end, they need to finish the manuals, they need to finish standardizing their languages and they need to have a complete set of regression tests to make sure everything works from build to build.

At the higher end they can do many different things, including better docs, more robustness... They already download a C compiler as part of the IDE!!! Now if only they had some reasonable support libraries, when asked I would not have to suggest other platforms for those who desire to use C!

Again to say one is a VW and other is a Saturn5 is bogus, both are free, both generate code, both have similar capabilities in the IDE...

Again this message will self destruct in...

Kurt

kenjj · **Posted:** Fri Feb 26, 2010 11:28 am

Goodness, no, leave the post in.

I visit other forums where the question of which language to use and why arises all the time. It's educational for those that follow who want some idea of what they should program in. This is our contribution. :mrgreen:

So, BMicro downloads a C in the IDE?! How's that again? Where is that hiding?
kenjj

KurtEck · **Joined:** Tue Nov 21, 2006 9:34 am **Posts:** 502

kenjj wrote:

So, BMicro downloads a C in the IDE?! How's that again? Where is that hiding?

The binaries and the like are all installed were you install studio: C:Program FilesBasicMicroBasic Micro Studioh8300-coff...
It is a version of the standard GNU tool chain, IE the same tool chain that many use on other processors including the AVR processors. There are more up to date versions of this tool chain available for the H8s from others such as KPIT Cummins. They support more recent builds of the GCC tools and libraries and includes an enhanced IDE. However for the most part I don't think you can use them as the BAP down loader is proprietary. What I have not tried doing is to try to replace all of the GNU binaries/headers/includes in the Basic Studio install with the ones installed from KPIT and see if that works....

So back to how do you use it? In Studio, you go to the file menu and select the "New Project" menu item. One of the options is to choose what type of project it is and one of the options is for a C/C++. Then you edit your code and do things like add files to the project and then you can build/Program from the IDE. Not sure if the debug button works or not...

Kurt
P.S - I forgot to put some C code in to blink an LED

Code:

//allows for printing with features, but uses more memory
#include <stdlib.h>

//WebbotLib Includes
#define UART1_TX_BUFFER_SIZE 80      // decided to have buffered IO so I set the size...
#define UART1_RX_BUFFER_SIZE 20
#define RPRINTF_COMPLEX 
#include "buffer.h"
#include "sys/axon2.h"//declare microcontroller
#include "led.h"


// hardware definitions... - was in different file
//UART defines (name your UART)
#define USB_UART UART1
#define USB_BAUD (BAUD_RATE)125000//38400
#define USB_ACTIVATE &uart1SendByte
#define GET_DATA_USB uart1GetByte()

static boolean g_fLEDOn = false;

//==============================================================================
//initialize hardware, ie servos, UART, etc.
//==============================================================================
void appInitHardware(void)
{
   delay_ms(100);//start up delay so motors don't jump

   statusLED_off();
      
   //setup UART on USB, too slow and it'll slow your entire bot down
   uartInit(USB_UART, USB_BAUD);


   rprintfInit(USB_ACTIVATE);

   rprintf("
Axon II initiated.

");

}

//==============================================================================
//   appInitSoftware - Initialize the application software.  Called after the
//             hardware has been init, but before the main appControl function
//==============================================================================
TICK_COUNT appInitSoftware(TICK_COUNT loopStart)
{
   return 0;
}

//==============================================================================
// This is the main function that is called by the main line to do all of the
//         work
//==============================================================================
TICK_COUNT appControl(LOOP_COUNT loopCount, TICK_COUNT loopStart)
{
   if (g_fLEDOn)
   {
      statusLED_off();
      g_fLEDOn = false;
   }
   else
   {
      statusLED_on();
      g_fLEDOn = true;
   }

   return 250000;   // wait a 1/4 second before we return...
}

Note: I could easily simplify some of this, but I left it pretty simple to read. This is using webbotlib and I am blinking the hardware LED. Could just as easily blink any other LED by simply creating it and say led_on(myled)...

Acidtech · **Posted:** Fri Mar 19, 2010 7:17 pm

Studio requires the COFF binary format so anything using ELF will not work. We are currently stilcking with GCC 3.X because 4.X has some compile size issues but you can use a new GCC as long as it produces a COFF binary. Also it must use the linker script for the project. If those changed or the command line arguments changed then using a different GCC may not work.

BasicMicro - Forums

Why would you want to use C when BASIC is so much simpler...

Who is online