Possible to drive SPI MAX7219 manually? (via breadboard)

Go To Last Post
16 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This might be a silly question, but when reading a datasheet: https://datasheets.maximintegrat... to be specific I try to do a "sample" via breadboard and NO MCU (just wires and flipping switches). So I was able to purchase a couple of those 8-segment 7 segment display modules with the MAX7219 attached:

 

They are pretty cheap and seems to be pretty popular. So I tried my hand at driving it manually (Which honestly may be impossible with SPI, I dunno?). I've been able to drive a few peripherals (Like LCD displays, something simple like outputting 1 character). But I've failed at doing this.

 

Looking at the datasheet, it seems like I should be able do this:

 

  1. Pull CS pin low
  2. Set DIN to GND
  3. Pulse CLK (going from GND to VCC +5v) 7 times
  4. Set DIN to VCC (High)
  5. Pulse CLK one more time (This should select Digit 0 according to the datasheet)
  6.  Set DIN to GND
  7. Pulse CLK 8 more times
  8. Pull CS high before I set CLK to GND one last time (Should display a 0 on Digit 0)

 

It doesn't work....and to be honest Im not really surprised because what im trying to do may not be possible based on timing. I just like to see if I can try to manually do these things. So is this impossible? is my pattern of doing it wrong or is it just not really feasible with timings/etc..

 

Thanks!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The timing won't be a problem as it's done by CLK.

 

But you didn't mention how are you switching CLK. If you are using wires or switches, you have to use some kind of debouncing. 

Computers don't make errors - What they do they do on purpose.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Those displays are so incredibly cheap!

Simply amazing.

 

Anyway, when I tinkered with one I drove it with an Arduino Nano.

Cheap hardware, complete with power supply, programming interface, by-pass caps, Xtal, etc. 

You can use SPI or you can bit-bang your own interface, and you can do it in whatever language you wish, (not just using the Arduino language).

 

The Max219 data sheet lists Minimum timing requirements for the clock pulse, but no maximums, so yo should, theoretically, be able to bit-bang your interface with switches.

 

As KIIV mentioned, however, every time you flip / push / release a switch the contacts bounce, and you actually get lots of pulses.

You could use some flip-flops to debounce the switches, or an RC, or, or, or,... but it is truly easier just to connect it to a micro to tinker with it.

 

The only difference is you use software to flip your bits instead of the physical switches themselves.

 

JC

 

 

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

KIIV_cz wrote:

The timing won't be a problem as it's done by CLK.

 

But you didn't mention how are you switching CLK. If you are using wires or switches, you have to use some kind of debouncing. 

I was using a switch to switch between ground and +5v, but yeah that's probably the problem. Since I was following the "pattern" pretty good. Although the last pulse with CS going high then low after the last data bit I was a bit confused how to do that.

 

