[Ovmsdev] Hardware hacking OVMS v2 for fun and profit

Thu Sep 5 15:14:00 HKT 2013

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 at 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 at 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 at 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:
>>   1) 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?
>>
>>   2)  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)?
>>
>>   3) Anybody with a better solution?
>>
>> Best regards
>> Håkon Markussen
>>
>>
>> 2013/8/24 Mark Webb-Johnson <mark at 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 at lists.teslaclub.hk
>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>>
>>>
>>
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.teslaclub.hk
>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>
>>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>
>
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20130905/4e798022/attachment.htm>