View unanswered posts | View active topics It is currently Sat Dec 15, 2018 9:09 pm



Reply to topic  [ 16 posts ]  Go to page 1, 2  Next
Windows Tuning Application 
Author Message
TO220 - Visibile

Joined: Sun Mar 27, 2011 12:26 pm
Posts: 10
Location: Perth, Western Australia
Hi,
Sorry if this is the wrong place for this thread. Please move as necessary.

I am looking at getting seriously involved in the FreeEMS project as I an a believer in everything it stands for!

Unfotunately I am a windows programmer by profession and while ok with linux, I don't have the time to devote to learning the ins and outs. I work for a company ( 13 years ) that has been designing ECU's ( hardware and software ) for heavy duty CNG industry for the last 30 years. We are also the company that designed the original supercharged 5.4 litre mustang motor.

So, I am looking at writing a dedicated tuning tool based on this project for Windows.

Currently I have a prototype Puma Spin 1 with just the CPU and USB for testing purposes.

Like I said, I don't have a lot of time to trawl the various threads to get some information that I need, so if someone could point me in the right direction that would be great.

1. Am I wasting my time?
2. What are the limitations to using third party ( licensed ) applications/libraries in this project?
3. Is there a spec on the comms protocol?
4. Is there a spec on how the configuration data is stored/retrieved in/from the ECU?
5. Any other usefule information?

Thanks,
Ernest


Sun May 08, 2011 12:39 pm
Profile
1N4001 - Signed up
User avatar

Joined: Tue Jun 10, 2008 5:17 pm
Posts: 1607
eezo20v wrote:
I am looking at getting seriously involved in the FreeEMS project as I an a believer in everything it stands for!
Welcome along and I look forward to your input and hopefully your contributions.
eezo20v wrote:
Unfotunately I am a windows programmer by profession and while ok with linux, I don't have the time to devote to learning the ins and outs.

So, I am looking at writing a dedicated tuning tool based on this project for Windows.
Have you seen Megatunix? That can be compiled for Windows, but is typically done on request. I guess the process is a bit less automated than the typical build process. It might be a good reference to start from, or it might fast track your dev if you can use parts of it.
eezo20v wrote:
Currently I have a prototype Puma Spin 1 with just the CPU and USB for testing purposes.
Great, that will certainly help. Have you plugged in the USB to see if it smokes or not? Also have you seen the mods to make it work with a standard cable? I'm guessing you know that Marco made a mistake which he fixed with a special cable. The USB mods appear to be noted in the PDF's on puma.freeems.org
eezo20v wrote:
Like I said, I don't have a lot of time to trawl the various threads to get some information that I need, so if someone could point me in the right direction that would be great.
I like your get-er done attitude. Of course read as much of the forums as required, but also focus on the dev. Feel free to ask questions. Most of us will reply until the same question has been asked a couple times.
eezo20v wrote:
1. Am I wasting my time?
Not in my oppinion
eezo20v wrote:
2. What are the limitations to using third party ( licensed ) applications/libraries in this project?
Basically only the limitations brought by the third party software. Your thread may be moved to the non-free section of the forum, and changes to GPL things like actuall firmware will likely be considered derived work that requires GPL be maintained. However on the side of the comms you are looking to be on, it would be what ever the third party prefers.
eezo20v wrote:
3. Is there a spec on the comms protocol?
I believe there is a communications spec. I forget where it is. I'm sure Fred can point you to the correct one.
eezo20v wrote:
4. Is there a spec on how the configuration data is stored/retrieved in/from the ECU?
Same as the above, I'm sure Fred will point you to those docs.
eezo20v wrote:
5. Any other usefule information?
Have you seen the wiki, or freeems.org? Freeems.org is a great jumping off point, it has links to things that new comers might be interested in.

In the near future, I hope to post some screen casts about how to use MTX. So keep your eyes open for that.


Sun May 08, 2011 2:41 pm
Profile
Moderator
User avatar

Joined: Tue Jan 15, 2008 2:31 pm
Posts: 15204
Location: Home sweet home!
My turn! :-)

