Finally got to take a look at this. This code really is "quick and dirty". Where do you want the comments sent? Still have to dig further for the possible change above though .

 

I want people to improve it, but I doubt it will be me doing it

I'm not terribly interested in writing PC software, but had to because trying to get the logger writers to add what I wanted was never going to work. For now this works better than a hex editor and you can actually map a car with it.

 

codgi, do you want to post the suggestions on here, and maybe some decent VB programmers can work on it? If you start talking repositories and source control, you'll just confuse me. How should it be arranged? No one feel they are treading on toes, let's just get it done...

 

Nothing about respositories. I'll start posting as i get more time. But I do want you to clarify this:

I have to look over the code again (and open your xmls) but is it that you want to allow the user to configure these tables in xml? Or is it that you want to be able to automatically pull this information from xml that ECUFlash already has?

The former is easy, the later is a bit tougher but i think i have a solution which could work for you. I can write the algo in Psuedo Code since VB honestly hurts my eyes....

 

VB burns holes through my soul

I would like to use one xml file (probably not the Ecuflash one as it doesn't contain info about RAM maps, although they could be added) that has a list of tables that will appear, and the program will parse the xml and create all the tabs, editing buttons, read/write buttons and datagridviews necessary. It is quite a change though, which is why I previously abandoned editing anything in my application and was using Ecuflash, hitting ctrl-s and then clicking write in my app. Trouble with this is that you can't do map tracing, which really is quite useful.

If Ecuflash gets a logger, then hopefully buttons could be added to that to write maps to RAM using my DMA protocol, but with the source not being available or in a form I know how to quickly add things like this to, I'm stuck there.

The protocol to transfer a DMA block, from the PC side:

Ex, 4 byte address, 2 byte length, data (read indirect, read direct, write direct depending on x being 0,1,2)

 

Added charting. Two problems, the logging goes from 1400 items per second down to 60 per second when I have it running, and the pastel colors aren't very clear.

 

Try using some queue, e.g. CompletionPort / Windows Message Queue, this should do the trick.

 

Who creates the original xml file?

 

Both Overkill for this application. The first one is not really applicable since he'd have to PInvoke the living daylights out of VB just to use it and even then it is VB so blah. Proper multi-threading will solve the issue.

 

I just did not want to scare hell out of John with magic word "multithreading"
I do not know how familiar is John with the multithreading topic. But yes if implemented correctly any multithreaded queue will do. I wanted to help him with ready solutions.

 

I've not attempted multithreading, but it looks like I'll get acceptable performance by using a few timers. Things run fast until the Dundas chart with 17 items is in view, so I can speed it up by only updating the chart twice a second on a timer. CPU usage goes down from 70% to about 20% and it is usable. Developing things like this is a real time eater, it took five hours yesterday to learn about and start playing with Dundas charts, then they run slow I would use my own graphics like I do on the Pocket PC and it scrolls nicely, but the same code doesn't work to scroll on the PC, and I can't work out why. I can run the actual Pocket PC application on the PC, and everything works except my scrolling.

The xml would be an amalgation of the individual xml files I put in with each ROM distribution - it would contain the addresses and sizes of each map that would be live edited.

 

The thing that serially irritates me about learning anything in VB.net is that many of the examples simply don't work or have errors in them! This was the case with a Dundas example and the first bit of code I just looked at to do multithreading. It has also happened before. You end up spending hours fixing the examples when you're supposed to be learning. Seems to be a VB thing

 

Better colors, and faster using just 8 items and Dundas Enterprise "fast line". You can scroll and zoom to review things afterwards. Not sure on the licensing arrangement though and whether I can distribute anything using the evaluation version, and the performance is still nothing like what my own code does on the Pocket PC. It is actually still the refresh speed of the Dundas chart that is the issue, and it seems slow in Evoscan as well.

What I need is more like an oscilloscope display, I want it to scroll smoothly like my old Amiga did

 

Yeah but the barrier to entry for multithreading is less than those queues .

 

Pretty certain that the eval version probably can't be legally "shipped" with your code but there should be an EULA somewhere in the download.