Is there a way I could emulate CLK without it giving a bunch of random pulses? Also any suggestions on the last part of the datasheet. should CS rise BEFORE the last CLK pulse goes down or what (it's tough to tell from the datasheet).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

For a bounce free switch, the usual technique is to use a change-over switch and a rs flip flop (two nand gates).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So I guess this is a followup question regarding CLK controlled interfacing methods (like SPI).

Does the timing REALLY matter, IE could I wait even 100 seconds between CLK pulses as long as the data sent is correct? (I didn't know if these devices had some sort of "timeout" but I guess probably not).

 

Also does anyone understand on the timing diagram the last data bit where CS/LOAD then goes up and down, I can't tell if I should bring LOAD high while the last CLK is high on the last data bit, or pull it high AFTER i've pulled CLK low for the last time.

 

Also once I pull CLK low....do I keep it low? (it looks like I keep going on the timing diagram, but im not too sure)

 

also as far as debouncing, what if I have a pulldown resistor and maybe a small cap? would that help with the debounce or nah?

Last Edited: Mon. Dec 24, 2018 - 06:16 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Image result for bounce free switch circuit

 

Image from the web...

 

So, yes you can make some bounce free switches if you have some low level gate chips and a SPDT toggle switch.

 

If you have a micro you can put some push button switches on some I/O pins and use software to debounce the switches and output some clean signals on other I/O pins.

 

Or, you can just write the code to toggle your pins as desired, and let the micro "emulate" your push button switches...

 

JC

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A rc network will control the bounce, but just make sure that your switch doesn’t short the capacitor. The time constant has to exceed any bouncing.

As far as i know, there is no max time for spi, so you should be able to toggle bits at your own leisure.

With the clk at the end - you have two possibilities. If you’re patient enough to consider toggling bits manually, then exploring both possibilities shouldn’t bother you.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Mercfh wrote:
I've been able to drive a few peripherals (Like LCD displays, something simple like outputting 1 character).

 

When you did this, did you use a microcontroller, or a bunch of switches and pushbuttons?  If a microcontroller, why not simply write a small program?

 

I built a retro clock with the 7219 and a Mega88 and it worked great.  The SPI engine in the AVR is perfectly suited for this type of thing.

 

 

JIm

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jgmdesign wrote:

Mercfh wrote:
I've been able to drive a few peripherals (Like LCD displays, something simple like outputting 1 character).

 

When you did this, did you use a microcontroller, or a bunch of switches and pushbuttons?  If a microcontroller, why not simply write a small program?

 

I built a retro clock with the 7219 and a Mega88 and it worked great.  The SPI engine in the AVR is perfectly suited for this type of thing.

 

JIm

I used just switches and buttons, it was a fun learning experience. The purpose of doing it manually is for me to understand the datasheet and how the data is transferred, I don't know why but doing these things manually makes me make sure I understand the datasheet.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

TO each his own then......

 

All the best on your quest.

 

JIm

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So I managed to figure it out partly. Apparently you have to put it in normal mode (Which makes sense, but something I must've glanced over) before writing to a register and then displaying digits. I managed to display a digit however it seems no matter what I do it keeps displaying on the same location. I guess more testing is needed. progress at least!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes   It is possible to control the MAX7219 by using debounced push-switches (a 0.1uF cap [to ground, 0 volts] and 10K ohm resistor [to Vcc] will debounce the keypress).  The datasheet says that there is no maximum time between the clock and data pulse component edges.

 

But this IC was designed to be used with a microprocessor or microcontroller.  Nobody has done manual push-switch data entry into a microprocessor-based system since the days of the first home microcomputer in 1974.  The first commercial microcomputer was the Altair, which had several rows of switches on its front panel.  There was a row of switches for the 16-bit address, a row for the 8-bit data, and a row for the Intel 8080's microprocessor control signals.  

 

People spent hours flipping the switches just to blink an LED.  The program that you manually entered disappeared when the power was turned off.  By about 1977, people were cassette tape recorders to save their computer code.  One frequency was a logic zero; a different frequency was a logic one.  It could take 20 seconds or more to load a program that only a hundred bytes long.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Mercfh wrote:
I used just switches and buttons, it was a fun learning experience. The purpose of doing it manually is for me to understand the datasheet and how the data is transferred, I don't know why but doing these things manually makes me make sure I understand the datasheet.
Boy are you in for a treat:

https://hackaday.com/2012/09/24/programming-a-microcontroller-one-bit-at-a-time/

https://www.youtube.com/watch?v=UJHeDvr_doM

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I do sort of see the charm of doing this by hand with a bunch of switches on a breadboard.

Unfortunately in this way you amplify human flaws (silly mistakes, forgetfullness) and in the end you have to start all over again.

 

Are you afraid of using a uC?

Libraries for chips such as (for example) max7219 do not appear out of nothing, nor are they written in a single typing session.

They often start very similar to what you do with your manual switches, but the switches are flipped by software and a uC instead of fingers.

You could begin for example by writing some very simple functions, which just flip a single output bit, and add a delay of a few us, just to make sure you have no problems with timing.In the next operation you change a few things in the order you think the switches should be flipped, and try again with the new sequence.

On each iteration you can verifie the result with an oscilloscope / logic analyser and compare it with the datasheet.

 

And then if you've got some sensible response out of your hardware for the first time, you are very happy.

After that follow a few iterations of cleaning up and extending the software library you've just written.

The first single character written (and visible) on a HD44780 I did in this way.

Timing was very conservative, probably 10x or more slower than was stated in the datasheet.

When that worked, I wrote some loops to iterate over a string and send a whole sentence to the display.

In the meantime the code gets reviewed multiple times, timing gets improved, horrible stuff gets rewritten, commended out code gets removed etc.

 

After you've gone through this process you have a thorough understanding of how to write to your hardware, and you have also a library to use in your projects for this hardware.

While doing this, also write some comments about the errors you've made, how you corrected them and why you did use particular software constructs to solve your problems.

 

When source code is properly written, and thus also readable by human beings, it is easy to read from the source code how things are done.

Repeating in comments what is being done is a mostly silly excersise, but I see it happening all the time.

Commenting why things are done in a particular way is much more usefull.

Write the comments as how you would explain things to someone who has never seen your code before and has no clue of what it is, what pieces it consists of, nor how those pieces fit together.

Start with explaining the big picture.

 

If you've gone through this process and have a nicely written and cleaned up library you can put it on github or your own site or share it with others.

When you have been using your library for some time (months or years), you'll forget more and more details, but that's ok.

You're just changing from a library writer to a user for this particular library.

It might even be usefull to yourself if you've changed some of the comments to be compatible with doxygen, so you can extract some html as a user manual for your library.

Doing magic with a USD 7 Logic Analyser: https://www.avrfreaks.net/comment/2421756#comment-2421756

Bunch of old projects with AVR's: http://www.hoevendesign.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Paulvdh wrote:

I do sort of see the charm of doing this by hand with a bunch of switches on a breadboard.

Unfortunately in this way you amplify human flaws (silly mistakes, forgetfullness) and in the end you have to start all over again.

 

Are you afraid of using a uC?

Libraries for chips such as (for example) max7219 do not appear out of nothing, nor are they written in a single typing session.

They often start very similar to what you do with your manual switches, but the switches are flipped by software and a uC instead of fingers.

You could begin for example by writing some very simple functions, which just flip a single output bit, and add a delay of a few us, just to make sure you have no problems with timing.In the next operation you change a few things in the order you think the switches should be flipped, and try again with the new sequence.

On each iteration you can verifie the result with an oscilloscope / logic analyser and compare it with the datasheet.

 

And then if you've got some sensible response out of your hardware for the first time, you are very happy.

After that follow a few iterations of cleaning up and extending the software library you've just written.

The first single character written (and visible) on a HD44780 I did in this way.

Timing was very conservative, probably 10x or more slower than was stated in the datasheet.

When that worked, I wrote some loops to iterate over a string and send a whole sentence to the display.

In the meantime the code gets reviewed multiple times, timing gets improved, horrible stuff gets rewritten, commended out code gets removed etc.

 

After you've gone through this process you have a thorough understanding of how to write to your hardware, and you have also a library to use in your projects for this hardware.

While doing this, also write some comments about the errors you've made, how you corrected them and why you did use particular software constructs to solve your problems.

 

When source code is properly written, and thus also readable by human beings, it is easy to read from the source code how things are done.

Repeating in comments what is being done is a mostly silly excersise, but I see it happening all the time.

Commenting why things are done in a particular way is much more usefull.

Write the comments as how you would explain things to someone who has never seen your code before and has no clue of what it is, what pieces it consists of, nor how those pieces fit together.

Start with explaining the big picture.

 

If you've gone through this process and have a nicely written and cleaned up library you can put it on github or your own site or share it with others.

When you have been using your library for some time (months or years), you'll forget more and more details, but that's ok.

You're just changing from a library writer to a user for this particular library.

It might even be usefull to yourself if you've changed some of the comments to be compatible with doxygen, so you can extract some html as a user manual for your library.

Oh I have no fears about using a uC, I just like to be able to see it physically work with switches/etc... because it makes me "know" that I understand the datasheet in the "slowest" form I guess? I think it's maybe almost sort of an OCD thing in that I can make it work just with switches/etc...

 

I did the same thing with the HD44780 screen, and am now writing a library for it for my own purpose (so far so good!)