[Ovmsdev] Hardware hacking OVMS v2 for fun and profit

[HONDA S-2000]

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;
>>>>   }
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20130906/748b774d/attachment.htm>