Why mod.. when you can make?

User Tools

Site Tools


blog:on_modularizing

Table of Contents

On modularizing..

On idea that keeps coming back and is tempting 'on the surface', is making things modular; back I think for zikzak r2 (or r4? I forget..), I had considered making a few smaller boards, instead of a larger one. I've been through the larger board, to minimizing number of chips, to module ideas and experimented, you see. The hardcore modular approach was to make simple cpu board, a ram board, gpu board, I/O board, etc, and then various interconnect boards that could allow 1, or 2, cpu's, and 1, or 2 RAM banks for single or double buffering, etc. Pretty intense, and.. a lot of cables, a lot of boards, a lot of $$! Scrapped that idea once it became apparent where it was going.

But now, with eZ80 being a pain for whatever reason (and breaking my little heart ;), it came to mind again; a base board for gpu and peripherals (joystick ports etc), and then a cpu pluggable board. But reviewing the notes for the earlier hardcore modular approach reminded me why I aborted it..

  1. memory bus (say, 24pin for address, 8pin for data, plus a few for control)
  2. misc control bus (vblank, maybe some i2c, spi, maybe some programming bus or do that on board itself)
  3. peripheral bus (10-16pin for joysticks, some pins for keyboard, maybe some for SDIO etc)
  4. power bus (couple of grounds, 5v, 3V, maybe more)
  5. serial ports..

You quickly end up with 5 or more cables, and some of those very large (memory being say 40 pin ribbon with a big IDC connector; maybe too big, so end up with 2*20pin?)

So, yeah, lets not do that.

No, what becomes tempting today (again, I don't get much time to think or work on this, so I spew out whatever comes to mind here; its not always a good idea ;), is to just make the base board with a default simple testable provable workable chip as CPU; then as the various buses come over to it, try to drifve them through one area and put some holes in there, where headers _may_ be soldered on as needed. So route things through one area and over to an stm32 or avr8 as cpu, and if the user wants.. they could just skip putting those in, and add in the header pins, and do a perfboard up with alternate cpu and away they go. (Or maybe I'd make some add-on modules available.)

As to selecting a good old reliable simple chip for cpu.. again back to the IC wars! STM, AVR, PIC, Zilog, .. so many options! But in the name of keeping things simple, and cheap (less programmers), etc, it does afford us ways to chip down, so I'd guess..

  1. avr8 (such as atmega644p, one of my favorite chips .. dual usarts, 40 pins DIP, 3V or 5V drivable, nearly everything as GPIO, good timers, PWM, etc.)
  2. stm32 (another one) - this would be wise since we already have an stm32 F4 for gpu, so using _another_ (or something nearly identical, like stm32 F2) means no extra programmer needed and re-using same adaptor or board-out for the placement; theres a synergy there. More complex to code though, but I've already got that under the belt.

Another consideration is .. avr8 does not typically drive external memory; if you do, using built-in XMEM, you require a high pincount part (typically surface mount, such as 100 pin part.) But the avr XMEM is not all that sweet a deal.. limited to 64K if I recall right, and not even a perfect whole 64K. IF you bit-bang it, and need say 18 or 20 address lines + 8 data lines + some control lines, you see why it is this way; 8 pins for base stuff (reset, 2+clock, 4 power, analog..), that leaves only 32pin free on a 40pin DIP chip; 20+8+4 say and you're all used up, every pin, just for memory bus; no space for peripherals (joysticks etc), and no way to communicate outwards via anything but memory.

Well, not quite true; with th3e avr8 you could use a shift register to add some high address extension; ie: a few pins to drive the register(s), and thus you end up getting say 24pin of addresses out of say 8 total pins, or more (depends how much shifting you want to do.) Each shift costing you some time slices.

Also, avr8 is limited in speed.. say 20MHz.

But atmega644 or atmega644p.. + some shift regiser(s) –> could handle being the cpu, and even handle peripherals (well, some, not many).

Might even have to do..

  1. atmega644 cpu with shift register so it has serial or i2c available
  2. + atmega644 I/O chip
  3. → the two talking via serial or i2c or bitbang
  4. → atmega644 I/O → atmega644 cpu → shift register → memory → stm32 GPU

So to use an avr8 as cpu, it means adding 2 avr8's, and a shift register.

_OR_ just use the stm32 F2/F4; it uses up more pins for 'junk', and if you get 64pin LQFP you really don't get _that_ many more pins than an avr8.

So It _may well be_ that need an avr8 as I/O chip _ANYWAY_, which would simplify design (the cpu module becomes just a cpu, not a case where one cpu module is just a chip, where another is a chip or 3..)

Will have to think it out a bit, see how many pins we need for peripherals, and if we can shift register _them_ sensibly. ie: You can always have 10-16pn's for joystick, and a couple for keyboard, on shift register; say 16bit (2 8bit shifters in chain), and then rotate them in when interupts occur. Its not like keyboard and joystick are particularly heavy.

And if you're doing an stm32 as cpu, its fast (120MHz and up) so all that shifting is really nothing. It also would have the bandwidth to hit that memory pretty hard in its time slices.

With an avr8, its not particularly fast so maybe can't hit the memory fast enough to be super awesome for graphics, and all that shifting/etc will slow it down quite a bit. (ie: reading a keyboard pin taking 16 shift+reads, sort of thing.. thats a lot of cycles to fetch one pin.)

….

So maybe stm32 f2 or f4 is the way to go for a cpu:

  1. re-use existing hookup as for gpu
  2. single programmer needed
  3. very fast chip
  4. higher complexity to code though (ARM and 32bit, not simple avrgcc 8bit)
  5. reliable toolchain (gcc!) .. unlike Zilog eZ80 with buggy compiler
  6. can't reflash it live, I do not think, from itself … but maybe could flash one stm32 from the other?
  7. can bitbang the RAM/ROM bus and also use the memory unit to do it without bitbang, likely
  8. lots of good features in stm32 (dma!)

So I've not made up my mind, but dual stm32's seems like it might be a wise default.

But I'd rather avr8 as default, despite all the extra work needed (dual avr8's + a shift register or two) –> ALL DIP makes design easy, makes soldering easy. Perhaps one QFP64 part as GPU is enough for SMT….

Discussion

Enter your comment. Wiki syntax is allowed:
 
/home/skeezix/public_html/zikzak.ca/zikzak.ca/dokuwiki/__data/pages/blog/on_modularizing.txt · Last modified: 2017/11/11 02:58 (external edit)