Home    Bloggers    Messages    Webinars    Resources   
Tw  |  Fb  |  In  |  Rss
Paul Clarke

Why PicoBlaze? Running Blinky the LED

Paul Clarke

In an earlier column (the one before my Game of Life blog), I was looking at building the core of the PicoBlaze, but had not really done much else. So it's time to fix that and get a light-emitting diode (LED) we shall call Blinky up and running. Now, controlling a light-emitting diode (LED) might not sound like a big deal, so why is a blinking LED so important?

Getting new hardware or software up and running is best achieved by taking small steps. I once heard a software engineer say that you can write a program in a day and then spend weeks debugging it. The problem is exacerbated if you trying to bring up both the hardware and the software at the same time. If something doesn’t work, is it the hardware that's letting you down, or is it the software that's at fault?

Here we see Blinky the LED in the lower lefthand corner of the breadboard.
Here we see Blinky the LED in the lower lefthand corner of the breadboard.

The first step is to make sure that the target hardware is really working, but how can you tell you have managed to get something working for the first time? The answer is Blinky the flashing LED, which I believe is the most powerful debug tool you will ever own (I'll let you read my blog, thereby saving you from being regaled by my passion for this topic).

The point is that getting an LED to blink means a lot, because it provides a way to demonstrate that you have achieved some goal. Over the last few days, this has meant proving that (on the hardware side) I could add the required support logic in the form of an output port and its control circuitry. I've also had to assemble a PicoBlaze program, synthesize everything, and -- ultimately -- get Blinky up and running.

Next page >

Page 1 / 2 Next >
<<   <   Page 2 / 2
Max Maxfield
Max Maxfield
7/31/2012 12:05:09 PM
User Rank Blogger
Re: In support of Blinky
@Duane: Sometimes hope is the only thing that keeps me going :-)

50%
50%
Duane Benson
Duane Benson
7/31/2012 12:02:48 PM
User Rank Blogger
Re: In support of Blinky
Max - There's something to that. Getting feedback right away makes it clear that there is hope for me and my new device.

50%
50%
Duane Benson
Duane Benson
7/31/2012 11:57:05 AM
User Rank Blogger
Re: The error that gets me most often.
Hamster - "scratching my head wondering why I have no life at all..." This sounds very familiar. I think that's part of my debugging technique too.

50%
50%
Max Maxfield
Max Maxfield
7/31/2012 10:00:52 AM
User Rank Blogger
Re: The error that gets me most often.
@Ken and Hamster: These are the tips and tricks that will save other (newbie) users countless hours ... so long as they take them to heart .... in fact this is pretty much what Duane did in his latest "Discovering FPGAs" blog

50%
50%
Max Maxfield
Max Maxfield
7/31/2012 9:58:10 AM
User Rank Blogger
Re: The error that gets me most often.
@Hamster: Good advice -- especially about lighting the lEDs after initial config so at least you know you've got them plugged in the right way round, even if the rest of the circuit doesn't work...

50%
50%
Max Maxfield
Max Maxfield
7/31/2012 9:56:19 AM
User Rank Blogger
Re: In support of Blinky
@Paul and Duane: Quite apart from anything else, blinking LEDs make me feel happy ... seriously :-)

50%
50%
Paul Clarke
Paul Clarke
7/31/2012 6:30:59 AM
User Rank Blogger
Re: The error that gets me most often.
Your correct in what you say Ken and Hamster,

I've done all these things before as you have stated and it's really a good idea to follow them. I've also used a simple counter to drive Blinky also that helps prove stuff is working and connected correctly. I guess my defence is that working with a Dev board I know and trust from other projects it's easy to step over these initial hardware checks.

I also like to take a quote from the film 'Contact' where a young Eleanor is searching for contacts on a Ham radio. Her father's says "take little steps" in reference to changing frequency. It's easy to want to see the all signing up and running board and dash in, but we should take little steps in getting there.

