 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : Speeding up The Maximite
| Author | Message | ||||
bigmik Guru  Joined: 20/06/2011 Location: AustraliaPosts: 2914 |
I have been thinking, I know, this usually means trouble But... As the MM has to display out the VGA port, how much speed up of code iteration would we achieve if we were able to tell MM basic to cease Console I/O and just run the code? Ie. a command CONSOLE OFF (ON) would toggle keyboard, VGA and USB I/O so that the fastest possible iterations of normal code can be performed by not servicing these functions. Would this generate some speed improvment or is it really minimal? Regards, Mik Mick's uMite Stuff can be found >>> HERE (Kindly hosted by Dontronics) <<< |
||||
vasi Guru Joined: 23/03/2007 Location: RomaniaPosts: 1697 |
And that qualifies for a wish... Hobbit name: Togo Toadfoot of Frogmorton Elvish name: Mablung Miriel Beyound Arduino Lang |
||||
Gizmo Admin Group  Joined: 05/06/2004 Location: AustraliaPosts: 5078 |
I think the VGA is processed indepently from the core. I remember reading somewhere Geoff used one of the serial UART's as a VGA output device, and it just runs in a loop reading from memory, freeing up the core to do other stuff. I could be totaly wrong though 
Its only when new data is written to the video memory that the core is involved. So in theory if nothing is changed on the screen output, there would be no gain in turning it off. Keyboard could be another matter, its waiting for user input all the time, even if just a CRTL-C. But again, I dont know how involved the core is with this. Glenn The best time to plant a tree was twenty years ago, the second best time is right now. JAQ |
||||
Dinosaur Guru Joined: 12/08/2011 Location: AustraliaPosts: 311 |
Hi all Mik a coincidence that I have finally received my mm, and did a speed test. A very simple program like: 10 Option Bas1 1 20 StartTime = Timer 30 For X = 1 To 1000000 40 Next x 50 Print Timer-StartTime 60 End And thus 23884 lines per Sec. Where is the 30,0000 lines per sec. Am I wrong, by saying this is only executing one line, is a For Next 2 Lines ? Changing the code to 10 Option Base 1
takes about the same time
20 StartTime = Timer 30 For X = 1 To 1000000:Next X 50 Print Timer-StartTime 60 End Regards Regards Hervey Bay Qld. |
||||
| Gizmo Admin Group Joined: 05/06/2004 Location: AustraliaPosts: 5078 |
I dont think lines per second is a good way to measure a computers speed. It would depend on what commands are issued on that line. eg a gosub or pause. Also incrementing variables can have a dramatic slow down when they reach a certain size. I know when programming in VB I have to watch string lengths, eg C="A"+"B" wont take long, but if we have a string thats a few thousand characters long instead of just "A", then its a big CPU hit, even though it appears to be a simple command. Also, what are we comparing the Maximite to? If I compare it to my old Microbee, then the Maximite is lightning fast. But compared to my current PC, its slow. Glenn The best time to plant a tree was twenty years ago, the second best time is right now. JAQ |
||||
haiqu Senior Member  Joined: 30/07/2011 Location: AustraliaPosts: 152 |
Dinosaur, That's the same code, line numbers would be optimized away anyhow. Good question about the video Mik, this might be important for critical embedded applications. Then again, would you use BASIC in that case? Rob unzip, strip, touch, finger, grep, mount, fsck, more, yes, fsck, fsck, fsck, umount, sleep |
||||
| bigmik Guru Joined: 20/06/2011 Location: AustraliaPosts: 2914 |
Hi Glenn, I wasnt trying to compare speed... I have actually bought some displays .. see link ... and am considering my interfacing options. And it looks like I will have to serially clock into a CD4040 or similar or use a few I2C latches to latch 16 bits across (2 chips) for each 8 dot character.. and then cycle through the 8 rows to display the dots a row at a time (fast cycle so it looks smooth) so I was wondering how fast basic would go at it and then came apon my idea and thought it might speed things up FYI Displays I bought regards, Mick Mick's uMite Stuff can be found >>> HERE (Kindly hosted by Dontronics) <<< |
||||
| bigmik Guru Joined: 20/06/2011 Location: AustraliaPosts: 2914 |
Hi Rob, Seriously I WOULD use basic because that is ALL I know... I have tried to get my head around C but that is gibberish to me. I really think a basic package that calls an optimsed C routine would probably be required in my application but I think that the VGA is effectively "Bit Banged" out it *HAS* to take some time and then scan for K/B.... but then I dont know enough about the Geoff's Magic code. Mik Mick's uMite Stuff can be found >>> HERE (Kindly hosted by Dontronics) <<< |
||||
| seco61 Senior Member Joined: 15/06/2011 Location: AustraliaPosts: 205 |
Hi. Thinking is good and it is a thought that had occurred to me some time ago. I have become very familiar with Geoff's code and can offer some insight into the overhead. First, to implement such a command would be very simple - though the implementation of the command would itself provide a very slight overhead in the case where it is in the CONSOLE ON state (but just 3 C "if" statements, which will equate to approximately 5 assembler instructions each...). While the video subsystem utilises a combination of a SPI peripheral, a DMA channel (well 2 actually), an output compare module and a timer with its associated interrupt - it "should" be a very minimal overhead as most of the processing is done outboard from the CPU (with the exception of the timer interrupt). However, due to a "technical glitch", a dummy loop has been inserted in the routine and this takes at least 11% of the available CPU. So disabling the video output routine (in its current state) would definitely provide a noticable benefit. I am currently playing with the video ouput code to see if I can find a way to avoid having to use the work around - but I do not know if I will succeed. The keyboard scan routine currently executes every 20uS. Most of the time it has a very fast path through it (unless a key is pressed) and probably only adds 1 - 2%. The USB check routine is currently called within the video interrupt. The recommendation is that this routine be executed every 100uS or so to ensure no buffer over-runs occur. I have not examined this code in detail (supplied by Microchip) so am not certain of its overhead. In my current code I have moved it to a different timer interrupt and call it less often. Also, as it is now in a lower priority interrupt it no longer interferes with the video display when I send a large amount of data from the terminal emulator (ie pasting in a large block of code). Regards Gerard (vk3cg/vk3grs) |
||||
| vasi Guru Joined: 23/03/2007 Location: RomaniaPosts: 1697 |
Hi Gerard, From the discussions from jallib group, if you have a lot of PWM outputs, a Serial comm is recommended instead of USB. But that was about PIC18F's. don't know how much count on a PIC32. Vasi Hobbit name: Togo Toadfoot of Frogmorton Elvish name: Mablung Miriel Beyound Arduino Lang |
||||
| seco61 Senior Member Joined: 15/06/2011 Location: AustraliaPosts: 205 |
Another thing that can be done to speed up the Maximite is to increase the "small data size" setting in the compiler options. However, due to what I consider to be a bug in the compiler, while the compiler correctly generates the code to support the size you supply, it does not place some of the variables into the correct section. And when the linker runs the variables are not grouped in the correct place and relocation fails. The variables that are not placed correctly are global variables that do not have a "extern" declaration. These end up in the COMMON section instead of the .scommon section. This can be fixed by changing the source to have a static attribute on the variables that do not require to be external. I have done this for testing purposes and it does make a significant difference to run time speed. Regards Gerard (vk3cg/vk3grs) |
||||
boss Senior Member Joined: 19/08/2011 Location: CanadaPosts: 268 |
Good morning from Canada, I would like to contribute into discussion with couple of ideas: first I have apologize for my bumpy English now: I'm pretty sure that maintain the VGA using the cpu is bare wasting of scarce CPU resources, the cheapest FPGA can is designed to perform such job in the superior quality and of course in color and as with many graphic support as we will be able design a program. Well, here is group of experienced fine gentleman, let form a special group and talk about an advanced MAXIMITE. Geoff did the incredible job, let help him ( if he will be interested of course) to design next generation of MAXIMITE. btw. It is an ideal solution for real time control and more. Regards Bo |
||||
| pito Newbie  Joined: 09/06/2011 Location: Posts: 25 |
Bo, there has been a discusion on coloured vga - I passed this info to the maximites at that time: http://excamera.com/sphinx/gameduino/ Ready to connect (via SPI) to maximite (or 1-2w of work on a new pcb). Also there are some benchmarks I did - the fastest language you may run on maximite today is pic32Lua (an interpreter of bytecode, very fast on chip compilation (~mseconds), and runs programs from sdcard as well, and, it is very small- ~65kBytes maybe - interpreter and compiler all-in-one): http://askrprojects.net/software/pic32lua/index.html Currently only asm and C is faster. BTW, Lua uses 64bit float as default, and even so the Lua is 20-30times faster then maximite's basic. Pito |
||||
| haiqu Senior Member Joined: 30/07/2011 Location: AustraliaPosts: 152 |
Pito, That may not be the case for very long, I just ported pForth. :-) Rob unzip, strip, touch, finger, grep, mount, fsck, more, yes, fsck, fsck, fsck, umount, sleep |
||||
| pito Newbie Joined: 09/06/2011 Location: Posts: 25 |
Interesting, we tried to scale down pforth but still @ 256kB ram.. Any reference to your port? Pito |
||||
 Print this page |
