-
Microcontroller suggestion
Posted by
fabiodl
on 04 Jun, 2023 04:12
-
I would like a microcontroller with the following features:
- it exposes a parallel address/data/control bus, to which I can connect memory mapped devices (like a motorola 68000)
- it has a wait/ready line which can make it halt during a read write (again, like a motorola 68000)
- its toolchain is open source and well supported
- it is not a softcore (i.e. it is not picorv32 )
- it is relatively fast (just to give an idea, over 1 MIPS)
- it is under 20 bucks
- it is currently sold
- bonus points if the default library supports floating point operations, i.e. it has enough ram /rom to support newlib or it uses avrlib
- bonus points if it's risc-v based
-
#1 Reply
Posted by
dobsonr741
on 04 Jun, 2023 04:31
-
RP2040 with the PIO emulating the bus.
-
-
RP2040 with the PIO emulating the bus.
Yes, the only downside is the limited number of GPIOs. That's quickly going to be a problem for interfacing parallel memory with an address, data and control bus.
Another option would probably be the much beefier and more expensive NXP iMXRT 106x series. Very flexible interfacing, many more GPIOs, much more powerful, and still below the 20 bucks mark.
For other common MCUs, that'll be hard to fit the bill. Many have some kind of memory interface, such as STM32's FSMC, but while it can be configured in various ways with configurable wait states and such, I don't think it's capable of doing the handshaking (the OP's wait/ready line.) This last point will restrict the choice of MCU drastically.
-
#3 Reply
Posted by
brucehoult
on 04 Jun, 2023 08:02
-
I would like a microcontroller with the following features:
- it exposes a parallel address/data/control bus, to which I can connect memory mapped devices (like a motorola 68000)
That is just about the definition of "What is the difference between a microprocessor and a microcontroller".
You can always implement whatever external bus you want using GPIOs if you have enough of them and the bus doesn't have to operate at super high speed.
ATMega2560 supports external RAM (or whatever) in hardware using PG0-2 for control and PA0-7 and PC0-7 for the address. D0-D7 use the same pins as A0-A7 so you need an external latch for the low address bits. External memory adds 1 wait state I believe.
- it has a wait/ready line which can make it halt during a read write (again, like a motorola 68000)
No idea. Of course if you implement everything yourself using GPIOs then you can do whatever you want.
- its toolchain is open source and well supported
- it is not a softcore (i.e. it is not picorv32 )
- it is relatively fast (just to give an idea, over 1 MIPS)
- it is under 20 bucks
- it is currently sold
- bonus points if the default library supports floating point operations, i.e. it has enough ram /rom to support newlib or it uses avrlib
All easy.
- bonus points if it's risc-v based
Harder.
Kendryte K210 has 8 MB of internal RAM and supports 8 MB of hardware-controlled external SPI RAM (which could of course be MMIO if you want).
-
#4 Reply
Posted by
hans
on 04 Jun, 2023 12:39
-
Look at F(S)MC of STM32F4, and possibly also present in other families (e.g. F2 F7 H7). In NOR/PSRAM mode it has a NWAIT signal that is an input to the MCU to wait on the memory device. The downside is that the data D[15:0] and address A[25:16] + A[15:0] is partially multiplexed.
These devices can support a reasonably large address space plus a 32-bit data bus.
One thing to test is whether that mode supports reads and writes, and how the asynchronous behaviour then works.
For example, the QuadSPI controller in some STM32 devices could also be memory mapped, but was only intended for reads from FLASH as it only supported a single instruction opcode to initiate random addressing. If it was used in direct mode, it could do both read and writes.
I think many other memory busses will have controllers that communicate in terms of synchronous transactions, and assumes a fixed number of dummy clocks (as latency) before the memory device will reply. That's how a lot of these FLASH and S(D)RAM chips work anyway.
I'm not sure if its an exact for the devices you want to communicate with. I think other options would quickly converge to a FPGA, but I will not challenge the presumption that 'no softcore' also means no FPGA/custom logic fabric solution (be it glue or as a complete controller).
-
#5 Reply
Posted by
langwadt
on 04 Jun, 2023 12:57
-
1 MIPS is slow, as long as you have enough pins you could easily bitbang a memorymapped device with a wait
-
#6 Reply
Posted by
nctnico
on 04 Jun, 2023 17:04
-
Some of NXP's LPC1800 series microcontrollers have an external memory interface (called EMC as in external memory controller). IIRC the LPC1700 series has these as well on some models.
-
-
Winchip CH32V307.V package (qfp 100) meets most of your requirements, with a question mark about the wait line. Would need to read the datasheet concerning the external memory interface.
Nice and relatively cheap around $3.50 usd. RISC V core at 144Mhz.
Edit: RP 2040 also could work, if you run out of GPIO as SiliconWizard comments you can multiplex and latch the address bus in external latches like 74hc373. The PIO could do this easily.
-
#8 Reply
Posted by
djacobow
on 04 Jun, 2023 22:23
-
Sounds to me like you might be happier using shift registers and a little glue to emulate an old school address+data bus rather than have it be the processor's actual bus. For this you could use just about any modern controller for the processor, 595's for the address bus, some kind of io expander for the data bus (or make something out of two kinds of shift registers, 595 for "writing" and 165 for "reading"), using controller GPIO to control them as well as serve as the control signals for bus devices.
You'll get much more than 1 MIPS this way and your bus can still go as fast or slow as you need.
I think it would be more fun to do it this way, too.
-
#9 Reply
Posted by
westfw
on 04 Jun, 2023 22:34
-
it has a wait/ready line which can make it halt during a read write
I don't think I've ever seen a "microcontroller" with a wait/ready line. In fact, it seems to be one of the first things to disappear even on "microprocessors" with internal memory decoding (80186, 6833x, etc) (IIRC, they also do internal wait-state generation on a per-decode basis, so you don't have to do it externally.)
-
-
As langwadt said though, unless the OP has strict timing requirements regarding memory access (in the sense of some jitter would be unacceptable, which I doubt here), that we can assume would not be required to be done at a higher frequency than 1MHz, it could be all bit-banged with pretty much any 32-bit MCU running at a few tens of MHz. So if RISC-V is required, pick one of the avaiaible ones such as what chickenHeadKnob suggested.
The only additional thing to know is, would this external memory access have to be "transparent" to the MCU core itself? (Meaning, transparently with just load/store instructions?)
If so, that might still be doable with bit-banging, implementing an exception set to trigger upon memory access to the address space you would define for this external memory.
Even with an exception in between, at 144MHz you should be able to work it out, although you'd have to look at the worst-case latency for exception handling on the particular MCU you're gonna use. And probably you'll need one with PMP too (to set up the exception).
-
#11 Reply
Posted by
james_s
on 04 Jun, 2023 22:58
-
Your requirements preclude any microcontroller ever made that I'm aware of, what you are describing is a microprocessor. With sufficient IO pins or an IO expander chip you could create your own bus, but it won't be the internal bus used by the core.
-
#12 Reply
Posted by
Psi
on 04 Jun, 2023 23:53
-
ATMega162 is another one with external memory space (64KB)
I'm not too sure about the "wait/ready line" requirement. it has a read/write stobe and addr latch enable.
Runs up to 16 MIPS.
-
-
-
#14 Reply
Posted by
brucehoult
on 05 Jun, 2023 11:11
-
-
#15 Reply
Posted by
Siwastaja
on 05 Jun, 2023 12:46
-
Microcontroller speed was discussed (~1MIPS), but how about the speed of that specific bus? Something like 1MHz would be trivial to bit-bang, or even interrupt-driven in background if you want ease of programmability of everything else. Make it 10MHz and it becomes tremendously more difficult, maybe something like STM32's FSMC with some extra glue logic to handle the wait/ready business. But at low enough bus clock speed, software solution gives you most flexibility.
-
#16 Reply
Posted by
langwadt
on 05 Jun, 2023 13:59
-
Microcontroller speed was discussed (~1MIPS), but how about the speed of that specific bus? Something like 1MHz would be trivial to bit-bang, or even interrupt-driven in background if you want ease of programmability of everything else. Make it 10MHz and it becomes tremendously more difficult, maybe something like STM32's FSMC with some extra glue logic to handle the wait/ready business. But at low enough bus clock speed, software solution gives you most flexibility.
it does look like the STM32 FMC (not FSMC) supports SRAM and external wait
-
#17 Reply
Posted by
wek
on 05 Jun, 2023 14:17
-
it does look like the STM32 FMC (not FSMC) supports SRAM and external wait
FMC is the same module as FSMC, except for added SDRAM support (yes, feature added, letter removed).
In other words, FSMC does support external wait, too, through FSMC_NWAIT pin.
JW
-
#18 Reply
Posted by
Siwastaja
on 05 Jun, 2023 14:44
-
With those peripherals, devil is always in details. I would suggest committing some time by mega carefully reading the STM32 reference manual about their F(S)MC peripheral, to see if the mentioned WAIT feature does exactly what you need. Another way is to pick some evaluation board and just start experimenting and try it out. Or both.
-
-
With those peripherals, devil is always in details. I would suggest committing some time by mega carefully reading the STM32 reference manual about their F(S)MC peripheral, to see if the mentioned WAIT feature does exactly what you need.
Indeed.
-
#20 Reply
Posted by
nctnico
on 05 Jun, 2023 21:10
-
Look at NXP first
More mature peripherals and better documentation. Recently I have been involved in some projects that use STM32 but I'd take NXP's LPC series microcontrollers over STM32 any day of the week. IOW: If you are not working on high volume projects where price is important, don't start looking at ST to select a microcontroller.
-
#21 Reply
Posted by
fabiodl
on 05 Jun, 2023 23:58
-
Thank you everybody. The term F(S)MC was fundamental for me (I googled for "external bus" which lead to much worse results). STM32 seems the most fitting, but the CH32V307 is as interesting as hell.
Look at NXP first More mature peripherals and better documentation. Recently I have been involved in some projects that use STM32 but I'd take NXP's LPC series microcontrollers over STM32 any day of the week. IOW: If you are not working on high volume projects where price is important, don't start looking at ST to select a microcontroller.
how is that so? To give some context, I want to develop under linux and with less proprietary stuff as possible
-
-
Also note PSSI interface (tx/rx 50/100 MHz) that some STM32's have. Although it is not exactly what you are looking for, it is worth knowing before you make a final decision on the chip