eezo20v wrote:
Sorry if this is the wrong place for this thread. Please move as necessary.

No, this looks like the perfect spot! If it turns into a real functional application, then we can move all related threads to a new section just for it.

Quote:
I am looking at getting seriously involved in the FreeEMS project as I an a believer in everything it stands for!

Great to hear! :-)

Quote:
So, I am looking at writing a dedicated tuning tool based on this project for Windows.

Sure, diversity and competition are always good :-)

Quote:
1. Am I wasting my time?

Probably not, as I said, diversity = good, competition = good.

Quote:
2. What are the limitations to using third party ( licensed ) applications/libraries in this project?

That depends upon what you mean, I guess. There is zero restriction to writing a closed source tuning app and selling it. A guy called Phil Tobin does that for MegaSquirt, if your product is worth it, people will pay, he, as much as I dislike him, ethically, has proved that to be true. If you use a closed source library that isn't freely available, then you will rule out many users and/or cause them to incur a cost to use your app, or have to charge them for it, etc. If you mean development tools, then you're just narrowing your potential audience of helpers. Basically, you can do what you want in connection with the firmware, either in terms of closed source tuning apps or closed source PCB/hw designs. Obviously I'd prefer that there were more open tools and hw designs available as it is already proving to provide a decent level of diversity. If you have anything more specific to say on this question, do so, and I will comment as required.

Quote:
3. Is there a spec on the comms protocol?

Yes, split into two parts, and fairly complete, but not 100% finalised. The first part is the core comms protocol, how to structure packets etc. The second is firmware specific commands that are available and formats etc for those. You should probably try to write your app to handle other firmwares with different sets of specific commands and the same underlying core protocol. That way it'll be easier to extend for future forks or related projects using our comms standard.

Quote:
4. Is there a spec on how the configuration data is stored/retrieved in/from the ECU?

Not yet, no, but it's easy to see what is available at any given time from the firmware source in ./src/initialisers/ and ./src/inc/<headers for stuff from initialisers>.h and ./src/inc/structs.h

Additionally there is a thread on designing the data description language for freeems and compatible designs. The basic idea is to use some sort of human and machine readable text format to hold structure and default data information, generate sources from it, and perhaps even compress it and include it IN the firmware, though that is uncertain at this time.

On top of that, you can get a listing from the firmware with a couple of specific commands on what types of data are accessible and what can be done with them. The first command gives you a list of "location IDs" and then you can request details on each and every one of those. The details include flags on what type of data they contain and how it can be manipulated. From this you can, without an xml file or similar, extract and save all tunable data from the device. The only thing that is missing is the structure itself which at this time, must be hard coded to match the firmware. This is a high priority once I leave the US.

Quote:
5. Any other useful information?

As Jared mentioned, MegaTunix can be cross built for windows and works pretty well as is. Any time you ask for a fresh build for windows, Dave is usually happy to oblige.

I hope that helps!! :-)

Fred.

_________________
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!


Sun May 08, 2011 10:34 pm
Profile WWW
TO220 - Visibile

Joined: Sun Mar 27, 2011 12:26 pm
Posts: 10
Location: Perth, Western Australia
Hi,
Thanks for the replies. I will continue to develop the application.

By third party I meant the use of a 3rd party library within the application that i write. I have purchased a design suite that does the gauges, charts, grids etc but it's a licensed application. Its a per machine compile license, so I can compile it, but others will not be able to ( unless they purchase the library ). Me compiling it is not an issue, as long as its ok with everyone else. Anyone running the compiled application is fine obviously.

Using this library means I can get it running a lot faster, and I could possibly investigate using free/open source alternatives once I have a working proof of concept.

Now, I have a couple of questions:

1. What is the purpose of the async comms?
2. Is anyone implementing a 32 bit CRC. I think this is important.
3. Certain characters are escaped, has anyone thought about using a 2 byte start sequence? Also, if you use sync comms escaping is not necessary.

