Re: [Flashforth-devel] I2c using PIC MSSP

[Mikael N. <mik...@pp...>]

If you want compiled code speeds, naturally you have to compile the code :-)

There are some delays because the interpreter takes time to process the 
input line one word at a time.

Another source of delay is if you have idle mode configured.
In every PAUSE FF sleeps until the next interrupt.
You can get rid off that by compiling FF with the idle mode disabled.

The FF3.8 BUSY IDLE words are tricky to use, but are simplified in FF5.0 
which you can find in GIT.

I have not tried higher baudrates. Even if these could be configured, in 
practice the PIC18 cannot process data at those speeds.

BR Mike

On 02/28/2014 05:09 AM, craig bair wrote:
> Sorry for the delay, things got crazed and I couldn't get back online 
> for a while there.
>
> As it turns out, putting the flag clearing after the buffer write 
> really did solve my problem, but there was this matter of scale with 
> the BitScope and its triggering.  I'm guessing that there's some odd 
> interaction going on between some of the routines, the interpreter, 
> and the time-slicing of the multi-tasker.  Entering the words as a 
> line interactively there was a 10 ms delay between the ssen and the 
> first sspbuf! with another 4 ms till the next sspbuf!.  The little 
> pocket BS-10 wasn't retriggering on the second write leading to the 
> misinterpretation of events.  It also wasn't happy about slowing down 
> enough to show the whole sequence, but eventually co-operated.
>
> Rolling the desired sequence together into a single word works much 
> more smoothly.  Do interactive sessions often do this?  I for one 
> normally wouldn't notice if it did under most circumstances.
>
> On an almost unrelated note, have you ever pushed a Pic18 UART to 
> 230.4K baud or 460.8K baud?  I may have need to run that or higher 
> bit-rates between chips for a project and the numbers look like it 
> might be possible when clocking the pics at 48-64Mhz.  One problem I 
> see is that I don't have a serial port that runs that fast to watch 
> them with.  I hope that one of the FTDI usb-to-uart interface boards 
> can give me a virtual serial that can handle it, but I'm experimenting 
> blind at this point. Tera Term does have settings up to 921.6K, after 
> all....(grin)
>
> Keep up the good work!
> craig
> ...averaging may or may not help clarify data.
>    If Bill Gates walks into a bar,
>    the average patron becomes a millionaire...
>
> ------------------------------------------------------------------------
> **
> When quickly checking the datasheet I saw no requirement for the slave
> to respond for sspif to be set. In the datasheet sspif is cleared after
> writing to sspbuf. In the current code sspif is cleared before writing
> to sspbuf. You could try this. : sspbuf! ( c -- ) \ sspbuf! takes 90 us
> @ 100 KHz
>   sspbuf c!
>   [ pir1 sspif a, bcf,      ]
> [ begin, ]
> [ pir1 sspif a, btfss, ]
> [ again, ]
> ;
> Mikael
>
>