I'm not quite sure if this is the right place to ask the question so please forgive me if I've made a mistake.I am developing a variable-rate ACELP Wideband decoder for the M0. While the code and work-RAM are small, I need a lot of space to store a datastream of speech to decode. I've talked with PragmatIC and they do have a CMOS M0 core on their road-map. My idea is to add mask ROM because at scale, it is an incredibly cheap and small form of data storage.While my initial aim is to incorporate it into the support processors of the current generation of consoles. They all use an ARM core so M0 is certain to work on all implementations and being a pure assembly language programmer, I can get very close to ARM processing speeds in Thumb.However, to develop such a thing on an M0 board does mean I need a decent amount of memory to store a decent amount of speech to demonstrate the system. I know that 72Mbit SRAMs are available but they seem to use a huge number of pin-outs and E2PROM and related are all slow (even a 48MHz CPU needs to add a wait-state) because normally the data is copied into RAM and the sizes don't tend to be huge.Am I correct in thinking that I should use the AHB-APB Bridge C (marked Peripherals) which appears to offer TC0-TC7 i.e. an 8-bit data-bus which would be fine as data is read as a byte-stream.The data-rate is variable. Speech is compressed to achieve a signal-to-noise ratio >20dB thus the number and length of tracks and number of bits allocated to LPC pitch-prediction keep changing. I noted that Audible is fixed and the spaces between words still has a background hiss. I concluded that the hiss could be encoded using 2 or maybe just 1 track with quite a long code-word size.For console work, it's designed to make it easier to support multiple languages and since in every case it is the support chip that is responsible for audio, inserting speech on said chip made things easier.As far as it goes with PragmatIC, the work of Vamsi Talla that has resulted in a mobile phone that harvests power from TV broadcast, Wi-Fi and other prevalent background EMR is a good fit for smart packaging. Imagine food packaging with recipes spoken by a celebratory chef, white goods with spoken operating instructions and 'bubblegum cards' each with a short story. A friend is developing a similar system for graphics encoding. The encoder is highly complex but the decoder is very simple.It is this asymmetric CPU-bandwidth model that is almost unrepresented. DVD and Blue Ray are other examples but the increase in processing power since their inception that has eroded those particular models. My friend has been writing what he calls SPEG - 'Simpsons Picture Expert Group'. The MPEG2 video codec is designed for general images but still manages to leave artifacts when dealing with block colour with black outlines. He got angry at the greed and wastefulness of Box-Set releases. Seasons 1-24 are on 124 discs! 5 discs per series of 22 episodes! That is less than 2 hours per disc! It turns out that you can get a series easily on 2 single-sided discs and to avoid waste, a single double-sided disc would contain the whole series. It's wasteful right from the materials to the duplication to the packaging to the distribution and finally to the convenience of taking said box-set home!I digress. Put simply, we believe that the IoT will be based on the M0. At under 2mm^2 you can't make a much cheaper chip and correct me if I'm wrong but 28nm fabrication size is the most economical and MROM storage just uses rows x columns (x levels) of the smallest feature (a line) that either is or is not a junction so only the but of MROM being access has to be powered so it's also the lowest energy?Sorry to OT but I'm an assembly-language bare-metal programmer (although I would use MBed if it became universal) and PragmatIC is offering a totally new kind of processor product that is 20 years behind silicon (their words). That means looking back 20 years would still see an M0 with it's 12000 gates as a very simple. The original P5 had gate count in the millions.Thanks for your time.PS PragmatIC think the speech stuff is 2 years away but by introducing it into consoles via their ARM cores is a way to publicize the idea and it expands the uses of the metal-on-cling-film uses. The video-codec obviously won't have LONG videos but bubblegum cards with a cartoon short would be popular with kids. PPS for those thinking that streaming from the net is a better option, consider that sets of audio.video are released so to get a full set, customers buy multiple units. The ClingfilmPC is so cheap, it's an added-value concept for the people using the idea.
TLDNR;Anyway, for the demo, how much RAM do you need? Why not go for a demonstrator on a Cortex-M3/M4 with sufficient RAM and downclock it. Or use for example an LPC4xxx which uses a CM4/CM0 combo: Let the CM4 do the "RAM simulation" and the CM0 the actual job?
The M3 cannot emulate an M0 .accurately The pipelining, the cache (the M0 cache is direct, not associative), the branch-speculation and so on. To attempt emulation every other instruction would need to be an instruction and/or memory barrier. I did spend quite a while looking at that option but was unable to find a way to do so. This doesn't mean it isn't possible, just I cannot find it in or infer from the manuals. I THINK I basically intend to scale the precise decode to use 100% of the M0s bandwidth. Luckily, decades of ACELP research has followed every avenue including that of using of all available resources. Since data access is serial, I don't need random access. I simply need something that reads the next 8 or 16 bits of data from a memory-mapped register into a CPU register. Ideally non-volatile to speed up development a bit (no pun intended). I believe that sufficiently fast flash, SRAM and EEPROM devices exist but as to the available sizes, I don't know. I believe 16kbs with 4-tracks & a 64-bit virtual codebook are right at the limit so I'm aiming at that. While microcontrollers are becoming very cheap, I'm aiming at the bottom end of that market. The man who can make an M0 execute an application that another man needs and M3 to complete will be the one to get the work. I'm looking at the PragmatIC roadmap and it's a system that is cheap enough for smart packaging that I am aiming at. They have a working M0. Please don't think I'm intending to show off. I am hopeless in every language but assembly language so the only way to profit from my rather narrow skill-set is by a similar metric to my previous profession - programming on (cheap) games consoles where heros like David Braben got Elite onto a 2MHz 6502 with 32Kbytes of RAM. The more severe the limitations, the more important the code. M0 supports a lot more tricks than one may imagine. Using 15 of the 16 registers is an assembly-only trick, for example.
So why not go for a CM4/CM0 dual core? Let the CM0 run your actual code and the CM4 emulate the peripherals?BTW: I earn my living doing assembly RTOS and wrote games for the Atari Lynx (65SC02).
Ah, like the Cypress PSoC 6 MCU Dual-Core! That looks like an excellent idea. I'm going to check the coms side to be sure but surely the best way if it works out.I also wrote a game on the Lynx. The serial ROM meant that I had to place a frame of the player character at the start of each page. That graphic compression was a pain. Use 3-bits-per-pixel and discover you have to pad out to a byte every line. I also had fun with the even more execrable Jaguar. The 68000 had bus priority over the RISC cpu so you had to run lots of divides just to keep it from stealing the bus. I did use an op-code that bricked the 68K but Atari were too precious.
The 68000 had bus priority over the RISC cpu so you had to run lots of divides just to keep it from stealing the bus. I did use an op-code that bricked the 68K but Atari were too precious.
Off topic, but yes, the Jaguar was/is a strange beast. I used "stop $2000" to halt the 68k in Tetris where I did 99% of the stuff with the Tom&Jerry using the Blitter to load the overlays ... aaaaah that was fun .... :-)
Well Bastian, it sounds like we were cut from the same cloth. I converted Tetris to the Commodore 64 when I was 14. The game was actually for the Jaguar CD. I think it was something to do with that which meant it couldn't use stop.