I have just recently moved from AVR324p and PIC to LPC2148 (boards and programmer are on the way).
My main interest is generating sound and VGA, which I have managed to to quite easily on the AVR324p, but only up to a resolution of 240x232 at 64 colors due to the 20Mhz limit. Yes, I could run the AVR at 25.175 to get a clean 320x240 screen over a 640x480 VGA screen, but overclocking is taboo and I wouldn’t want to get shunned!
Ok, on to my question…
I only work in assembler due to the intense nature of video timing, and find the cycles per instruction to be just as important as the actual language itself, and so far I have yet to see a clear indication of what each ARM instruction is worth in terms of clock cycles. If there is a list of all instructions with clock cycles included, I would really like to have it as a reference.
My first project will be a port of my AVR sound and video system to the LPC2148. I will increase the resolution to 320x240 using 256 colors, add two more sound channels, a USB keyboard input, and the ability to format SD cards. If it goes to plan, i will post the info if anyone is interested in such things.
Referring to a post I made a long time ago (viewtopic.php?t=3110), ARM chips don’t have fixed instruction cycles. I would definitely recommend using a hardware timer (the 2148 has 2 of them on-chip).
I know that you just ordered your boards, but honestly I would recommend that you move up to a better-equipped ARM, such as Cirrus’s EP-93XX series (Olimex sells boards through Sparkfun for the 9301 and 9302 currently). You can build Linux kernels for them with Cirrus’s software, and the higher level chips (I’m not sure exactly which ones, though) have built-in video drivers and can take keyboard (and maybe mouse) input. The chips also have built-in I2S hardware for your audio needs.
Thanks for the info, Brennen. I will look at the hardware timer option for now as the Cirrus parts seem to be a bit overkill for my project. If I could do it on a AVR324 at 20Mhz, the I can surely do it on the 66Mhz ARM7.
Odd about the “uncountable” instruction cycles though. You would figure that if I wrote a tight loop, I should be able to find out how many uS it takes to complete it and get the same results each time.
This is mainly a fun learning project, so throwing the beefy Cirrus chip at it would make this too easy
I guess I like doing things the hard way, which is why I have no interest in using C over ASM. I look at C code, and it reminds me of that ugly isolated bloat code that I am forced to work with on the PC - UGH!
I know that comment will open a can of worms, but it is just my opinion, and I have respect for all coders no matter what language they choose.
Anyhoo, thanks for the info, I will remember the timer option as soon as I get past the blinky LED stage!
I won’t say that the instruction cycles are necessarily “uncountable.” I’m just saying that apparently not all instructions take the same amount of clock/processor cycles (like they do in PICs). I don’t really see any disadvantage to using timers if they’re available to you, though, instead of trying to count instructions.
I have appreciation for those who decide to code in assembly, but I will definitely never one of those people. While I could make code run faster in asm, it isn’t worth all the extra headache that is required to do complex math, communications, array operations, etc. that using a higher-level language. But let’s face it - C isn’t really that high-level of a language. I’ve even seen it called a middle-level language because even though the assembly is abstracted from you, the actual language doesn’t do a terrible amount for you (think about C# or java as an alternative). But hey, if you don’t like C, then it’s actually a benefit for you because you don’t have to pay hundreds or even thousands of dollars for a compiler .
There are instruction cycle timings that can be found in the big book, ArmSystems Developers Guide. The timings are accurate for register operations, ie no memory access.
But if the next instruction will execute immediatley or not depends on the memory access times.
For code running from full speed memory, or very small loops where all instructions are in some processor coupled cache it also works. Any access to slow memory OR to peripherials accessed through the periperial bus incures wait states and the exact timings are, as brennan says, unpredeictable.
I have tried to improve speed by rewriting C code into assembler with very mixed results. Sometimes, but definetly not always I can improve on the code generated by the C compiler. gcc is free and there and in most other good C compilers you can insert asm fragments for extremely time critical sections of code.
Yes, to me C seems more confusing than any ASM source I have ever seen, but that is because I started using ASM when I first started into microcontrollers. I look at the code and it seems like you have to use a lot of jargon to do the same thing you can do in a few simple instructions.
Oh well, I don’t want to start anything here; we are all after the same goal - working code!
The routine to generate a VGA line is pretty simple - mainly a counter pumping out bytes from SRAM to an 6 or 8 bit DAC depending on your color depth, so the loop timing may still be feasible. I heard that the ARM is bandwidth limited at the pins, so my goal of adding 128K external SRAM may be out the window unless I keep the resolution down to half the VGA pixel clock, since at full speed, the ARM would have to spew out a 16 bit address at 25.175 MHz. The AVR can only do half that if I overclock it to 25.175MHz since it takes two instructions to send the address out to the port.
I would be really happy if I could drop a 128K SRAM onto the 2148, and send out the 17bit address at 25.175Mhz. This would free up the internal 32K+8K for whatever code I intend to use as well as the USB. Actually, I would be fine with the same result at ~12.6 Mhz just so I could get 320x240 out to the monitor without borders like my AVR project.
The NoPc project is a good example of what my intentions are, although he has used the internal SRAM, which is why the color is only 3 bits and the video resolutions are somewhat nonstandard. The uVGA core seems to be able to run way past 640x480, but I am not sure if that is a 2148 on the board or not since it has had the label scraped off and painted over!
AtomicZombie:
I would be really happy if I could drop a 128K SRAM onto the 2148, and send out the 17bit address at 25.175Mhz.
The next family up in the LPC series (the LPC22xx) I'm pretty sure all have external memory busses for RAM and flash memory. Looks like you just missed it with the 2148.
AtomicZombie:
I heard that the ARM is bandwidth limited at the pins
The fastest the LPC2148 can toggle its "fast" I/O pins is around 15 MHz at a 60 MHz peripheral clock (it's in the user manual somewhere).
.