ATmega32U4 with timing sensitive application and USB

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

 

Hi all,

 

I am looking into using an ATmega32U4 for converting a timing sensitive protocol to USB, essentially being a slave to an old traditional bidirectional parallell bus with RD and WR strobes.

I have used 32U4s with Arduino, but in this case I believe I should build the firmware from C for better control (I don't know enough about what the Arduino stuff does that could possibly upset the timing), and I have not done that before. I would be really helped by some advice from this community.
 

It needs to respond within a microsecond or so to changes in RD and WR strobe lines during transactions on the parallell bus, for example to tristate the outputs when RD goes inactive, and the transactions can last for 10-20 ms or so.

One idea is to use Pin Change Interrupts with the strobes, and do bit banging in those.
But for this to work with microsecond latency, it must respond to the interrupts within a few (16) instructions, so there can be no other interrupts enabled, at least not any with a handler that doesn't immediately enable interrupts again.

Will the USB interface work without interrupts enabled?
Would it be better to use LUFA or the Atmel USB library for this?
 

Would I be better off with another controller?

 

Thanks a lot for all input,
/ragge
 

Last Edited: Fri. Jan 14, 2022 - 09:20 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Welcome to AVRFreaks!

 

 I have no experience with the USB, so can't help there, but I would use the INTn pins rather then the PCINTn pins as the INTn pins have priority and each has its own ISR(), with the PCINT's you have to figure out which pins caused the interrupt which will take additional time.   Also IIRC with the INTn pins you can choose which edge of the pin changes will cause the interrupt, where the PCINT's will cause an interrupt in either edge direction, again more to sort out in s/w.....

 

 

Jim

 

Keys to wealth:

Invest for cash flow, not capital gains!

Wealth is attracted, not chased! 

Income is proportional to how many you serve!

If you want something you've never had...

...you must be willing to do something you've never done!

Lets go Brandon!

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

For really strict ISR latency requirements you should choose a micro with a fully prioritised interrupt controller. This means either the 16-bit PIC24 series or 32-bit SAM or PIC32 device from Microchip.

 

I dare say STM32 would also suffice for your requirements, but you shouldn't really ask about that on a Microchip forum.

 

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

 

Hi Jim,

 

Thanks, and thanks for your thoughts!

 

I​​​​n this case I thought it was a feature to have interrupts on both edges, at least for /RD:

Falling edge -> Output data on pins, and set pins as output/driving

Rising edge -> Set pins as as input/tristate

 

For /WR, one would read input ("latch") when it goes low, and there is no use for the rising edge, so I agree that it would probably be better as an INTn.
 

Thanks for the suggestion!

 

Best,

/ragge

 

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

"Dare to be naïve." - Buckminster Fuller

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

N.Winterbottom wrote:

For really strict ISR latency requirements you should choose a micro with a fully prioritised interrupt controller. This means either the 16-bit PIC24 series or 32-bit SAM or PIC32 device from Microchip.


 

Thanks for the suggestions! I'll look into those.
(I see now that the SAM D5x/E5x has a "Parallel Capture Controller" (PCC), which could possibly be used for the WR operations (except the strobe seems to be inverted), even with DMA it seems.)

 

N.Winterbottom wrote:

I dare say STM32 would also suffice for your requirements, but you shouldn't really ask about that on a Microchip forum.

 

Of course, I have now rephrased that, thanks!

Best,

/ragge

 

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

Yes, interrupt priorities may be the way to go. Thanks!

 

Best,

/ragge

 

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

ragge wrote:

It needs to respond within a microsecond or so to changes in RD and WR strobe lines during transactions on the parallell bus, for example to tristate the outputs when RD goes inactive, and the transactions can last for 10-20 ms or so.

...

Would I be better off with another controller?

 

With timing that tight, you could consider two controllers ?

Use one rather like a CPLD to manage the very tight timing, and buffer things, and deliver serial data to the USB controller.

 

What size packets and what burst speeds do you need, and what handshake system does the existing interface use  ?

 

There are also FTDI parts that have parallel bus interfaces, one of those, or one + CPLD might manage higher data rates than bit-banged sw.

 

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

Who-me wrote:
There are also FTDI parts that have parallel bus interfaces,
likewise Cypress GPIFTM (common use case is inexpensive logic analyzers)

EZ-USB™ FX2LP - Infineon Technologies

EZ-USB™ FX3 SuperSpeed USB 3.0 peripheral controller - Infineon Technologies

 

"Dare to be naïve." - Buckminster Fuller