Chip suggestions with large number of I/O

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

Hi Guys,

 

A current project I'm working on has run into a bit of a wall.  Currently using an Atmega324PB to to service 16 encoders using PCINT (the chip has PCINT on just about all the pins) and the code works well.  However, what is needed is a board with 64 inputs with PCINT.  My original design had 2 x AVR's but it's not really practical. (ran out of pins).  I don't want to go down the expander route if at all possible and polling the inputs isn't going to cut it.

 

So..... Any chip suggestions?  Someone has suggested going down the ARM route, but that sounds like a whole new learning experience.

 

regards

 

 

 

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

The biggest AVR or Xmega is a 100 pin device. ie ATmega2560 or Xmega128A1U or maybe others.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Sounds like you need to re-think your project, divide it down into sub systems. 

Jim

 

Click Link: Get Free Stock: Retire early! PM for strategy

share.robinhood.com/jamesc3274
get $5 free gold/silver https://www.onegold.com/join/713...

 

 

 

 

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

The ATmega2560 doesn't have enough PCINTS  but the  Xmega128A1U looks interesting.  The datasheet suggests interrupts are available on all GP I/O's but I'm guessing it uses something other than PCINT.

 

regards

 

 

 

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

AVR32 UC3C0 has :

  • 144 pins (123 GPIO)
  • one GPIO interrupt group with 16 lines
  • CPU Local Bus reduces interrupt latency for 4 ports (32b) (4 of 16 lines then ISR reads a byte)
  • 5V I/O (other UC3 are 5V-tolerant on some I/O)

 

AT32UC3C064C - Microcontrollers and Processors

 

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

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

The issue is I'm interfacing to a legacy system so I'm restricted to board size.  The board I'm trying to replace used polling and it would miss detents on the encoders.

 

regards

 

 

 

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

Not what you asked for but I've used these with good results: https://lsicsi.com/products/Incremental-Encoder-Interface/LS7366R_LS7366R-S_LS7366R-TS

Letting the smoke out since 1978

 

 

 

 

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

The board I'm trying to replace used polling and it would miss detents on the encoders.

If you could poll that many encoders and it almost worked, seems to imply the encoders are moving slowly (or maybe not all at once)...perhaps you can simply beef up that software for higher performance.  Interrupts often seem like a fine idea at first, but being hit with an onslaught of unexpected edges from 16+ devices may not be so fun. 

 

My original design had 2 x AVR's but it's not really practical. (ran out of pins).

So, add another AVR...the pins have to be on some chip, regardless.   Is the space that  tight?  You could common clock them, if that is an issue  to cave on clock sources.

 

 

"encoder" is not too informative...are these volume controls, robot arm positioners, or some high speed shaft sensors?  That certainly can effect the approach.

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

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

+1
Lots of external interrupts sounds like a recipe for disaster. Identify the root cause for missing detents then address that issue. If you’re running out of cpu cycles you can look at optimising the specific code or explore options of a faster cpu.