| ??? 10/03/08 09:08 Read: times |
#158793 - Fast interrupts Responding to: ???'s previous message |
No. You do not want an interrupt to consume time. All interrupts should be as quick as possible, since the total time to enter, run, leave the interrupt handler adds up to the worst-case response time for other events.
But there are one exception that may be relevant here. If you have a situation where you must turn off all interrupts when doing the SPI communication (to remove the risk of an interrupt handler delaying your code enough to miss an SPI state change) then you might as well do the full transfer of an SPI message in the interrupt handler, and not leave until you see the slave-select line deassert. You really have to settle for one of three alternatives: - Running the SPI at a snail pace. - Letting your processor focus 100% of its capacity on SPI when a transfer is active. - Get a processor with hardware SPI support for the slave side. |
| Topic | Author | Date |
| SPI slave | 01/01/70 00:00 | |
| high speed? | 01/01/70 00:00 | |
| sory for late replay. | 01/01/70 00:00 | |
| SPI clock | 01/01/70 00:00 | |
| not sure.. | 01/01/70 00:00 | |
| the worst possible approach | 01/01/70 00:00 | |
| SPI Slave Response | 01/01/70 00:00 | |
| further explanation? | 01/01/70 00:00 | |
| Fixed speed | 01/01/70 00:00 | |
| SPI Timing Diagrams | 01/01/70 00:00 | |
| UART Mode 0 - SPI like Serial Shif register | 01/01/70 00:00 | |
| uhm | 01/01/70 00:00 | |
| to joe | 01/01/70 00:00 | |
| your point? | 01/01/70 00:00 | |
| you can't fail with software master | 01/01/70 00:00 | |
| Unanswerable! | 01/01/70 00:00 | |
| really? | 01/01/70 00:00 | |
| Intended for/usable for not always identical | 01/01/70 00:00 | |
| consideration? | 01/01/70 00:00 | |
| Some Questions | 01/01/70 00:00 | |
| whichever you choose | 01/01/70 00:00 | |
| low cost? | 01/01/70 00:00 | |
| if you do not use an interrupt | 01/01/70 00:00 | |
| polling? | 01/01/70 00:00 | |
| bits/s not packet size | 01/01/70 00:00 | |
| speed? | 01/01/70 00:00 | |
| bits/s not packet size! | 01/01/70 00:00 | |
| 500ms? | 01/01/70 00:00 | |
| here | 01/01/70 00:00 | |
| Yes - I agree | 01/01/70 00:00 | |
| issues | 01/01/70 00:00 | |
| UART! | 01/01/70 00:00 | |
| Not complex - just requiring low baudrate | 01/01/70 00:00 | |
| kind of rcorrect | 01/01/70 00:00 | |
| Complexity contra recommendable | 01/01/70 00:00 | |
| answer | 01/01/70 00:00 | |
| as i said | 01/01/70 00:00 | |
| lots of them | 01/01/70 00:00 | |
mcu with spi, right here in the thread | 01/01/70 00:00 | |
| CodeArchitect. ? | 01/01/70 00:00 | |
| no | 01/01/70 00:00 | |
| ahhh | 01/01/70 00:00 | |
| simulating SS? | 01/01/70 00:00 | |
| Interrupts are slower than tight polling | 01/01/70 00:00 | |
| wow | 01/01/70 00:00 | |
| all about worst-case | 01/01/70 00:00 | |
| thanks... | 01/01/70 00:00 | |
| missed interrupts | 01/01/70 00:00 | |
| correct me.. | 01/01/70 00:00 | |
| Fast interrupts | 01/01/70 00:00 | |
| thanks... | 01/01/70 00:00 | |
| An Alternative... | 01/01/70 00:00 | |
| Some Descriptive Information | 01/01/70 00:00 | |
| AT89LP2052 has HW SPI | 01/01/70 00:00 |