[Ovmsdev] Hardware hacking OVMS v2 for fun and profit

Mark Webb-Johnson mark at webb-johnson.net
Sat Sep 7 20:50:57 HKT 2013


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 at 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 at 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 at 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 at 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 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/20130907/487809c6/attachment.htm>


More information about the OvmsDev mailing list