A few operational issues:
1. I have a working spin 1 that spits out the async data periodically ( looks like a data log of some sort ), so I assume that I have a working payload?
2. Can someone please explain or post a link to how I update the firmware. I need to know what application/version to use to flash a s19 file.
3. I assume the payload sits atop the loader, so when you delete the payload you are left with the loader, which in turn reloads a payload?
4. The same comms protocol is used in the loader and payload?

I don't want to get into a position where I can potentially brick the board so any gotchas are more than welcome :)

Ernest.


Wed May 11, 2011 9:04 am
Profile
1N4001 - Signed up
User avatar

Joined: Tue Jun 10, 2008 5:17 pm
Posts: 1607
About firmware upgrade(s). You'll probably need to compile it, I understand the prior compiled versions are dated. To upload you have a couple of options.

One option is Megatunix which comes with mtxloader or something like that. It can upload a new firmware. I've found Megatunix to be easier to install on my Ubuntu 11.04 64bit platform. Mostly the ./autogen script and README were easier to follow. Megatunix can be found here. https://github.com/djandruczyk/MegaTunix

The other option is FreeEMS-loader. FreeEMS-loader can rip, erase, and upload a firmware. The most recent copy is fairly easy to install, but I had some mild bumps in road due to the QSerialPort install process not coping files to the correct locations. I had to cp a file to make it work. FreeEMS-loader is the more tested and more feature rich bootstrapping program, but MTX is close behind, and MTX does many of the tasks you are setting out to do. https://github.com/seank/freeems-loader

About compiling FreeEMS-vanilla, I see there are s19's posted under the previous-release folder. However those are dated and you really want the newer ones, which most likely means you want to compile them. You'll have to setup the toolchain. You should be able to find the repos and such instructions here http://tools.diyefi.org/, however it looks like that hasn't been updated yet.

EDIT: For 64 bit Ubuntu users contact jharvey for further details. 32 bit users see http://tools.diyefi.org

Once you have the tool chain installed, you'll need to get the Source files. Download them from here. https://github.com/fredcooke/freeems-vanilla

Once you have them, cd to the dir, and type make. It's fairly self explanatory after that.


Last edited by Fred on Wed May 11, 2011 5:45 pm, edited 1 time in total.

Remove unofficial repository information from the public eye. PMs are fine, where necessary only.



Wed May 11, 2011 9:53 am
Profile
Moderator
User avatar

Joined: Tue Jan 15, 2008 2:31 pm
Posts: 15204
Location: Home sweet home!
Just to reply to Jared's post first, I removed the information from IRC as those packages were not acceptably built or labeled. They are good for a 64bit user, but unrequired for any other users. Contact jharvey for details IF you need it only. The rest of the post is untouched. I'll reply to other misinformation here :-)

Jared is right, the version on the card is ancient at best. You need to upgrade. Upgrading involves building and loading the firmware. Building is easy. Loading will be easy.

The rest of this thread should assume windows. Ubuntu info isn't useful here.

Loader wise, there are two options, but neither of them are win friendly and working correctly right now. Hopefully Sean makes his win happy and Dave makes his work properly soon. For mtxloader you need to get dave to build you a recent win installer as, as far as i know, it's not possible to build it yourself on win. He cross compiles for win.

The better news is that the tools site is up to date, and the win installer is very convenient. Firstly get msysgit installed, then clone the source (not download) from the URL that Jared said to download it from. Cloning allows trivial upgrades to future versions, downloading certainly does not. When installing msysgit, check the "git bash here in context menu" item, and the gui one below it, if you so desire.

For building, I'd recommend skipping the intro stuff and just typing "make s19" from the ./src/ source directory. This will get you the minimal files that you need in the shortest possible time. Right now, you can load any firmware you want, they're all the same. If you want to feed the card an input and see an output, you need to configure things yourself, or use a pre-canned build. Read the cli test script in ./bin/ to see how to achieve that. Later, and hopefully pretty soon, the file to load will be the bench test one, as it will provide useful functionality with nothing attached - just CPU, Serial and Power.

OK, back to answer the other post.

Fred.

_________________
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!


Wed May 11, 2011 5:59 pm
Profile WWW
Moderator
User avatar

