Search found 883 matches
- Fri Mar 22, 2024 10:48 am
- Forum: Bug Reports
- Topic: Lookup table resizing.
- Replies: 4
- Views: 670
Re: Lookup table resizing.
Ok - I'll replace the spaces with commas - odd that it works for the original data block - which also uses spaces....
- Fri Mar 22, 2024 5:42 am
- Forum: Bug Reports
- Topic: Lookup table resizing.
- Replies: 4
- Views: 670
Re: Lookup table resizing.
Yes - a table of 8 bit values.
Not sure if size is limited but the initial size shows correctly and in simulation (which is all that is needed here) seems to work correctly (although I didn't single step through it all - and the simulation locked when I altered the rate slider)
Martin
Not sure if size is limited but the initial size shows correctly and in simulation (which is all that is needed here) seems to work correctly (although I didn't single step through it all - and the simulation locked when I altered the rate slider)
Martin
- Thu Mar 21, 2024 9:16 pm
- Forum: Bug Reports
- Topic: Lookup table resizing.
- Replies: 4
- Views: 670
Lookup table resizing.
I hit a small issue resizing a lookup table (in an Arduino sketch - though this might not be relevant) I created an 8 bit lookup table and pasted in 4637 values - this was correctly reflected in the num values field. However - to create a simpler 'demo' version of my program I then replaced these va...
- Thu Mar 21, 2024 9:08 pm
- Forum: General
- Topic: Protocol j1587
- Replies: 80
- Views: 7229
Re: Protocol j1587
A version that allows multiple 'message blocks' to be read:
Here allowing MIDs of 128 and 144.
Here allowing MIDs of 128 and 144.
- Thu Mar 21, 2024 11:01 am
- Forum: General
- Topic: Protocol j1587
- Replies: 80
- Views: 7229
Re: Protocol j1587
Yes, and no.
It actually stores a 16bit sum - the twos complement of this (% 256) needs to be 0.
Martin
It actually stores a 16bit sum - the twos complement of this (% 256) needs to be 0.
Martin
- Thu Mar 21, 2024 9:30 am
- Forum: General
- Topic: Protocol j1587
- Replies: 80
- Views: 7229
Re: Protocol j1587
The reset needs the checksum resetting too. So will only receive one message as is...
V2. 0 this evening
V2. 0 this evening
- Wed Mar 20, 2024 10:49 pm
- Forum: General
- Topic: Protocol j1587
- Replies: 80
- Views: 7229
Re: Protocol j1587
Regarding the row of two byte PIDs, for example: engine speed - PID 190, data 087 009 - PID_data[0] /; 087;/ + (PID_data[1] /;009;/<<8) I get a 16-bit value and multiply it by 0.25 (res/bit) So - the PID - get from PID[0] - if this is >= 128 then the 16 bit value is PID_Data[0] ( NOT PID_Data[0] + ...
- Wed Mar 20, 2024 4:30 pm
- Forum: General
- Topic: Protocol j1587
- Replies: 80
- Views: 7229
Re: Protocol j1587
Let us know how it goes... Remote debugging is notoriously tricky :cry: I think the one piece of error checking it needs is to check the length of the message - if it's greater than 21 bytes then reset and start looking for MID again. As it stands - is the end isn't found then it will trample over m...
- Wed Mar 20, 2024 2:48 pm
- Forum: General
- Topic: Protocol j1587
- Replies: 80
- Views: 7229
Re: Protocol j1587
This was my first attempt.. It works in simulation for the 'dummy' data (one row of above table) - it assumes that the checksum condition is met to end the input... Output is a table of PIDs (PID[]) and a table of the data values for each PID (PID_Data[]) It assumes that PIDs of 0..127 have one byte...
- Tue Mar 19, 2024 11:20 pm
- Forum: General
- Topic: Protocol j1587
- Replies: 80
- Views: 7229
Re: Protocol j1587
We need to look at a 'slightly smarter' read - need a way to check the length of each data block and also when the end of the current data is received. This is the checksum byte - but how to know that this is the end of the data and not another PID? So it looks like PIDs are in a range of values (wi...