Opinions requested: Use SPI or code with AVR?

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

First, I'm sorry but I did not have the time to search for a previous thread of this nature, but still I'd like to hear what others have to say.

Here's how I see things:

To use SPI means one must follow the SPI rules. I can't say exactly what those rules are except that I know I need:
1. A SPI CLK to clock in
2. SPI MOSI, serial data input, during the time of
3. SPI CS, which is high or low, but I don't know which is the rule,
4. in order to get SPI MISO, a serial data output from the SPI-equipped device.

That said, I can either code my own SPI or figure out (think learning curve) how to use AVR's SPI.

Which would you do and why?

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

The SPI is quite useful, and unlike the earlier USI on older devices, can be tweaked to work with almost everything. By all means use it wherever possible.

The SPI's shift register is most useful for reading and writing serial data to peripherals - doing it in code is much more troublesome. Even if you decide to use your own code for SPI, suggest you make use of the shift register at least.

If you think education is expensive, try ignorance.

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

Why would you do software SPI when you have dedicated hardware to do it for you?

Regards,
Steve A.

The Board helps those that help themselves.

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

Quote:
Why would you do software SPI when you have dedicated hardware to do it for you?

"Figuring out" means a learning curve is involved. It takes time to read the rules (SPI or AVR), understand the rules (SPI or AVR), and then choose to follow the rules (SPI or AVR).

I've never used the AVR SPI option. However, in order to successfully use it, I must follow its rules. What I'm asking, then, is is it better to learn and follow its rules, taking advantage of its existing SPI design, or understand the SPI rules and design my rules around the SPI rules and, thus, ignore AVR's SPI design in lieu of my own?

A new SPI design must be compatible with an old SPI design, not the other way around. AVR's implementation (AVR's SPI design) came after not before SPI. In short, AVR's SPI design had to follow the SPI rules in order to successfully create a SPI design, just as I would have to do in order to create a successful SPI design. The choice is (what this thread's about) do I learn the rules that AVR put in place for me to "simply" use its SPI design, or do I ignore AVR's "simple" SPI design (and accompanying learning curve, no matter how "simple") in lieu of implementing my own SPI design?

Which would you do?

Bear in mind one other detail that I accidentally left out in the launching post of this thread. This will be done in assembly whichever path I take. There will be no middle man (whose rules I'd also have to follow.) There can be machine without assembly and there can be assembly without C, but it can't go the other way around. ;-)

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

If one followed your philosophy you might as well forget microcontrollers all together and the I2C, SPI, ADC, UART, EERPOM, etc. and just bit-bang everything on GPIO pins and use external devices for things like ADC and EEPROM. In fact you'd find you had travelled back in time to the early 1980's where people were using microprocessors such as Z80 and 6502 and all the control stuff was done by external devices such as 8255's, Z80 DART, Z80 CTC etc.

The whole point of microcontrollers is that they pepper a whole bunch of useful h/w support blocks around a common core - so it would seem churlish not to use them.

So I'm with Steve, I haven't a clue why you wouldn't use the h/w SPI when it's handed to you on a plate. The problem occurs when you need two SPI simultaneously and the hardware only has one or you need three UARTs and the hardware only has two. In that case you have to consider the utter nightmare of software bit-banging the things to implement your own solution (that almost certainly will not be as "good" as the ones Atmel provides in silicon!)

Cliff

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

Added note:

That's the main selling point with me with regards to the AVR. It doesn't cater to the most common denominator (high-level language) and forget the least (machine language), the world of today. No, instead it recognizes that the world of today (high-level language, new rules) could not exist without the least common denominator (machine language.) A program is useless (cryptic words on a page) unless it runs, and it's in the running (electrons flowing) that the work (moving something that doesn't want to move) is done that actually solves the problem. AVR gets that right out of the starting gate, and this is why I can now, years later (notice my join date but lack of posts??,) pick up again near where I left off. Only this time around I'm much more in the driver's seat, which, in turn, makes AVR's initial investment in me, way back when, start paying off. ;-) Nothing is free in this world, nothing. AVR gets that. I get that. (The stock market investors... I'm sorry -- that was off task.) :shock:

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

Quote:
If one followed your philosophy you might as well forget microcontrollers all together and the I2C, SPI, ADC, UART, EERPOM, etc. and just bit-bang everything on GPIO pins and use external devices for things like ADC and EEPROM. In fact you'd find you had travelled back in time to the early 1980's where people were using microprocessors such as Z80 and 6502 and all the control stuff was done by external devices such as 8255's, Z80 DART, Z80 CTC etc.

The whole point of microcontrollers is that they pepper a whole bunch of useful h/w support blocks around a common core - so it would seem churlish not to use them.

So I'm with Steve, I haven't a clue why you wouldn't use the h/w SPI when it's handed to you on a plate. The problem occurs when you need two SPI simultaneously and the hardware only has one or you need three UARTs and the hardware only has two. In that case you have to consider the utter nightmare of software bit-banging the things to implement your own solution (that almost certainly will not be as "good" as the ones Atmel provides in silicon!)

Cliff

An excellent contribution!

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