Joined: Tue Jan 15, 2008 2:31 pm
Posts: 15204
Location: Home sweet home!
eezo20v wrote:
Thanks for the replies. I will continue to develop the application.

Cool, I look forward to seeing it! :-)

Quote:
By third party I meant the use of a 3rd party library within the application that i write. I have purchased a design suite that does the gauges, charts, grids etc but it's a licensed application. Its a per machine compile license, so I can compile it, but others will not be able to ( unless they purchase the library ). Me compiling it is not an issue, as long as its ok with everyone else. Anyone running the compiled application is fine obviously.

OK, yeah, that is entirely up to you! Are you planning to keep the source open anyway such that others can poke around and suggest fixes/improvements? Open source is nice from a trust point of view too. I pretty much only install FOSS software on win/mac for that reason.

Quote:
Using this library means I can get it running a lot faster, and I could possibly investigate using free/open source alternatives once I have a working proof of concept.

Sure thing, I look forward to trying it :-)

Quote:
1. What is the purpose of the async comms?

Flexibility, reliability and speed.

Quote:
2. Is anyone implementing a 32 bit CRC. I think this is important.

Data integrity checking is important, yes. But it only comes in percentages. IE, a simple checksum protects you X% of the time. A 16 bit CRC Y% of the time. A 32 bit CRC Z% of the time. The checksum is not the only method of data protection being used in this protocol. The simple checksum when combined with the other measures has proven to be completely reliable in practice. If switching to a more robust checksum style, speed is a consideration. I mean that in two ways:

1) Calculation cost on the embedded device.
2) Bandwidth cost for packets sent.

2 doesn't seem like an issue, but for very short packets, streaming a single byte at a high rate, packet overheads are already high, and a 32 bit checksum would really hurt samples per second.

16 bit CRC is definitely being considered, however not for a while, at least. A well written program will only require minor change if we migrate to a better checksum in future.

Quote:
3. Certain characters are escaped, has anyone thought about using a 2 byte start sequence? Also, if you use sync comms escaping is not necessary...

...and full bandwidth streaming not possible. Unlike a future checksum change, sync-only comms is NOT going to happen.

Quote:
1. I have a working spin 1 that spits out the async data periodically ( looks like a data log of some sort ), so I assume that I have a working payload?

Yes, however I couldn't tell you what is in it, and if it's only periodically, then it's an old version.

Quote:
2. Can someone please explain or post a link to how I update the firmware. I need to know what application/version to use to flash a s19 file.

We've done the best we can there. I'll let Sean know that you're waiting for him too.

Quote:
3. I assume the payload sits atop the loader, so when you delete the payload you are left with the loader, which in turn reloads a payload?

By payload, do you mean firmware? If so, your sentence makes sense, however in light of other comms protocol discussion I had to read it several times to realise that. If I understand correctly, the answer is yes.

Quote:
4. The same comms protocol is used in the loader and payload?

Again, if you mean bootloader/serial monitor and firmware by loader and payload (we use loader to mean the pc side app) then the answer is no. The bootloader protocol is simpler and less robust. It's documented in AN2548 if you want to write a windows only loader app as a warm up exercise and because Sean's one isn't working just now.

Quote:
I don't want to get into a position where I can potentially brick the board so any gotchas are more than welcome :)

Bricking the board is not possible. If you don't have a BDM you can't erase the SM/bootloader and if you do, you can put it back on easily.

I hope that that helps!

Fred.

_________________
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!


Wed May 11, 2011 6:21 pm
Profile WWW
TO220 - Visibile

Joined: Sun Mar 27, 2011 12:26 pm
Posts: 10
Location: Perth, Western Australia
Quote:
By third party I meant the use of a 3rd party library within the application that i write. I have purchased a design suite that does the gauges, charts, grids etc but it's a licensed application. Its a per machine compile license, so I can compile it, but others will not be able to ( unless they purchase the library ). Me compiling it is not an issue, as long as its ok with everyone else. Anyone running the compiled application is fine obviously.
Fred wrote:
OK, yeah, that is entirely up to you! Are you planning to keep the source open anyway such that others can poke around and suggest fixes/improvements? Open source is nice from a trust point of view too. I pretty much only install FOSS software on win/mac for that reason.

