Hardware hacking OVMS v2 for fun and profit
Over the past year or so, I've had a few people ask me the same sort of question, so thought a single reply here would help.
On the v2 module circuit board there is a unpopulated 9x2 set of holes in the board. You can see it on the attached picture, between the crystal and LEDs.
You can either solder directly to this, or use a header plug/socket arrangement. All the unused pins from the PIC are brought out via that header, as well as GND, +5V and +12V. There are several free analog input pins, as well as digital input/output pins available for expansion. They are all 5V TTL level.
If someone wants to use these for something, I suggest you code utils.h/utils.c to provide a function to initialise and control the required ports. Just try to make it fairly non-specific so it is of some use to others. Then, the vehicle module can just call the appropriate utils.c function, presumably in response to an SMS / net_msg command.
For bi-directional sync/async comms, things are a little bit more tricky. The I2C pins are used by the LEDs, so you would have to sacrifice those and hack the code to use I2C. You could in theory do a software async, but I think that would be tricky. The DIAG port is just a tap between the PIC and the modem. Probably the best, for something sophisticated, is to use the CAN bus.
Regards, Mark.
Hi all,
I see there is currently some HW discussion ongoing, so I'm picking up this post again:
I want to implement the doorlock control for Think City (vehicle_thinkcity.c) to the app.
The problem is that the module controlling the door locks (General Electric Module from Ford, part 17ST-15K600-KB) uses K-line only. I think the door lock switch can be triggered (K-line style) with request 22 A1 45 which returns 62 A1 45 40 for lock or 62 A1 45 80 for unlock. I have tried to address via other ECU's which also talk k-line, but with no success.
The GEM lock switch can be triggered by applying a gnd-pulse to the lock/unlock switch input. The pin voltage measure about 3,5V when no gnd is applied.
My current idea for solution is using RB4 and RB5 on the OVMS 9x2, connect it to the GEM unlock switch and GEM lock switch. The question is:
Do I need a transceiver between the Ovms-module (RB4/RB5) and the GEM-module (unlock/lock switch) for protection? If yes, any suggestions of type/device?
Are there anybody with the knowledge (and time) to re-write the utility.c/utility.h so the vehicle specific files can utilize the extra pins (RB4/RB5 for my case)?
Anybody with a better solution?
Best regards Håkon Markussen
2013/8/24 Mark Webb-Johnson <mark@webb-johnson.net>
Over the past year or so, I've had a few people ask me the same sort of question, so thought a single reply here would help.
On the v2 module circuit board there is a unpopulated 9x2 set of holes in the board. You can see it on the attached picture, between the crystal and LEDs.
You can either solder directly to this, or use a header plug/socket arrangement. All the unused pins from the PIC are brought out via that header, as well as GND, +5V and +12V. There are several free analog input pins, as well as digital input/output pins available for expansion. They are all 5V TTL level.
If someone wants to use these for something, I suggest you code utils.h/utils.c to provide a function to initialise and control the required ports. Just try to make it fairly non-specific so it is of some use to others. Then, the vehicle module can just call the appropriate utils.c function, presumably in response to an SMS / net_msg command.
For bi-directional sync/async comms, things are a little bit more tricky. The I2C pins are used by the LEDs, so you would have to sacrifice those and hack the code to use I2C. You could in theory do a software async, but I think that would be tricky. The DIAG port is just a tap between the PIC and the modem. Probably the best, for something sophisticated, is to use the CAN bus.
Regards, Mark.
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Hi, for the K stuff: K line is just an async serial, at battery levels, at 10400bps 8n1. should be very easy to control from OVMS, with a mosfet on a serial TX pin for output, if there's a free UART. About the switches, if they are low current push buttons connected to the ECU that just short to ground, you can easily use any mosfet (2n7000 is my favourite) to "buffer" the PIC output. You will just need to connect the Source pin to ground, the Drain to the other side of the button, and the gate to the PIC pin, with a 1K to 10K resistor to ground. I'd go with that option. About the software, I haven't enough experience to help you, sorry. Regards MG
2013/9/4 Håkon Markussen <hakon.markussen@gmail.com>
Hi all,
I see there is currently some HW discussion ongoing, so I'm picking up this post again:
I want to implement the doorlock control for Think City (vehicle_thinkcity.c) to the app.
The problem is that the module controlling the door locks (General Electric Module from Ford, part 17ST-15K600-KB) uses K-line only. I think the door lock switch can be triggered (K-line style) with request 22 A1 45 which returns 62 A1 45 40 for lock or 62 A1 45 80 for unlock. I have tried to address via other ECU's which also talk k-line, but with no success.
The GEM lock switch can be triggered by applying a gnd-pulse to the lock/unlock switch input. The pin voltage measure about 3,5V when no gnd is applied.
My current idea for solution is using RB4 and RB5 on the OVMS 9x2, connect it to the GEM unlock switch and GEM lock switch. The question is:
Do I need a transceiver between the Ovms-module (RB4/RB5) and the GEM-module (unlock/lock switch) for protection? If yes, any suggestions of type/device?
Are there anybody with the knowledge (and time) to re-write the utility.c/utility.h so the vehicle specific files can utilize the extra pins (RB4/RB5 for my case)?
Anybody with a better solution?
Best regards Håkon Markussen
2013/8/24 Mark Webb-Johnson <mark@webb-johnson.net>
Over the past year or so, I've had a few people ask me the same sort of question, so thought a single reply here would help.
On the v2 module circuit board there is a unpopulated 9x2 set of holes in the board. You can see it on the attached picture, between the crystal and LEDs.
You can either solder directly to this, or use a header plug/socket arrangement. All the unused pins from the PIC are brought out via that header, as well as GND, +5V and +12V. There are several free analog input pins, as well as digital input/output pins available for expansion. They are all 5V TTL level.
If someone wants to use these for something, I suggest you code utils.h/utils.c to provide a function to initialise and control the required ports. Just try to make it fairly non-specific so it is of some use to others. Then, the vehicle module can just call the appropriate utils.c function, presumably in response to an SMS / net_msg command.
For bi-directional sync/async comms, things are a little bit more tricky. The I2C pins are used by the LEDs, so you would have to sacrifice those and hack the code to use I2C. You could in theory do a software async, but I think that would be tricky. The DIAG port is just a tap between the PIC and the modem. Probably the best, for something sophisticated, is to use the CAN bus.
Regards, Mark.
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Unfortunately, no free UART on the low-end PIC18 we are using. We could do a software UART, but given all the other stuff going on, that would concern me.
I don't mind adding some stuff to utils.{c,h} for controlling digital outputs, if you want to go that route.
Regards, Mark.
On 4 Sep, 2013, at 10:13 PM, Mastro Gippo <gipmad@gmail.com> wrote:
Hi, for the K stuff: K line is just an async serial, at battery levels, at 10400bps 8n1. should be very easy to control from OVMS, with a mosfet on a serial TX pin for output, if there's a free UART. About the switches, if they are low current push buttons connected to the ECU that just short to ground, you can easily use any mosfet (2n7000 is my favourite) to "buffer" the PIC output. You will just need to connect the Source pin to ground, the Drain to the other side of the button, and the gate to the PIC pin, with a 1K to 10K resistor to ground. I'd go with that option. About the software, I haven't enough experience to help you, sorry. Regards MG
2013/9/4 Håkon Markussen <hakon.markussen@gmail.com> Hi all,
I see there is currently some HW discussion ongoing, so I'm picking up this post again:
I want to implement the doorlock control for Think City (vehicle_thinkcity.c) to the app.
The problem is that the module controlling the door locks (General Electric Module from Ford, part 17ST-15K600-KB) uses K-line only. I think the door lock switch can be triggered (K-line style) with request 22 A1 45 which returns 62 A1 45 40 for lock or 62 A1 45 80 for unlock. I have tried to address via other ECU's which also talk k-line, but with no success.
The GEM lock switch can be triggered by applying a gnd-pulse to the lock/unlock switch input. The pin voltage measure about 3,5V when no gnd is applied.
My current idea for solution is using RB4 and RB5 on the OVMS 9x2, connect it to the GEM unlock switch and GEM lock switch. The question is:
Do I need a transceiver between the Ovms-module (RB4/RB5) and the GEM-module (unlock/lock switch) for protection? If yes, any suggestions of type/device?
Are there anybody with the knowledge (and time) to re-write the utility.c/utility.h so the vehicle specific files can utilize the extra pins (RB4/RB5 for my case)?
Anybody with a better solution?
Best regards Håkon Markussen
2013/8/24 Mark Webb-Johnson <mark@webb-johnson.net>
Over the past year or so, I've had a few people ask me the same sort of question, so thought a single reply here would help.
On the v2 module circuit board there is a unpopulated 9x2 set of holes in the board. You can see it on the attached picture, between the crystal and LEDs.
You can either solder directly to this, or use a header plug/socket arrangement. All the unused pins from the PIC are brought out via that header, as well as GND, +5V and +12V. There are several free analog input pins, as well as digital input/output pins available for expansion. They are all 5V TTL level.
If someone wants to use these for something, I suggest you code utils.h/utils.c to provide a function to initialise and control the required ports. Just try to make it fairly non-specific so it is of some use to others. Then, the vehicle module can just call the appropriate utils.c function, presumably in response to an SMS / net_msg command.
For bi-directional sync/async comms, things are a little bit more tricky. The I2C pins are used by the LEDs, so you would have to sacrifice those and hack the code to use I2C. You could in theory do a software async, but I think that would be tricky. The DIAG port is just a tap between the PIC and the modem. Probably the best, for something sophisticated, is to use the CAN bus.
Regards, Mark.
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
I'm sorry that my programming skills are not the best and have to ask about this. But to get this baby going I need some more detailed help.
In the utils.c (and utils.h) can I add two functions, and then call them from the vehicle-specific? One function (lock) sets RB4 high for 500ms and the other fuction (unlock) sets RB5 high for 500ms.
Do you think this will work?
void send_lock(void) { // Check if RB4 is low, set RB4 high for 500ms and back to low if (PORTBbits.RB4 == 0) { PORTBbits.RB4 = 1; delay100(5); PORTBbits.RB4= 0; }
void send_unlock(void) { // Check if RB4 is low, set RB4 high for 500ms and back to low if (PORTBbits.RB5 == 0) { PORTBbits.RB5 = 1; delay100(5); PORTBbits.RB5 = 0; }
Br. Håkon
2013/9/5 Mark Webb-Johnson <mark@webb-johnson.net>
Unfortunately, no free UART on the low-end PIC18 we are using. We could do a software UART, but given all the other stuff going on, that would concern me.
I don't mind adding some stuff to utils.{c,h} for controlling digital outputs, if you want to go that route.
Regards, Mark.
On 4 Sep, 2013, at 10:13 PM, Mastro Gippo <gipmad@gmail.com> wrote:
Hi, for the K stuff: K line is just an async serial, at battery levels, at 10400bps 8n1. should be very easy to control from OVMS, with a mosfet on a serial TX pin for output, if there's a free UART. About the switches, if they are low current push buttons connected to the ECU that just short to ground, you can easily use any mosfet (2n7000 is my favourite) to "buffer" the PIC output. You will just need to connect the Source pin to ground, the Drain to the other side of the button, and the gate to the PIC pin, with a 1K to 10K resistor to ground. I'd go with that option. About the software, I haven't enough experience to help you, sorry. Regards MG
2013/9/4 Håkon Markussen <hakon.markussen@gmail.com>
Hi all,
I see there is currently some HW discussion ongoing, so I'm picking up this post again:
I want to implement the doorlock control for Think City (vehicle_thinkcity.c) to the app.
The problem is that the module controlling the door locks (General Electric Module from Ford, part 17ST-15K600-KB) uses K-line only. I think the door lock switch can be triggered (K-line style) with request 22 A1 45 which returns 62 A1 45 40 for lock or 62 A1 45 80 for unlock. I have tried to address via other ECU's which also talk k-line, but with no success.
The GEM lock switch can be triggered by applying a gnd-pulse to the lock/unlock switch input. The pin voltage measure about 3,5V when no gnd is applied.
My current idea for solution is using RB4 and RB5 on the OVMS 9x2, connect it to the GEM unlock switch and GEM lock switch. The question is:
Do I need a transceiver between the Ovms-module (RB4/RB5) and the GEM-module (unlock/lock switch) for protection? If yes, any suggestions of type/device?
Are there anybody with the knowledge (and time) to re-write the utility.c/utility.h so the vehicle specific files can utilize the extra pins (RB4/RB5 for my case)?
Anybody with a better solution?
Best regards Håkon Markussen
2013/8/24 Mark Webb-Johnson <mark@webb-johnson.net>
Over the past year or so, I've had a few people ask me the same sort of question, so thought a single reply here would help.
On the v2 module circuit board there is a unpopulated 9x2 set of holes in the board. You can see it on the attached picture, between the crystal and LEDs.
You can either solder directly to this, or use a header plug/socket arrangement. All the unused pins from the PIC are brought out via that header, as well as GND, +5V and +12V. There are several free analog input pins, as well as digital input/output pins available for expansion. They are all 5V TTL level.
If someone wants to use these for something, I suggest you code utils.h/utils.c to provide a function to initialise and control the required ports. Just try to make it fairly non-specific so it is of some use to others. Then, the vehicle module can just call the appropriate utils.c function, presumably in response to an SMS / net_msg command.
For bi-directional sync/async comms, things are a little bit more tricky. The I2C pins are used by the LEDs, so you would have to sacrifice those and hack the code to use I2C. You could in theory do a software async, but I think that would be tricky. The DIAG port is just a tap between the PIC and the modem. Probably the best, for something sophisticated, is to use the CAN bus.
Regards, Mark.
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Håkon,
I think I'd like to keep utils.{h,c} simple. Just have standardised functions to set the digital output on/off.
void io_digital_set(port, onoff); unsigned char io_digital_get(port);
Then, put the logic for how it is used in the vehicle module itself.
if (io_digital_get(4)==0) { io_digital_set(4,1); delay100(5); io_digital_set(4,0); }
We would also need to initialise the ports in the correct way, and standardise what ports are used for input and what for output. I will look at this later tonight.
Regards, Mark.
On 5 Sep, 2013, at 3:14 PM, Håkon Markussen <hakon.markussen@gmail.com> wrote:
I'm sorry that my programming skills are not the best and have to ask about this. But to get this baby going I need some more detailed help.
In the utils.c (and utils.h) can I add two functions, and then call them from the vehicle-specific? One function (lock) sets RB4 high for 500ms and the other fuction (unlock) sets RB5 high for 500ms.
Do you think this will work?
void send_lock(void) { // Check if RB4 is low, set RB4 high for 500ms and back to low if (PORTBbits.RB4 == 0) { PORTBbits.RB4 = 1; delay100(5); PORTBbits.RB4= 0; }
void send_unlock(void) { // Check if RB4 is low, set RB4 high for 500ms and back to low if (PORTBbits.RB5 == 0) { PORTBbits.RB5 = 1; delay100(5); PORTBbits.RB5 = 0; }
Br. Håkon
2013/9/5 Mark Webb-Johnson <mark@webb-johnson.net> Unfortunately, no free UART on the low-end PIC18 we are using. We could do a software UART, but given all the other stuff going on, that would concern me.
I don't mind adding some stuff to utils.{c,h} for controlling digital outputs, if you want to go that route.
Regards, Mark.
On 4 Sep, 2013, at 10:13 PM, Mastro Gippo <gipmad@gmail.com> wrote:
Hi, for the K stuff: K line is just an async serial, at battery levels, at 10400bps 8n1. should be very easy to control from OVMS, with a mosfet on a serial TX pin for output, if there's a free UART. About the switches, if they are low current push buttons connected to the ECU that just short to ground, you can easily use any mosfet (2n7000 is my favourite) to "buffer" the PIC output. You will just need to connect the Source pin to ground, the Drain to the other side of the button, and the gate to the PIC pin, with a 1K to 10K resistor to ground. I'd go with that option. About the software, I haven't enough experience to help you, sorry. Regards MG
2013/9/4 Håkon Markussen <hakon.markussen@gmail.com> Hi all,
I see there is currently some HW discussion ongoing, so I'm picking up this post again:
I want to implement the doorlock control for Think City (vehicle_thinkcity.c) to the app.
The problem is that the module controlling the door locks (General Electric Module from Ford, part 17ST-15K600-KB) uses K-line only. I think the door lock switch can be triggered (K-line style) with request 22 A1 45 which returns 62 A1 45 40 for lock or 62 A1 45 80 for unlock. I have tried to address via other ECU's which also talk k-line, but with no success.
The GEM lock switch can be triggered by applying a gnd-pulse to the lock/unlock switch input. The pin voltage measure about 3,5V when no gnd is applied.
My current idea for solution is using RB4 and RB5 on the OVMS 9x2, connect it to the GEM unlock switch and GEM lock switch. The question is:
Do I need a transceiver between the Ovms-module (RB4/RB5) and the GEM-module (unlock/lock switch) for protection? If yes, any suggestions of type/device?
Are there anybody with the knowledge (and time) to re-write the utility.c/utility.h so the vehicle specific files can utilize the extra pins (RB4/RB5 for my case)?
Anybody with a better solution?
Best regards Håkon Markussen
2013/8/24 Mark Webb-Johnson <mark@webb-johnson.net>
Over the past year or so, I've had a few people ask me the same sort of question, so thought a single reply here would help.
On the v2 module circuit board there is a unpopulated 9x2 set of holes in the board. You can see it on the attached picture, between the crystal and LEDs.
You can either solder directly to this, or use a header plug/socket arrangement. All the unused pins from the PIC are brought out via that header, as well as GND, +5V and +12V. There are several free analog input pins, as well as digital input/output pins available for expansion. They are all 5V TTL level.
If someone wants to use these for something, I suggest you code utils.h/utils.c to provide a function to initialise and control the required ports. Just try to make it fairly non-specific so it is of some use to others. Then, the vehicle module can just call the appropriate utils.c function, presumably in response to an SMS / net_msg command.
For bi-directional sync/async comms, things are a little bit more tricky. The I2C pins are used by the LEDs, so you would have to sacrifice those and hack the code to use I2C. You could in theory do a software async, but I think that would be tricky. The DIAG port is just a tap between the PIC and the modem. Probably the best, for something sophisticated, is to use the CAN bus.
Regards, Mark.
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Hi,
i don't like this:
delay100(5); in a "real Time System"
Better to put a sub in an timer/interrupt routine. I think we have enough timer.
Bye Michael
Am 05.09.2013 um 10:29 schrieb Mark Webb-Johnson <mark@webb-johnson.net>:
Håkon,
I think I'd like to keep utils.{h,c} simple. Just have standardised functions to set the digital output on/off.
void io_digital_set(port, onoff); unsigned char io_digital_get(port);
Then, put the logic for how it is used in the vehicle module itself.
if (io_digital_get(4)==0) { io_digital_set(4,1); delay100(5); io_digital_set(4,0); }
We would also need to initialise the ports in the correct way, and standardise what ports are used for input and what for output. I will look at this later tonight.
Regards, Mark.
On 5 Sep, 2013, at 3:14 PM, Håkon Markussen <hakon.markussen@gmail.com> wrote:
I'm sorry that my programming skills are not the best and have to ask about this. But to get this baby going I need some more detailed help.
In the utils.c (and utils.h) can I add two functions, and then call them from the vehicle-specific? One function (lock) sets RB4 high for 500ms and the other fuction (unlock) sets RB5 high for 500ms.
Do you think this will work?
void send_lock(void) { // Check if RB4 is low, set RB4 high for 500ms and back to low if (PORTBbits.RB4 == 0) { PORTBbits.RB4 = 1; delay100(5); PORTBbits.RB4= 0; }
void send_unlock(void) { // Check if RB4 is low, set RB4 high for 500ms and back to low if (PORTBbits.RB5 == 0) { PORTBbits.RB5 = 1; delay100(5); PORTBbits.RB5 = 0; }
Br. Håkon
2013/9/5 Mark Webb-Johnson <mark@webb-johnson.net> Unfortunately, no free UART on the low-end PIC18 we are using. We could do a software UART, but given all the other stuff going on, that would concern me.
I don't mind adding some stuff to utils.{c,h} for controlling digital outputs, if you want to go that route.
Regards, Mark.
On 4 Sep, 2013, at 10:13 PM, Mastro Gippo <gipmad@gmail.com> wrote:
Hi, for the K stuff: K line is just an async serial, at battery levels, at 10400bps 8n1. should be very easy to control from OVMS, with a mosfet on a serial TX pin for output, if there's a free UART. About the switches, if they are low current push buttons connected to the ECU that just short to ground, you can easily use any mosfet (2n7000 is my favourite) to "buffer" the PIC output. You will just need to connect the Source pin to ground, the Drain to the other side of the button, and the gate to the PIC pin, with a 1K to 10K resistor to ground. I'd go with that option. About the software, I haven't enough experience to help you, sorry. Regards MG
2013/9/4 Håkon Markussen <hakon.markussen@gmail.com> Hi all,
I see there is currently some HW discussion ongoing, so I'm picking up this post again:
I want to implement the doorlock control for Think City (vehicle_thinkcity.c) to the app.
The problem is that the module controlling the door locks (General Electric Module from Ford, part 17ST-15K600-KB) uses K-line only. I think the door lock switch can be triggered (K-line style) with request 22 A1 45 which returns 62 A1 45 40 for lock or 62 A1 45 80 for unlock. I have tried to address via other ECU's which also talk k-line, but with no success.
The GEM lock switch can be triggered by applying a gnd-pulse to the lock/unlock switch input. The pin voltage measure about 3,5V when no gnd is applied.
My current idea for solution is using RB4 and RB5 on the OVMS 9x2, connect it to the GEM unlock switch and GEM lock switch. The question is:
Do I need a transceiver between the Ovms-module (RB4/RB5) and the GEM-module (unlock/lock switch) for protection? If yes, any suggestions of type/device?
Are there anybody with the knowledge (and time) to re-write the utility.c/utility.h so the vehicle specific files can utilize the extra pins (RB4/RB5 for my case)?
Anybody with a better solution?
Best regards Håkon Markussen
2013/8/24 Mark Webb-Johnson <mark@webb-johnson.net>
Over the past year or so, I've had a few people ask me the same sort of question, so thought a single reply here would help.
On the v2 module circuit board there is a unpopulated 9x2 set of holes in the board. You can see it on the attached picture, between the crystal and LEDs.
You can either solder directly to this, or use a header plug/socket arrangement. All the unused pins from the PIC are brought out via that header, as well as GND, +5V and +12V. There are several free analog input pins, as well as digital input/output pins available for expansion. They are all 5V TTL level.
If someone wants to use these for something, I suggest you code utils.h/utils.c to provide a function to initialise and control the required ports. Just try to make it fairly non-specific so it is of some use to others. Then, the vehicle module can just call the appropriate utils.c function, presumably in response to an SMS / net_msg command.
For bi-directional sync/async comms, things are a little bit more tricky. The I2C pins are used by the LEDs, so you would have to sacrifice those and hack the code to use I2C. You could in theory do a software async, but I think that would be tricky. The DIAG port is just a tap between the PIC and the modem. Probably the best, for something sophisticated, is to use the CAN bus.
Regards, Mark.
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Michael,
We have several of those already in the code.
The UART, CAN and LEDs are all interrupt-driven, so will run even in a delay100() sleep - apart from those there shouldn't be anything else timing-dependant.
That said, 500ms is quite a long time, and for this example it would also be quite simple to do it in ticker1() (for a 1000ms delay), or even ticker10th() (which is called every 100ms).
Regards, Mark.
On 5 Sep, 2013, at 5:57 PM, Michael Jochum <mikeljo@mac.com> wrote:
Hi,
i don't like this:
delay100(5); in a "real Time System"
Better to put a sub in an timer/interrupt routine. I think we have enough timer.
Bye Michael
Am 05.09.2013 um 10:29 schrieb Mark Webb-Johnson <mark@webb-johnson.net>:
Håkon,
I think I'd like to keep utils.{h,c} simple. Just have standardised functions to set the digital output on/off.
void io_digital_set(port, onoff); unsigned char io_digital_get(port);
Then, put the logic for how it is used in the vehicle module itself.
if (io_digital_get(4)==0) { io_digital_set(4,1); delay100(5); io_digital_set(4,0); }
We would also need to initialise the ports in the correct way, and standardise what ports are used for input and what for output. I will look at this later tonight.
Regards, Mark.
On 5 Sep, 2013, at 3:14 PM, Håkon Markussen <hakon.markussen@gmail.com> wrote:
I'm sorry that my programming skills are not the best and have to ask about this. But to get this baby going I need some more detailed help.
In the utils.c (and utils.h) can I add two functions, and then call them from the vehicle-specific? One function (lock) sets RB4 high for 500ms and the other fuction (unlock) sets RB5 high for 500ms.
Do you think this will work?
void send_lock(void) { // Check if RB4 is low, set RB4 high for 500ms and back to low if (PORTBbits.RB4 == 0) { PORTBbits.RB4 = 1; delay100(5); PORTBbits.RB4= 0; }
void send_unlock(void) { // Check if RB4 is low, set RB4 high for 500ms and back to low if (PORTBbits.RB5 == 0) { PORTBbits.RB5 = 1; delay100(5); PORTBbits.RB5 = 0; }
Br. Håkon
2013/9/5 Mark Webb-Johnson <mark@webb-johnson.net> Unfortunately, no free UART on the low-end PIC18 we are using. We could do a software UART, but given all the other stuff going on, that would concern me.
I don't mind adding some stuff to utils.{c,h} for controlling digital outputs, if you want to go that route.
Regards, Mark.
On 4 Sep, 2013, at 10:13 PM, Mastro Gippo <gipmad@gmail.com> wrote:
Hi, for the K stuff: K line is just an async serial, at battery levels, at 10400bps 8n1. should be very easy to control from OVMS, with a mosfet on a serial TX pin for output, if there's a free UART. About the switches, if they are low current push buttons connected to the ECU that just short to ground, you can easily use any mosfet (2n7000 is my favourite) to "buffer" the PIC output. You will just need to connect the Source pin to ground, the Drain to the other side of the button, and the gate to the PIC pin, with a 1K to 10K resistor to ground. I'd go with that option. About the software, I haven't enough experience to help you, sorry. Regards MG
2013/9/4 Håkon Markussen <hakon.markussen@gmail.com> Hi all,
I see there is currently some HW discussion ongoing, so I'm picking up this post again:
I want to implement the doorlock control for Think City (vehicle_thinkcity.c) to the app.
The problem is that the module controlling the door locks (General Electric Module from Ford, part 17ST-15K600-KB) uses K-line only. I think the door lock switch can be triggered (K-line style) with request 22 A1 45 which returns 62 A1 45 40 for lock or 62 A1 45 80 for unlock. I have tried to address via other ECU's which also talk k-line, but with no success.
The GEM lock switch can be triggered by applying a gnd-pulse to the lock/unlock switch input. The pin voltage measure about 3,5V when no gnd is applied.
My current idea for solution is using RB4 and RB5 on the OVMS 9x2, connect it to the GEM unlock switch and GEM lock switch. The question is:
Do I need a transceiver between the Ovms-module (RB4/RB5) and the GEM-module (unlock/lock switch) for protection? If yes, any suggestions of type/device?
Are there anybody with the knowledge (and time) to re-write the utility.c/utility.h so the vehicle specific files can utilize the extra pins (RB4/RB5 for my case)?
Anybody with a better solution?
Best regards Håkon Markussen
2013/8/24 Mark Webb-Johnson <mark@webb-johnson.net>
Over the past year or so, I've had a few people ask me the same sort of question, so thought a single reply here would help.
On the v2 module circuit board there is a unpopulated 9x2 set of holes in the board. You can see it on the attached picture, between the crystal and LEDs.
You can either solder directly to this, or use a header plug/socket arrangement. All the unused pins from the PIC are brought out via that header, as well as GND, +5V and +12V. There are several free analog input pins, as well as digital input/output pins available for expansion. They are all 5V TTL level.
If someone wants to use these for something, I suggest you code utils.h/utils.c to provide a function to initialise and control the required ports. Just try to make it fairly non-specific so it is of some use to others. Then, the vehicle module can just call the appropriate utils.c function, presumably in response to an SMS / net_msg command.
For bi-directional sync/async comms, things are a little bit more tricky. The I2C pins are used by the LEDs, so you would have to sacrifice those and hack the code to use I2C. You could in theory do a software async, but I think that would be tricky. The DIAG port is just a tap between the PIC and the modem. Probably the best, for something sophisticated, is to use the CAN bus.
Regards, Mark.
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Hi all,
Michael is correct to show concern for the busy wait code. The USB
function is often polled in the PIC library, and a long 500ms, 100ms,
or even just a few milliseconds delay would cause the device to
disconnect from the host. It's theoretically possible to run USB from
an interrupt, but I'm not sure this works yet. Most all of the
projects I've seen that implement PIC USB are using the polled USB
stack. At the very least, it would be good to be prepared for that
setup.
It would be much better to design a generic mechanism for timed
events so that all of the existing delay100() calls can be removed
when necessary. I'm looking ahead to v3 when you add USB. Right now,
I'm sure there's no problem since, as you point out, all the other
peripheral communications are interrupt-driven.
Note that the 100ms delay is not very accurate when all of those
other interrupts are happening. Not that accuracy is that important,
but a timer-based solution would not slow down in the presence of
significant interrupt activity.
Brian
On Sep 5, 2013, at 05:58, Mark Webb-Johnson wrote:
We have several of those already in the code.
The UART, CAN and LEDs are all interrupt-driven, so will run even
in a delay100() sleep - apart from those there shouldn't be
anything else timing-dependant.That said, 500ms is quite a long time, and for this example it
would also be quite simple to do it in ticker1() (for a 1000ms
delay), or even ticker10th() (which is called every 100ms).On 5 Sep, 2013, at 5:57 PM, Michael Jochum <mikeljo@mac.com> wrote:
i don't like this:
delay100(5); in a "real Time System"
Better to put a sub in an timer/interrupt routine. I think we have enough timer.
Bye Michael
Am 05.09.2013 um 10:29 schrieb Mark Webb-Johnson <mark@webb- johnson.net>:
I think I'd like to keep utils.{h,c} simple. Just have
standardised functions to set the digital output on/off.void io_digital_set(port, onoff); unsigned char io_digital_get(port);
Then, put the logic for how it is used in the vehicle module itself.
if (io_digital_get(4)==0) { io_digital_set(4,1); delay100(5); io_digital_set(4,0); }
We would also need to initialise the ports in the correct way,
and standardise what ports are used for input and what for
output. I will look at this later tonight.Regards, Mark.
On 5 Sep, 2013, at 3:14 PM, Håkon Markussen
<hakon.markussen@gmail.com> wrote:I'm sorry that my programming skills are not the best and have
to ask about this. But to get this baby going I need some more
detailed help.In the utils.c (and utils.h) can I add two functions, and then
call them from the vehicle-specific? One function (lock) sets RB4 high for 500ms and the other
fuction (unlock) sets RB5 high for 500ms.Do you think this will work?
void send_lock(void) { // Check if RB4 is low, set RB4 high for 500ms and back to low if (PORTBbits.RB4 == 0) { PORTBbits.RB4 = 1; delay100(5); PORTBbits.RB4= 0; }
void send_unlock(void) { // Check if RB4 is low, set RB4 high for 500ms and back to low if (PORTBbits.RB5 == 0) { PORTBbits.RB5 = 1; delay100(5); PORTBbits.RB5 = 0; }
Brian,
For the _current_ code, delay100() is fine. Use should be minimised, but there really is no need to go to the flash+ram expense of setting up an event based solution.
Internally (utils.c) delay100() uses delay100b() which uses timer2.
For v3 ovms, I would really like to use a RTOS of some form (something that we just didn't have the RAM or flash space for in v1/v2). Running each component in its own thread would be much more flexible.
Regards, Mark.
On 7 Sep, 2013, at 4:42 AM, HONDA S-2000 <s2000@sounds.wa.com> wrote:
Hi all,
Michael is correct to show concern for the busy wait code. The USB function is often polled in the PIC library, and a long 500ms, 100ms, or even just a few milliseconds delay would cause the device to disconnect from the host. It's theoretically possible to run USB from an interrupt, but I'm not sure this works yet. Most all of the projects I've seen that implement PIC USB are using the polled USB stack. At the very least, it would be good to be prepared for that setup.
It would be much better to design a generic mechanism for timed events so that all of the existing delay100() calls can be removed when necessary. I'm looking ahead to v3 when you add USB. Right now, I'm sure there's no problem since, as you point out, all the other peripheral communications are interrupt-driven.
Note that the 100ms delay is not very accurate when all of those other interrupts are happening. Not that accuracy is that important, but a timer-based solution would not slow down in the presence of significant interrupt activity.
Brian
On Sep 5, 2013, at 05:58, Mark Webb-Johnson wrote:
We have several of those already in the code.
The UART, CAN and LEDs are all interrupt-driven, so will run even in a delay100() sleep - apart from those there shouldn't be anything else timing-dependant.
That said, 500ms is quite a long time, and for this example it would also be quite simple to do it in ticker1() (for a 1000ms delay), or even ticker10th() (which is called every 100ms).
On 5 Sep, 2013, at 5:57 PM, Michael Jochum <mikeljo@mac.com> wrote:
i don't like this:
delay100(5); in a "real Time System"
Better to put a sub in an timer/interrupt routine. I think we have enough timer.
Bye Michael
Am 05.09.2013 um 10:29 schrieb Mark Webb-Johnson <mark@webb-johnson.net>:
I think I'd like to keep utils.{h,c} simple. Just have standardised functions to set the digital output on/off.
void io_digital_set(port, onoff); unsigned char io_digital_get(port);
Then, put the logic for how it is used in the vehicle module itself.
if (io_digital_get(4)==0) { io_digital_set(4,1); delay100(5); io_digital_set(4,0); }
We would also need to initialise the ports in the correct way, and standardise what ports are used for input and what for output. I will look at this later tonight.
Regards, Mark.
On 5 Sep, 2013, at 3:14 PM, Håkon Markussen <hakon.markussen@gmail.com> wrote:
I'm sorry that my programming skills are not the best and have to ask about this. But to get this baby going I need some more detailed help.
In the utils.c (and utils.h) can I add two functions, and then call them from the vehicle-specific? One function (lock) sets RB4 high for 500ms and the other fuction (unlock) sets RB5 high for 500ms.
Do you think this will work?
void send_lock(void) { // Check if RB4 is low, set RB4 high for 500ms and back to low if (PORTBbits.RB4 == 0) { PORTBbits.RB4 = 1; delay100(5); PORTBbits.RB4= 0; }
void send_unlock(void) { // Check if RB4 is low, set RB4 high for 500ms and back to low if (PORTBbits.RB5 == 0) { PORTBbits.RB5 = 1; delay100(5); PORTBbits.RB5 = 0; }
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
participants (5)
-
HONDA S-2000 -
Håkon Markussen -
Mark Webb-Johnson -
Mastro Gippo -
Michael Jochum