It seems to me you'd need to know exactly how spi worked in order to bit-bang it so why not take the easier road and read the data sheet and let the hardware do the hard work.

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

You talk about AVR SPI needing to be compatible with "older" SPI in some fashion, but the same would be true of your own bit-banging SPI code, so that consideration is a wash. An SPI implementation only has to be compatible with the particular HW you want to connect to, not with every piece of hardware ever made with an SPI interface.

If you look to your career future, you'll probably have many opportunities to do SPI-type stuff. Why not learn now how to do it with the provided hardware (at least, one design's provided hardware)? It's one thing to bit-bang SPI if your uC doesn't have the hardware, but another to pay for the hardware and then not use it (and take software CPU cycles that could be used for other purposes).

I would recommend that a beginner code a bit-banged SPI interface one time to get a better understanding of what's involved, but after that one should always use the available hardware unless there is a very compelling reason not to. I can just imagine the reaction of a programmer's supervisor if that programmer bit-bangs an interface that is built in to the chip. :shock: :shock:

So, if you want to bit-bang SPI to learn how, go ahead, but if you're concerned about the learning curve (or the universality of the AVR implementation), then bite the bullet and use the hardware - it's not hard at all.

Mike

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

If the AVR's SPI implementation has any shortcomings it's that it only has a single byte FIFO. We have an application that experiences data overrun because of this, so we had to add a flow control line to throttle the incoming data. There are chips that have deeper fifos in SPI uarts.

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

Quote:
SPI uarts

An interesting oxymoron - the A in "uart" rather precludes its use with SPI.

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

clawson wrote:
Quote:
SPI uarts

An interesting oxymoron - the A in "uart" rather precludes its use with SPI.

I guess the more correct word would have been 'usart', but I don't see that used much anymore.

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

I'm hearing you all. I'm hearing many valid points. It's sounds to me like you all are seeing things the way I am. There are advantages and there are disadvantages in either route. However, I must admit, after reading what you all have said, that I left out another very important detail: I'm only concerned with one SPI device.

The question is does this change anything with any of you or do you still stand by your response thus far?

I really like this forum and the AVR. That said, I really wish I had more time to answer some questions on my own. But I know I can bit bang, and I don't know I can absorb what is necessary to use the AVR to do what I know I can do, simply because it's "easier." Yes, if the system is complex it is likely much easier. But for one SPI device??

This is a terrible comparison but how many of you consider the learning curve involved in adoption of a new version of a well-understood piece of software? I do.

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

Just realize that there are only about 8 or 10 configuration bits you need to figure out to run the AVR SPI. IMHO the "learning curve" would be measured in minutes.

Mike

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

I have evaluated both approaches (I have a time critical application and need to do the transfer as quickly as possible.

SPI rules are not at all difficult. Just read the data sheet of the peripheral and see whether it wants data on the rising or falling edge of the SPI clock, and set the polarity od the SPI clock accordingly. This approach gives you the fastest speed, up to 2 AVR system clock cycles per bit.

Bit banging using the SPI shift register is almost as quick (more work for the programmer, though).

Bit banging without using the SPI shift register really sucks. More code, more resources, and painfully slow. Read one bit from the port, check to see if it is high or low, set the corresponding bit in the save register accordingly, repeat for next bit, while keeping track of the total number of bits. Don't go there unless you have to, eg. when you need more SPI interfaces than your AVR model has.

If you think education is expensive, try ignorance.

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

Can't believe this is even a question. It took me like 3 minutes to write code to initialize and send/receive data over the SPI bus on the mega644. That was my first time using SPI so I had budgeted the next three days to troubleshoot it. Turned out to be 2.99 days quicker than I anticipated

If I had to bitbang, I'd still be working on it today.[ I imagine.

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

Quote:
The question is does this change anything with any of you or do you still stand by your response thus far?

Not unless you are a masochist who enjoys giving yourself pointless work to waste your time.

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

Ok, now I'm really hearing what I needed to hear, the reason I posted this question. Specifically I'm hearing from people who know, already (and who are willing to share that knowledge,) that the AVR SPI setup is indeed the better route, even though they could bit bang, and even if it requires digging up the information, because the information wasn't difficult to absorb and use once it was found.

Likewise, based on this advice, this is what I'll do, for I'm convinced, now, that this won't be a waste of time, such as has been the case, at least for me, in trying to navigate the guantlet that is the programming world of today, a world where it takes one megabyte of memory to print "hello world," after spending $$$ to find just the right book because "help" was too cumbersome if not useless, in order to use a decent programming package, but still not be able to say "hello world" with a non-text graphic smiley face on the screen, a task that was child's play back in the 80's, before things got sooo much better.

Thanks for saving me loads of wasted time! Now I can try to budget the time necessary.

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

I'll bet you are probably someone who pedals his car like Fred in the Flintstones because you prefer an alternative to switching the engine on? :lol:

Good luck in exploring what an engine can do for you!

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

aka...

10 HOME
20 HGR: HCOLOR=3
25 GOSUB 100
30 PRINT "HELLO WORLD"
40 END
100 REM CREATE A SMILE
105 PI = 3.14156: R = 10
110 FOR THETA = 0 to 2*PI
120 X = R*COS(THETA): Y = R*SIN(THETA)
130 XPLOT 140+X,80+Y
140 NEXT THETA

...you get the drift

CALL -151
6000: 20 60 FB
6000G
;-)