Source code will definately be open source to anyone who wants to have input, compiling may be on certain machines. Installation of the app will be available to everyone, which will be more than 90% of users.

Quote:
1. What is the purpose of the async comms?
Fred wrote:
Flexibility, reliability and speed.

Please correct any misconceptions I may have.
1. If all comms is initiated by the PC then async is not viable.
2. The periodic async comms from the ECU is what information exactly?
3. Its slightly concerning if you have the ECU connected to any multi drop bus and you are sending unsolicited messages. This all depends on what data is being sent periodically. If its a broadcast its fine ( ie CAN, ISO9141 etc ), if its a simple log of data that is not an automotive protocol then its an issue. If we are only ever going to use master/slave then forget this point altogether.
You guys may need to be a bit short/direct with me ( to keep me in line )on this point as I come from an environment where everything is compliance based, and sending unsolicated data is a big no no ( unless its an official automotive protocol broadcast ).

Quote:
2. Is anyone implementing a 32 bit CRC. I think this is important.
Fred wrote:
Data integrity checking is important, yes. But it only comes in percentages. IE, a simple checksum protects you X% of the time. A 16 bit CRC Y% of the time. A 32 bit CRC Z% of the time. The checksum is not the only method of data protection being used in this protocol. The simple checksum when combined with the other measures has proven to be completely reliable in practice. If switching to a more robust checksum style, speed is a consideration. I mean that in two ways:

1) Calculation cost on the embedded device.
2) Bandwidth cost for packets sent.

2 doesn't seem like an issue, but for very short packets, streaming a single byte at a high rate, packet overheads are already high, and a 32 bit checksum would really hurt samples per second.

16 bit CRC is definitely being considered, however not for a while, at least. A well written program will only require minor change if we migrate to a better checksum in future.

My apologies I had a brain freeze. I meant 16 bit CRC. I have C source code to handle if needed.

Quote:
3. Certain characters are escaped, has anyone thought about using a 2 byte start sequence? Also, if you use sync comms escaping is not necessary...
Fred wrote:
...and full bandwidth streaming not possible. Unlike a future checksum change, sync-only comms is NOT going to happen.

I understand that full bandwidth streaming is not possible. I may be naive in my point ( by not fully understanding the reasons behind whats being sent asynchronously ). Is it only logging data that is being sent without a request? Everything else is a challenge/response format?
Also, out of curiosity, what is the fastest rate you get?

Quote:
1. I have a working spin 1 that spits out the async data periodically ( looks like a data log of some sort ), so I assume that I have a working payload?
Fred wrote:
Yes, however I couldn't tell you what is in it, and if it's only periodically, then it's an old version.

I have attached a 5-6 second log. Converted to ASCII binary. The last block is incomplete. This was purely opening the port and reading.
Attachment:
[The extension txt has been deactivated and can no longer be displayed.]

Also, if someone has some time, could you please point out the header block and decipher it. I want to make sure I have it correct.

Quote:
2. Can someone please explain or post a link to how I update the firmware. I need to know what application/version to use to flash a s19 file.
Fred wrote:
We've done the best we can there. I'll let Sean know that you're waiting for him too.

OK

Quote:
3. I assume the payload sits atop the loader, so when you delete the payload you are left with the loader, which in turn reloads a payload?
Fred wrote:
By payload, do you mean firmware? If so, your sentence makes sense, however in light of other comms protocol discussion I had to read it several times to realise that. If I understand correctly, the answer is yes.

Yes payload means firmware. I will change my use of payload to firmware.

Quote:
4. The same comms protocol is used in the loader and payload?
Fred wrote:
Again, if you mean bootloader/serial monitor and firmware by loader and payload (we use loader to mean the pc side app) then the answer is no. The bootloader protocol is simpler and less robust. It's documented in AN2548 if you want to write a windows only loader app as a warm up exercise and because Sean's one isn't working just now.

