I have a I2C display from a broken car radio device, I want to use it on my own device.
The display is working because I have some i2c traces before the radio totally dies, with this data I only know how to set memory offset and turn on/off segments, so basically is working, in fact, I'm able to display text, but I have a problem that from time to time the i2c bus got stuck writing to the display, so, I have to disable and re-enable the display with the enable pin (named by me, maybe is a reset pin), to do this I have to put a watchdog on my system because it hangs on isI2CAck.
I need some kind of help to identify the controller on this display, I already check some datasheets but none of them match this display commands, the inscriptions on the backside got no results searching on the net, and I can't see anything on the display glass (sometimes, there are some codes between the glasses, but nothing in this one).
Segments: 256 (memory positions 32bytes*8bits, 249 on the crystal)
I2C Addr: 0x70
Pinout (front view, no pin number, Left to Right): Vcc, Gnd, Gnd, Enable, SCL, SDA
From radio i2c dump
Init:
I2CAddr, 0x00, 0x00, 0x00
I2CAddr, 0x00, 0xC0, 0x03
Set memory position:
I2CAddr, 0x00, 0xDC, position (0-31)
Set memory data:
I2CAddr, 0x40, data, data, data, ...
Found by myself
Some kind of blink:
I2CAddr, 0x00, 0xC0, 0xFn //n= 0 blink off, 1 blink fast, 2 blink faster
Some kind of contrast or pump charger:
I2CAddr, 0x00, 0xC0, 0xC8 *Low contrast, 0xC8 or 0xD8*
I2CAddr, 0x00, 0xC0, 0xCC *High contrast, 0xCC or 0xDC*
Some kind of recover or a Soft reset:
I2CAddr, 0x00, 0xC0, 0xE0
Display - All Segments On - Image
Back side of display - Image
Found inscriptions:
8345-LED-B-(A161)130401/ROHS/2*2
B2013050034(?)
132569330
Edit:
The stereo was from a Renault Clio car and is a Read Only device,got nACK when I2CWrite( I2CADDR + 1).
Maybe somebody search for the same display and maybe somebody find another commands.
Related
I´ve got a JavaCard (SmartMX) with emulated DESFire EV2 and want to get both Uid´s from DESFire and JavaCard.
Therefor I´ve found the following APDU command:
0xFF, 0xCA, 0x00, 0x00, 0x00
But only get the DESFire Uid. May someone tell how to retreive the JavaCard Uid?
I´m using PCSC Lib together with C# .net5.
The documentation is saying, that the first protokoll which is called will be proceed. Therefor I´ve tried to read JavaCard free memory with APDU:
0x00, 0xB0, 0x00, 0x00, 0x02
But after again calling GetUid I´ve received again the DESFire CSN/Uid. May someone also tell which format a JavaCard´s Uid has?
But only get the DESFire Uid. May someone tell how to retreive the JavaCard Uid?
NXP SmartMX has ISO 14443 type A communication. UID value appears during initialization phase of the contactless protocol
(see ANTICOLLISION and SELECT commands in ISO 14443-3). It's before branching between protocols (Mifare and JavaCard protocols).
Protocol type A initialization is common for both Mifare and JavaCard. There is no special value for Mifare and special value for JavaCard.
Therefore, chip can have only one UID value for all protocols.
May someone also tell which format a JavaCard´s Uid has?
As far as I know UID in JCOP cards is configurable until the card is fused. There are several acceptable formats of UID. See your chip datasheet for exact information. Sometimes UID can be random.
When a diagnostic tool is connected to the server it gets the the DTC.
I want to know how the DTC data is defined and stored in the ECU.
DTC codes are usually defined as 2-byte or 3-byte values.
A common representation following ISO 15031-6/SAE J2012 is as five-character alphanumeric code (ie. P0001) with the optional low-byte appended as hexadecimal value (ie. P0001-00). The first letter being either: P for Powertrain (00b, highest bits on highest byte), C for Chassis (01b), B for Body (10b) or U for Network related DTCs (11b). ie.
P0001 (Fuel Volume Regulator Control Circuit/Open) would be represented as bytes: 0x00 0x01
P0A01 (Range/Performance) would be represented as bytes: 0x0A 0x01
C0001 (TCS Control Channel A Valve 1) would be represented as bytes: 0x40 0x01
The DTCs are stored as their respective byte representation in Non-volatile memory (NvM) of the ECU, so that it can be retrieved even if the ECU has been power cycled. Along with the DTC additional information will be stored, i.e. Freeze frame/environmental data, DTC status mask (pendingDTC/confirmedDTC/...), counter (aging/debouncing), time of first occurence, etc.
I'm currently planning out the code for a Bluetooth low energy (BLE) device that will operate on the HID over GATT profile from the bluetooth specification. I've read through the HID specification 1.11 and the Usage Tables 1.12, but I can't find anything about the minimum required use of Usage_pages and Usages.
Since we're implementing both the host and device, the plan is to use a vendor defined usage page for our report descriptor, but since our goal is to have fast connections and low power consumption, I don't want to send more bytes than I have to in the report definition phase of HID over GATT. Because of this, I'm considering removing all usages that would normally tag an input/output since they only seem semantic.
Here's a sample of what I'm considering:
Usage_Page( Vendor Defined)
Usage( Vendor 1)
Collection(Application)
Collection(Logical) ; First Collection and Report
Report_ID(1)
Usage_Page(Button) ; This is what the specification seems to encourage
Usage_Minimum(Button 1)
Usage_Maximum(Button 3)
Logical_Minimum(0) ; Logical limits
Logical_Maximum(1)
Report_Size(3) ; Three bits corresponding to the buttons
Report_Count(1) ; One of the three bit sets
Input( Data, Variable, Absolute) ; Make it an input
Report_Size(5)
Report_Count(1)
Input(Constant) ; Pad the transmitted byte
Collection End
Collection End
When I look at the this, I see a lot of extra bytes that do nothing since I'm not using a native parser. These range from Usages to even logical minimums/maximums. What consequences would there be if I just defined my report descriptor with only the top-level usage and no use of things like logical maximums?
A compliant parser should accept the following optimized descriptor:
0x85, 0x01, // ReportID (1)
0x05, 0xff, // UsagePage (255)
0x09, 0x01, // Usage (1)
0xa1, 0x01, // Collection (Application)
0x25, 0x01, // LogicalMaximum (1)
0x75, 0x01, // ReportSize (1)
0x05, 0x09, // UsagePage (Button)
0x19, 0x01, // UsageMinimum (Button(1))
0x29, 0x03, // UsageMaximum (Button(3))
0x95, 0x03, // ReportCount (3)
0x81, 0x02, // Input (Variable)
0xc0, // EndCollection
logical minimum defaults to 0,
padding at the end of last byte comes for free.
Also note all Central-side implementations (Win, Bluez, CoreBluetooth, and Bluedroid) of HoG actually cache the report descriptor when pairing occurs in order to minimize the reconnection time. So, the actual size of the report descriptor is not that important: it will only take time once upon pairing, and probably never again (until device is paired again of course).
Also consider the report descriptor reading represents a few packets exchanged between central and peripheral (one every 20 bytes with a default MTU), each round-trip costs two intervals (if both stack implementations are not too bad), which will be around 60 ms (most centrals connect with a default interval to ~30 ms). So the actual discovery latency will be less than 200 ms longer when your report descriptor is 60 bytes longer... It is not a big deal for something that happens only once in the life of the device.
Lastly, a side note: You should probably not use a vendor-specific collection type, but try to stick to standard ones. It will allow driverless operation of your device in most cases.
Don’t forget that even if you only foresee an application-specific usage of your hardware, some people may actually be happy to reuse it for something else. If so, driverless is better, unless you want to forbid third part usage at all, but there is no point using HID in the first place. (HID was designed for driverless operation, and I'm still puzzled to see drivers for mice and gamepads, remote controls and push buttons just because of the maker's laziness.)
I am using a Raspberry Pi (linux kernel 4.4) and "libusb" to read the steering angle of a Logitech G29 HID Device (PS3 mode). I get only one byte of data for the angle and that is far to little for the steering range of +-450° deg. The HID Device Descriptor shows the problem.
Item(Global): Physical Maximum, data= [ 0xff 0x00 ] 255
How could I change the Physical Maximum to 65535?
Why do you think that a number from 0 to 255 cannot be used to represent angles between -450 and +450? Isn't it possible that a value of 0 corresponds to -450 degrees and a value of 255 corresponds to 455 degrees? It's very unlikely that Logitech made a fatal design flaw in the HID interface of their device.
If you really want to change the HID interface, then, at a minimum, you would have to reprogram the firmware of your G29 device in order to change that descriptor and change the HID report it describes. It is very likely that the device is closed source and that there are no instructions for reprogramming the firmware, so you are probably out of luck. Adding more resolution to that measurement might also require hardware changes, which could be difficult.
I'm new to embedded devices and am trying to understand how to use i2cget (or the entire I2C protocol really).
I'm using an accelerometer MMA8452, and the datasheet says the Slave Address is 0x1D (if my SAO=1, which I believe is referring to the I2C bus being on channel 1 on my raspberrypi v2).
From the command line, I enter
sudo i2cget -y 1 0X1d
It returns
0X00
I think that means I'm attached to the correct device.
So now, I'm trying to figure out how do I get actual data back from the accelerometer?
The i2c spec says
i2cget [-y] i2cbus chip-address [data-address [mode]]
So I have tried
sudo i2cget -y 1 0x1D 0x01
where 0x01 is the OUT_X_MSB. I'm not sure entirely what I'm expecting to get back, but I figured if I saw some data other than 0x00, I might be able to figure that out.
Am I using ic2get wrong? Is there a better way to learn and get data from i2c?
The datasheet for my accelerometer chip is at
http://dlnmh9ip6v2uc.cloudfront.net/datasheets/Sensors/Accelerometers/MMA8452Q.pdf
I am way too late but this might help other people. You might be getting the 0x00 output every time you use i2cget is because you might have forgotten to set some mode. For instance, I was working on pcf8583 which is a clock and calendar chip and can also be use as a counter.
My goal was to use this chip as a counter. It was connected to i2cbus1 with device address 0x51. So reading the data sheet, I found out that, the chip would work as a counter when the mode is set to 0x20 in the control register 0x00. The command I used for doing this:
i2cset 1 0x51 0x00 0x20
Now, I could read the counter pulses from a wind sensor with the command:
watch i2cget -y 1 0x51
watch is just a linux command that runs the specified command (i2cget) repeatedly every 2 seconds and displays the results on standard output.
From the datasheet its clear that the default value of Status Register Address 0x00 is 0x00, so you are doing fine I guess. See Table 11 Register Map Address in the datasheet.
You may try reading the device ID at Register Address 0x0D. You should get value 0x2A when you read this register(0x0D).