>
> The gnuCsimm Project
> ~~~~~~~~~~~~~~~~~~~~
Ouch, there's confusion for you (obviously intentional). I'd ask that you
pick another name, Glen. I'm sure you can think of one that cannot be
confused with the uCsimm...
...
> This device is not a replacement for the uCsimm, but targets a
> different
> application: Data acquisition and embedded control. For example, the
Well, remember that the uCsimm is targetted at exactly this as well. I'm
sorry if that was not clear before.
> The '332 does not have a Bootstrap Mode, however a small (8Kb or 32Kb)
> boot EEPROM can be programmed from the BDM interface. In turn, it can
> be used as the primary debugguing/FLASH programming interface.
No, you can just use the bootloader code I wrote for 68332 years ago
over at ftp://ryeham.ee.ryerson.ca/pub/m68k. There are Linux Background
Debug Mode tools there as well. There is my user mode 68332 tools,
A very nice kernel module someone else wrote including a gdb remote
and some FLASH tools I wrote that work with the kernel module.
Don't mess about with EEPROM, just use the first sector of the FLASH for
that. Once burned, you don't need the BDM anymore (same as the bootloader
mode on the 68EZ328). The people doing the EFI332 project (which might be a
good place for you to start if you're not sure what you're doing) were using
these tools to great success last time I looked.
...
> which is necessary as the '332 is not as standalone as the '328.
Of course it is :-) The 332 was/is _the_ defining member of the 683xx
series, and IMHO the most sucessful. Intended for fuel injection and
motor control, it really kicked off Motorola's on chip "modules"
with the same core approach from the POV of engineers using Mot
embedded chips. One of it's modules, the SIM (no, not SIMM :-) or
System Integration Module is present on all 683xx in one form or another.
The _only_ thing the 332 lacks is the DRAM controller (and it does not
meet FLASH timing, but you can work around that).
> The '332 needs pullup/down on the address bus coming out of reset to
> set boot options. It also has a maximum of 1Mb address space on each
Yes, you'll need to look out for those. These cause things to fail in
nasty frustrating ways (there is a lot of options).
> Chip Select pin, so only chips of 1Mb or less address space can be used
> without external circuitry. There is no Real Time Clock onboard, so an
> external RTC is needed.
And they don't meet FLASH write cycle timing.
>
> Fortunately, there are 9 Chip Select pins available, as well as a
> dedicated CS for the boot ROM device. As a starting point, I would
> suggest two 512Kbx16bit FLASH chips, four 512kbx16bit SRAM chips, CS8900
Commodity FLASH of that size is 3v, and you'll want to just or together
a few chip selects and use a single larger one (or decode a larger block).
There apparently is a 3v 68332, but the 5v 332 is the common one, so that's
going to be an issue. I think you mean four 512kbx8bit SRAM, 512kbx16bit
is not a commodity part. If you're decoding anyway, IMHO, just build
a DRAM controller with a single chip bus exchanger and the same CPLD used
to decode.
> ethernet, and an 8bit RTC. This leaves one CS pin for external devices,
> however, two of the SRAM CS pins will be available on the connector, so
> if the chips are not installed, they can select off-board devices.
> Also,
> if the SRAM/FLASH chips are pin-comaptible, they can be interchaged for
> a specific application.
No, not even close. Different package even. You might be able to have
pads on the board for both in the same space, though the routing will
be ugly.
>
> If you are interested in this project, send me some email with a short
> description of your experience with this chip. I'll create a mailing
> list
Used it in more commercial applications than I care to mention. Kenneth
and I ported uClinux to it. Sorry Glen, IMHO your project is a direct
stab at uCsimm because we've decided not to give away the whole store...
can't lend you a hand.
> and we can start discussing the peripherals and capabilities. After the
> details are pinned down, we can move onto schematics and then the PCB.
>
> Cheers, glen.
>
--
Cheers,
Jeff / VE3DJF [EMAIL PROTECTED] http://www.cgocable.net/~jdionne
Got one, got one, everybody's got one. Oompah oompah, stick it up your jumper.
Got one, got one, everybody's got one. Oompah oompah, stick it up your jumper.
--
To unsubscribe from this list, send a message to [EMAIL PROTECTED]
with the command "unsubscribe linux-embedded" in the message body.
For more information, see <http://waste.org/mail/linux-embedded>.