Yes, loader is bootloader/serial monitor. Again i'll change my phrasing.
I will write a windows only bootloader. I may need some guidance as to how ( as in which ECU commands to use ) to delete the firmware and get the bootloader running.
Also I may need some help in translating the AN2548 doco if its very hardware specific. I don't do hardware very well.

Quote:
I don't want to get into a position where I can potentially brick the board so any gotchas are more than welcome :)
Fred wrote:
Bricking the board is not possible. If you don't have a BDM you can't erase the SM/bootloader and if you do, you can put it back on easily.

Fantastic. I do want to get myself a BDM programmer. Can you please suggest one that will work with this processor.

Fred wrote:
I hope that that helps!

Fred.

Definately.


Thu May 12, 2011 3:23 am
Profile
Moderator
User avatar

Joined: Tue Jan 15, 2008 2:31 pm
Posts: 15204
Location: Home sweet home!
Hi! Firstly, you've got to read the core comms spec doc, it explains a lot of this. Ditto the app note for the serial monitor/boot loader, it explains all aspects of that. In reading our core comms doc, if there are weaknesses, please bug me about them. That way the docs can get improved as we go. If I just answer questions here that are answered in that document, it doesn't benefit future implementers. That said, let me respond to your post.

eezo20v wrote:
Source code will definately be open source to anyone who wants to have input, compiling may be on certain machines. Installation of the app will be available to everyone, which will be more than 90% of users.

Excellent! :-)

Quote:
Quote:
1. What is the purpose of the async comms?
Fred wrote:
Flexibility, reliability and speed.

Please correct any misconceptions I may have.

I'll give it a shot :-)

Quote:
1. If all comms is initiated by the PC then async is not viable.

The comms is full duplex. The PC (or other device) can send a request in the middle of the stream and the stream will be interrupted in order to respond. Async is totally viable :-) In fact, due to the escaping and start/stop scheme, it's possible to use purely simple devices and apps to record the available streams, and/or request simple things, and decode and interpret them later with specific applications. This takes the burden away from any logging and recording devices and apps and places it at a less time critical point in the process.

Quote:
2. The periodic async comms from the ECU is what information exactly?

Datalog streams (various), error packets, warning packets, debug information, status information. Anything that the ecu wants to tell the world about (as opposed to being asked for information), and anything that benefits from being fast.

Quote:
3. Its slightly concerning if you have the ECU connected to any multi drop bus and you are sending unsolicited messages. This all depends on what data is being sent periodically. If its a broadcast its fine ( ie CAN, ISO9141 etc ), if its a simple log of data that is not an automotive protocol then its an issue. If we are only ever going to use master/slave then forget this point altogether.

UART is designed for point to point use, however there is nothing to stop multiple devices listening in. It would potentially be problematic to both apps if both were sending requests. If set up well, the two apps could actually coexist and only listen for packets with specific key ids, but there could still be collisions if that was being done, so I don't recommend it. As such it's not a problem to stream async stuff or send sporadic async messages of various kinds.

Quote:
You guys may need to be a bit short/direct with me ( to keep me in line )on this point as I come from an environment where everything is compliance based, and sending unsolicated data is a big no no ( unless its an official automotive protocol broadcast ).

I'm sure I can manage to do this for you! :-)

Quote:
My apologies I had a brain freeze. I meant 16 bit CRC. I have C source code to handle if needed.

Eventually, I'll probably migrate. It's just not a priority right now, and will sort the good coders from the bad when swapped to. I've got a few tricks up my sleeve to keep the speed up.

Quote:
I understand that full bandwidth streaming is not possible. I may be naive in my point ( by not fully understanding the reasons behind whats being sent asynchronously ).

When it comes to logging, not too many things are important. Accuracy, consistency, matching data, configurability, and last, but NOT least, SPEED! :-)

Quote:
Is it only logging data that is being sent without a request? Everything else is a challenge/response format?

No, see above, right now, yes, but in future, no, all sorts of things will get sent.

Quote:
Also, out of curiosity, what is the fastest rate you get?