When I was interviewed for a job once I was asked how I would power up a board for the first time, I started with visual check, check power rails without ICs fitted  at which point the interviewer smiled and said you're the first one to now just slap the power on and see what happens!

For reference, my next blog will be getting the UART to work – the next best debug tool perhaps?

50%
50%
Ken_Chapman
Ken_Chapman
7/31/2012 4:01:02 AM
User Rank Expert
Re: The error that gets me most often.
I have to say that I tend to take more steps than Paul indicated that he did on this occasion. This is All Programmable logic so we should exploit it whenever possible and taking small steps is the best way to avoid the otherwise silly issues that 'hamster' has also encountered in the past. It is one thing brining up a known good piece of hardware and having to identify what you have done silly in your design but rather more serious when bring up a brand new hardware platform for the first time and not knowing what mistakes could be present on that board.

So when possible my first 'design' is a series of straight through pin-to-pin connections. On an evaluation kit then that is switches or press buttons connected via 'wires' to LEDs. With this first step I can test that the FPGA configures and prove my pin constraints for the switches and LEDs. Just this first step has saved me from more that is first obvious such as the "Oh, that press button was active Low" and the "so now I realise that I need to enable the built-in pull-up resistor in the I/O for it to work".

My second design brings in the clock (or clocks) and I put a register in the path between the switches and LEDs. If the LEDs still follow the switches then the clock is good. Yes, this helped me notice the oscillator completely missing from the board on one occasion let alone the wrong pin assignments on more times than I care to recall!

Only then do I insert PicoBlaze to read those same switches and drive those same LEDs. Even then my first program is just an 'echo' and if that fails I try just driving fixed values out to the LEDs. As soon as possible I get the 'JTAG Loader' utility provided with PicoBlaze into my design because then I can load a new test program every 10 seconds or so which really accelerates the testing of larger features as my design grows.

100%
0%
hamster
hamster
7/30/2012 8:32:09 PM
User Rank Blogger
The error that gets me most often.
What do you do when your LED doesn't blink?

Don't do as I've done in the past, getting out the meters and scopes, then spent a while scratching my head wondering why I have no life at all...

First thing is to make sure that you have put in a 'LOC' constraint for your clock signal nailing it to the correct I/O pin. I've found that my designs work a heck of a lot better when they actually have a clock signal attached. I've fallen for this twice. 

Next thing to do is to change the project so that the LEDs are lit after inital configuration  (e.g. start the counter at all '1's). That way even without a clock you then get a sign of life...

50%
50%
Duane Benson
Duane Benson
7/30/2012 7:31:44 PM
User Rank Blogger
In support of Blinky
Paul - The LED is one of my best friends as well. It's pretty much the first thing I do when bringing up any new MCU (and now FPGA). I also tend to place them at strategic points in many of the PC boards I design. A set of four LEDs can go a long way toward debugging motor controller hardware and software. Once I have everything working, I can always leave the LEDs depopulated.

50%
50%
<<   <   Page 2 / 2
More Blogs from Paul Clarke
Now it's time to look at the memory interface that will supply the information required by our PicoBlaze 8-bit soft processor core.
We've now reached the point where we are ready to start debugging a PicoBlaze-based design using the ISim software simulation tool.
For some reason, my simulation never loads my memory with any contents. Instead, it's left containing undefined ('UUUU...') states. Can you help?
The PicoBlaze does not come with the ability to single step, set breakpoints, and monitor registers and memory, so we need a way to get around these limitations.
As opposed to rebuilding the entire design every time we "tweak" the code we wish to run on the PicoBlaze soft microcontroller core, we can simply use a JTAG tool to load our executable code directly into the FPGA's on-chip memory.
flash poll
information resources
sponsored content by Xilinx
All resources
follow us on twitter
follow Xilinx on twitter
like us on facebook
like Xilinx on facebook
All Programmable Planet     About Us     Contact Us     Help     Register     Twitter     Facebook     RSS