__          __
 \ \        / /
  \ \  /\  / / 
   \ \/  \/ /  
    \  /\  /   
     \/  \/    
               
               

 _____ 
|  __ \
| |  \/
| | __ 
| |_\ \
 \____/
       
       

         
         
  ####   
 ##      
 ##      
 ##      
  ####   
         

 __  __
 \ \/ /
  \  / 
  /  \ 
 /_/\_\
       

 #       
 #       
 # ###   
 ##   #  
 #    #  
 ##   #  
 # ###   
         

IMPORTANT: enter the case-INsensitive alphabetic (no numbers) code AND WRITE SOME SHORT summary of changes (below) if you are saving changes. (not required for previewing changes). Wiki-spamming is not tolerated, will be removed, so it does NOT even show up in history. Spammers go away now.


Visit Preferences to set your user name
Summary of change:
Compiled using WinAVR. A few messages, but nothing scary so far. Hmm. What if I tried to make the footprint smaller to see if it would fit in another device? (I won't bother readers by explaining why unless you want to know. Ask if you do.) '''Why ?''' Which device ? I have a 1951 Fergie that I use around the house. It runs crappy and is more thirsty than a 1970's popstar. I thought it might be a nice 1'st project to play around with a DIY ignjection system. There would be no space (or environment) for an LCD. It would have to be a bit more compact and resistant to harsh environment. I was hoping to use a PCB I have a number of from a project I've done at work and just solder on the missing components dead-bug style. It uses ATmega16/32. I would like to see if I could get the footprint down to match it by removing the modules not needed. And I could play with it between Christmas/New Year as I have a week off. '''You can certainly get the V3 board in a week''', just write urgent in the order note. (unassembled controllers can be sent in 24hours; assembled controllers are usually sent out in a week, but take +4 days for Hungary=>Sweden) BTW. My compliments on the project. It took me less than 15min from start of download to first .hex code. It fit straight into my existing environment. Looks very clean. I don't expect anyone to take much interest in such a low perf. app, but even if it does not go well, it will let me get a feel for how the code is built up. If you can shrink the binary to 32kbyte and make it suit your app, that probably justifies the small HW. Please send to the authors (MembersPage/MarcellGal preferrably SVN/CVS/WEB access code via email or SMS; or the zipped tree in email ) * your modified (in this case "shrinked") firmware source (required by the license anyway) * the schematic you run the shrinked source on (or at least AVR input-output mapping) * if possible, the layout (in editable form) as well. This is not required but would be highly appreciated. Commenting out "# MY_CONF += -D LCD" makes it barf on missing functions. Someone forgot to #ENDIF <stub code>. I suggest either taking out the indication in my_make it can be done, or correcting code so it can. Obviously, it is possible to fix it to compile without LCD, and magicstr.h and varstr.h and lcd_display.c would free much space. Also, much inlining eats space. 64 kbyte flash would be possible, but 32kbyte would mean serious compromise. Thank you for an open and constructive reply. After the first brief look, I tend to agree in that it may well turn up as a major rewrite, and incompatible with evolving code. And unless it can fit in one of the smaller packages probably not very useful. I'll follow on the sideline a bit and see if there are other things I can do that is not a dead end. I'll better go have a sightseeing in the code and see if it may be too much other stuff making it difficult to fit in another device. Fitting in a smaller device is kindofa dead-end (unlikely to be wrapped into a product). But it can be fun, and who knows it's long-term benefits for related projects. If you want to help making the code (more) portable, it's possible that you get SubVersionSvn access for the trunk (codetree that has been started to be ported for ARM), but signing a lightish NDA is necessary, and firmware developers must see your intentions clearly. Signing a NDA is no problem. I've signed quite a few of them, and "lightish" they were not. But I'll not do that unless I get where I think I have something to contribute, which will be after/if I get a grasp on the downloaded code. --------------------- The summer projects are now on hold due to lack of summer. So I started to look into the VEMS code to see if I can make any sense of it. Firmware_1.0.45 is the most recent I can find that looks complete. Can someone tell me what the different states of engine.ignstate means? 0 - Spark was fired off. Coil not charging, nothing was scheduled. 1 - Tested against it, but never set to 1!? 2 - Spark have been scheduled. 3 - Seems to have something to do with early_dwellstart. Overides state 4 in disp_igndeact(). 4 - Same as State 0, except it was immediately activated. What is early_dwellstart and where is it set? What is LATE_CORRECTION used for? The engine.ignstate is old code soon to be retired (when the new overlapping-dwell code supports coil-type trigger and distributor). What are your intentions ?
Optional: Add document to category:
Wiki formatting: * is Bullet list ** Bullet list subentry ... '''Bold''', ---- is horizontal ruler, <code> preformatted text... </code> See wiki editing HELP for tables and other formatting tips and tricks.