1000 samples per second for a single 8 channel one byte port logger. IIRC about 40 per second of the full length default/basic log. A single channel analogue scope logger should deliver about 800 samples per second or there abouts. The shorter the log, the greater the benefit of the packetised scheme in async streaming mode.

Quote:
Also, if someone has some time, could you please point out the header block and decipher it. I want to make sure I have it correct.

The data payload is just three structs from the header files in the firmware source. The general rule for tuning app authors is:

1) Read any header
2) Do not read any source code

This way you will write your code to the interface description and specification, and not write to any quirks of the current implementation (which could change at any time).

For now, focus on decoding the packets properly, and decoding the header properly. Do it purely using the documentation. If docs are wrong, or even unclear, complain loudly here and we'll try to clarify or correct them ASAP. If you need some assistance with the raw packet decoding scheme, there is some default source code that I can point you at, however I'd do it very differently in an OO language. For now, have a crack at it without assistance. If you run into trouble and need help, let me know here.

Once you have that done, it would pay to make the break down of the actual datalog packets configurable such that they can be changed and improved over time without code changes to your app and an associated recompile that users (and me!) can't do.

Quote:
Quote:
2. Can someone please explain or post a link to how I update the firmware. I need to know what application/version to use to flash a s19 file.
Fred wrote:
We've done the best we can there. I'll let Sean know that you're waiting for him too.

OK

He's been putting some good work into it today, hooray. Hopefully we can get some good testing in in the next few days.

Quote:
I will write a windows only bootloader. I may need some guidance as to how ( as in which ECU commands to use ) to delete the firmware and get the bootloader running.
Also I may need some help in translating the AN2548 doco if its very hardware specific. I don't do hardware very well.

Read the app note, it explains how the SM works. Simply, you flick a hw switch, and on reset the sm reads the port and if its one state holds control, and if another hands over control to the "user code" aka firmware. Reset can be done over the serial line from either SM or firmware. See the core comms docs for details on that when the firmware is running and the ./lib/test.packets/serial.monitor.dir/*.bin files for when the SM is running. (there is a reset packet there)

Quote:
I do want to get myself a BDM programmer. Can you please suggest one that will work with this processor.

There are a number of choices. There is on that Tech Arts sells for 50usd that is all open source, I'd get that if I were getting one, but I already have another.

Good luck! Don't forget to:

A) use git (github is nice), not svn, svn is not appropriate for distributed open source development IMO.
B) post test binaries for people to play with as often as you can be bothered (I have an XP VM for example)
C) post screen shots of progress
D) post on the forum about progress (you're doing great so far!)

Fred.

_________________
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!


Thu May 12, 2011 6:14 am
Profile WWW
1N4001 - Signed up
User avatar

Joined: Tue Jun 10, 2008 5:17 pm
Posts: 1607
So I recall I could not uninstall the official 32 bit debs. I seem to recall it appeared they were configured via apt-get, and that typical tools like simplicity couldn't remove them, as those debs didn't follow typical Ubuntu practices. The 64 bit didn't work because those debs definitely didn't follow Ubuntu practices.

So, the Fred proclaimed "official" location has known issues that go unresolved, by official mechanism, as Fred doesn't have time to find some unimportant problem with the debs that do work. However he has time to remove posts about the packages that do work. Makes perfect sense to me....

eezo20v if you would like those notes about how to get it up and running on a Ubuntu machine, let me know and I'll make sure you can compile a current firmware. Also if you can get it to compile on a windows machine, please let us know. We have not had people verify that the windows compile environment actually works. I tried a month or so ago and failed. Supposedly I failed because the instructions on tools.diyefi.org were wrong or something like that. The packages installed just fine, but I couldn't use them to create an S19 firmware file. Shrug, perhaps that fixed now. I don't think so, as it's just an executable and the one I have, has the same name as the one I would download today.


Thu May 12, 2011 12:03 pm
Profile
Display posts from previous:  Sort by  
Reply to topic   [ 16 posts ]  Go to page 1, 2  Next

Who is online

Users browsing this forum: No registered users and 3 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software for PTF. ColorizeIt.