Just for grins, who here knows exactly what I just did? Hint: I just printed something at the top of the screen.

And, of course, I'll give the answer later, but I'm out of time for now. :-(

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

The AVRFreaks rock! ...but now I must go back to work.

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

Quote:
I'll bet you are probably someone who pedals his car like Fred in the Flintstones because you prefer an alternative to switching the engine on? Laughing

Good luck in exploring what an engine can do for you!

Is there an alternative to spending loads of money to create an engine such that I'd need to turn it on? Or could I build the equivalent function of the engine using a carefully constructed fundamental building block and just call upon that building block with different parameters, including one that, of course, leaves the final construction running?

The engine you advocate might break some day, simply because you can't turn the key. What a stupid reason for a car to sit on the side of the road. However, my equivalent contraption wouldn't need a key. But then I'd be considered heartless if I dared to laugh or say I told you so.

One other thing about good old Fred is he didn't need to buy gas.

In other words, laugh at what you find funny. You're right, sometimes there is a free lunch, but, from my experience, most of the time, no.

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

Now I'm waiting for someone to say I don't need to spend loads of money to create the engine, so why build an equivalent of the engine? [sigh]

No, you don't need to spend, directly, to create the engine, but you most definitely will spend, indirectly, to create the engine. Therefore, in the end, you still spent to create the engine. Hence, the real question is how much did you spend to create the engine?

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

Quote:
the AVR SPI setup is indeed the better route, even though they could bit bang,
It depends. If the micro you want to use has an SPI and the peripheral conforms to "normal" SPI rules like it has Miso, Mosi, SCK and CS then use the hardware SPI. Extremely easy to use.

spi_out:
; Start transmission of data (in temp)
	out		SPDR,temp
; Wait for transmission complete
Wait4spif:
	in		temp,SPSR
	sbrs	temp,SPIF
	rjmp	Wait4spif
	ret

Otherwise for bitbanging you can do the following.

;Shift out data in temp 8 Bits
spi_out:
	ldi		temp1,8					;8 Bits to shift out
spi_out_lp:
	cbi		clock_port,spi_clk		;Clock bit low	
	rol		temp
	brcs	A_ONE
	rjmp	a_zero					;Equalise timing	
A_ZERO:
	cbi		data_port,spi_data		;Clear data bit
	rjmp	NEXTBIT
A_ONE:
	sbi		data_port,spi_data		;Set data bit
	rjmp	NEXTBIT					;Equalise timing
NEXTBIT:
	sbi		clock_port,spi_clk 		;Clock bit high
	dec		temp1
	brne	spi_out_lp				;shifted out if ==0
	ret

I probably have more projects using some version of the bitbanged type as I use some weird chips that don't have a CS pin and the number of data bits are other than just a nice 8 bit.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Quote:
and the number of data bits are other than just a nice 8 bit.

Bingo! Thanks JS.

And I'm lacking time again, so I'll answer my just-for-fun question in this post:

When an old 80's Apple was turned on it left you at a prompt. From that prompt you could type

Quote:
CALL -151
6000: 20 60 FB
6000G

The first line called you into the Apple ROM's monitor program, which left you to enter command lines via a new "*" prompt, just to let you know you were now in the monitor program. (You just left Kansas.) Then the next line entered the machine code for "JSR $FB60" at address $6000, a free RAM area above BASIC and graphics RAM-space but below the DOS RAM-space, a safe area. The final line ran that machine code you just entered. If the code ended with RTS then you got the monitor prompt afterward. If the code ended in an intentional or unintentional error then you got a beep and a dump of the 6502 registers. (You could have gotten stuck in a loop somewhere, but usually you fell upon a BRK somewhere and caused the dump.) This code would have 1) cleared the screen, 2) on the top text line, ID'd the Apple type, and 3) then would have, likely, dumped the registers, as I did not end the one line program with RTS, while it's also doubtful the next byte would have been $60 (RTS.)

Hence, if there were any old-timey Apple II fans here amongst the AVRFreaks, they'd have surely smiled with the very short trip to yesteryear and, likely, would have said something to let me know it.

I gotta go.

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

Quote:

and the number of data bits are other than just a nice 8 bit.

Not a problem. I'm doing 32 bits at a time using SPI (in fact I'm using the SPI's poor cousin - Tiny2313's USI, so with true SPI it should be a breeze). That shift register is worth it. :D

If you think education is expensive, try ignorance.

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

Quote:
I'm doing 32 bits
I'm doing 17 bits and 35 bits in some cases.

The 35bitter chip does not have a CS pin as it is intended to be a single chip on board, I have up to 4 :shock: so I use 1 shared bit banged data line a 4 different bit banged clock lines to determine which chip I'm talking to.

I told you things can get pretty crazy... :lol:

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly