Drivers updated!

Comments

• jcullins0 Posts: 10

  2012-08-19 10:51 edited 2012-08-19 10:51

  Thanks Kye, you do fantastic work.
• Kye Posts: 2,200

  2012-08-19 11:52 edited 2012-08-19 11:52

  Thank you,
• cavelamb Posts: 724

  2012-08-19 11:58 edited 2012-08-19 11:58

  Bravo, Kye.
  
  Good stuff.
• groggory Posts: 205

  2012-08-19 19:14 edited 2012-08-19 19:14

  Just out of curiosity, what do these drivers bring to the table over the standard serial drivers?
• Ahle2 Posts: 1,179

  2012-08-20 00:54 edited 2012-08-20 00:54

  @Kye
  When I see your name at the top of a driver, I know that it is of high quality. Having peeked at how you do things (in pasm) I know that you are a fan of simple, yet powerful solutions.
  (I must say that the majority of drivers in the OBEX are of medium or low quality)
  
  /Johannes
• Kye Posts: 2,200

  2012-08-20 07:55 edited 2012-08-20 07:55

  Thanks Ahles2!
  
  @groggory
  
  My serial driver offers 256 bytes RX and TX FIFO buffers over 16 byte FIFO buffers in full duplex serial. This means that it is easier to handle serial data at a much higher rate without having to poll the serial driver for bytes so often to keep it from overflowing. The serial driver additionally, does not have jitter in the TX output unlike the full duplex serial which has a very jittery serial output at higher baud rates. The serial driver can also handle a baud rate of 250,000 BPS at 96 MHz. The serial driver supports bulk input and output routines that make sending and receiving lots of bytes much faster. And... finally, my serial driver can be cleanly stopped and started without corrupting transmitted serial data. If you stop the full duplex serial driver while it is transmitting bytes it won't finish transmitting and then stop. It will just stop and corrupt whatever it was sending.
  
  Thanks,
• groggory Posts: 205

  2012-08-20 12:19 edited 2012-08-20 12:19

  Well said! You should put that in your obex description. That answers so many questions.
  
  I'm going to be using these!
  

  Kye wrote: »

  Thanks Ahles2!
  
  @groggory
  
  My serial driver offers 256 bytes RX and TX FIFO buffers over 16 byte FIFO buffers in full duplex serial. This means that it is easier to handle serial data at a much higher rate without having to poll the serial driver for bytes so often to keep it from overflowing. The serial driver additionally, does not have jitter in the TX output unlike the full duplex serial which has a very jittery serial output at higher baud rates. The serial driver can also handle a baud rate of 250,000 BPS at 96 MHz. The serial driver supports bulk input and output routines that make sending and receiving lots of bytes much faster. And... finally, my serial driver can be cleanly stopped and started without corrupting transmitted serial data. If you stop the full duplex serial driver while it is transmitting bytes it won't finish transmitting and then stop. It will just stop and corrupt whatever it was sending.
  
  Thanks,
• Martin Hodge Posts: 1,246

  2012-08-20 15:27 edited 2012-08-20 15:27

  Kye, you should set up a PayPal "donate" button somewhere. I'd throw in two bits.
• Kye Posts: 2,200

  2012-08-20 15:35 edited 2012-08-20 15:35

  To bad it isn't setup for the OBEX.
  
  Thanks,
• cavelamb Posts: 724

  2012-08-20 15:49 edited 2012-08-20 15:49

  Kye wrote: »

  To bad it isn't setup for the OBEX.
  
  Thanks,

  
  No reason it couldn't be...
  
  (Ken, are you paying attention?)
• groggory Posts: 205

  2012-08-20 15:52 edited 2012-08-20 15:52

  If you like this object, send a donation to the developer by clicking here --Paypal Donate--
  
  That'd be great.
  
  Maybe we'd get as many objects as the Apple App store and it will make propeller authors/coders/artists millionaires!
• Drone Posts: 433

  2012-08-21 00:23 edited 2012-08-21 00:23

  @Kye, Unless I'm missing something obvious, in the top-post you say you've updated your serial driver to V1.7, but on the ObEx page for your driver it says Version 2.0. Just nit-picking ;-) Thanks for the update, David
• Kye Posts: 2,200

  2012-08-21 07:23 edited 2012-08-21 07:23

  This post was made a year ago. The driver was updated again...
• Dr_Acula Posts: 5,484

  2012-08-25 05:03 edited 2012-08-25 05:03

  Hi Kye,
  
  I'm building some code I'm calling "KyeFTP" which is a file transfer protocol to talk to the SD card via the serial port and enable file transfers and dir listings etc from the PC. Run a simple program on the PC side and drag and drop files onto the propeller. Maybe even integrate that into an IDE? Of course, I am *only* using Kye objects - the SD card driver and the serial driver.
  
  So - looking at the serial driver, I see

    baudRateTiming(baudRate) 
  

  
  and that calls a routine

  PUB baudRateTiming(baudRate) '' 4 Stack Longs
  
  '' ////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
  '' // Sets the baud rate. The new baud rate goes into effect after the current byte is done being transmitted.
  '' //
  '' // BaudRate - The baud rate to transmit and receive at. Between 1 BPS and 250K BPS at 96 MHz.
  '' ////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
  
    baudNumber := ((clkfreq / ((baudRate <# (clkfreq / constant(96_000_000 / 250_000))) #> 1)) / 4)
  

  
  It is working at 11200 baud, but that line of code above seems to have a value hardwired for a 6Mhz clock. I'm using a 5Mhz clock - would it matter? Or would it be better to declare a constant at the top of the program of 80_000_000 and then reference all timing off that constant and so you would only need to change one constant if you change the xtal frequency?