Group Actions
Engagement
  • Author Author: michaelwylie
  • Date Created: Date Created
  • Views 937 views
  • Likes 3 likes
  • Comments 9 comments
Related
Recommended

Trying Out the CodeBug

michaelwylie

I got a CodeBug about a month ago with the intent of cloning the game Simon. I quickly found out the device is severely limited, but very easy to use. This, of course, is the old "Ease of Use" vs "Flexibility" issue for any new device\language. In this case, it was my fault for not checking the capability before jumping in. Even though I wasn't able to create Simon, I was able to have lots of fun with the device. It is incredibly easy to use, but at times, incredibly annoying for advanced users. This is one instance where the device is targeted very well to its intended audience. That can't be stressed enough, they are doing an excellent job at meeting their target audience. My two year old son loves the device, he's always asking for the CodeBug. I can load in a simple name scrolling program and we can identify letters together.

 

To add to the code base for the device I created the basic interface to scroll across the screen with button presses. This is the classic Space Invaders scrolling spaceship type of code. With a random number generator I could add random ships attacking like a scrolling shooter. A screenshot of the code is below, but I also shared it under the name 'Moving Around'.

 

image

 

The code above makes sense if you invert the CodeBug so the buttons point downward. Pressing the B button moves the lit LED to the left and pressing the A button moves the lit LED to the right. The code wraps the lit LED around the edges. I had to practice with the pause time for the best response, which occurred at 200 ms. I also kept track of the old position so that the LED didn't flicker.

 

I'm not a fan of polling buttons; I prefer interrupts, but this is a limit of the environment provided. It would be nice if the inventors could include a random number generator that can generate a random number between two limits. For example, generate a random number between 0 and 4 which could be used to light a random LED on the screen.

  • in reply to johnbeetem

    It's impossible at all. You should hack the stuff and setup a local compiler. But this is not the goal. This device is so poor ...

  • in reply to johnbeetem

    I've searched around some forums and that doesn't seem to be an option yet.

  • in reply to michaelwylie

    Michael Wylie wrote:

     

    Shabaz has explained it quite well. Simon should generate a random sequence. The best I could do is generate a pseudo random sequence in the CodeBug. Also, storing the sequence values would be difficult, since CodeBug has no array functionality.

    I see.  It's like when I had to program stacks and trees in early-1970s BASIC on my high school's computer versus programming in the far more versatile and eloquent PDP-11 assembly language.

     

    Can you bypass CodeBug's pretty graphical programming language and just use C?

  • in reply to johnbeetem

    Shabaz has explained it quite well. Simon should generate a random sequence. The best I could do is generate a pseudo random sequence in the CodeBug. Also, storing the sequence values would be difficult, since CodeBug has no array functionality.

  • in reply to johnbeetem

    Hi John!

     

    The best way to equate it; sometimes we see beginner programmers in Arduino with massive main functions because they've not read the chapter on functions or arrays?

    In the case of the codebug, it is like that, except that there actually are no functions, and arrays (from memory).

     

    Basically I think the main issue is that there are minimal structures possible in the graphical language that is used : (

    As one example; it is not possible to have functions for example, so the code ends up being one massive entity with bits of functionality copied in multiple locations - it gets very complicated quickly, and opportunity for error rises exponentially.

    Also, there is no event driven capability, nor even humble interrupts, so everything needs to be in a loop, which means explosion in variables as state machines all over the place. And as soon as you want (say) to insert a bit of functionality

    then you may as well kiss it all goodbye and start from scratch because the code has become impossibly messy to manage without risk of error.

     

    In other words, codebug is great for implementing 'hello world' style programs, but once you start wanting to go further it is exceedingly hard to use for anything much beyond that.

    It's definitely feasible in theory to do slightly-non-trivial stuff, for instance I wrote a BCD clock program but that was tiresome enough : (

    With asynchronous events from buttons, the loop structure would be messier, but presumably still feasible.


    I wish we could ask the creator of the codebug to implement our ideas such as these (which would take 20 minutes in front of a PC) - see how long it takes him : )

    Maybe the answer from him would be that little kids won't want to implement things on the level of a clock or Simon - but I disagree with that assumption that little kids won't want to do things on that level, or see them being done

    by their teachers. If I were a kid I'd certainly want ideas to inspire me further, and seeing a real clock or a game implemented would interest me.