View previous topic :: View next topic |
Author |
Message |
KenHorse
Joined: 16 Jul 2004 Posts: 523
|
Posted: Mon Dec 07, 2015 12:06 am Post subject: Is there a better way? |
|
|
I have a need to allow me to select whether a PRINTBIN or PRINTBIN #x is used. As the strings being sent are quite long (60 bytes) and there are quite a few places in my code where this choice is to be made, I was hoping there's a better way (using less code space) than this pseudo code:
Code: |
If Variable = 1 Then
PrintBin blah blah blah blah blah
Else
PrintBin #x, blah blah blah blah
|
(BASCOM-AVR version : 2.0.7.8 ) |
|
Back to top |
|
|
AdrianJ
Joined: 16 Jan 2006 Posts: 2483 Location: Queensland
|
Posted: Mon Dec 07, 2015 3:22 am Post subject: |
|
|
Printbin normally prints to the hardware UART0. Does #x signify another serial port, or a file ?
If its just a different serial port, you can define (say) com1 ( which is normally uart0) as serial port #1 and then use a variable to select the port number.
roughly: Code: |
config com1 as #1 'and add the rest of the port config parameters here
config com2 as #2 'the numbers dont have to match, but its less confusing if they do !
dim cport as byte
cport = 1 'set target to serial port #1
printbin #cport,........ 'will go to com1
cport = 2 'reset target to com2
printbin #cport,........... 'will go to com2
|
Havent tried this since a long time ago, but I guess it should still work.
I dont think this works with file numbers as well as serial ports ( but I could be wrong ). _________________ Adrian Jansen
Computer language is a framework for creativity |
|
Back to top |
|
|
KenHorse
Joined: 16 Jul 2004 Posts: 523
|
Posted: Mon Dec 07, 2015 3:45 am Post subject: |
|
|
PRINTBIN currently does print to a hardware serial port whereas #4 is a software-defined one. (this is legacy code so I can't really change too much). That's kinda my dilemma as I didn't think you could change that sort of thing on the fly |
|
Back to top |
|
|
AdrianJ
Joined: 16 Jan 2006 Posts: 2483 Location: Queensland
|
Posted: Mon Dec 07, 2015 3:53 am Post subject: |
|
|
I never tried it with a S/W defined serial port, but I would have thought that should work. I try and avoid S/W ports, they chew up too many processor cycles. Good for debugging, but not much else, IMHO.
Not sure when the facility to use a variable for a port number was added. You may have to experiment with different compiler versions. Certainly the older versions did not have that facility. _________________ Adrian Jansen
Computer language is a framework for creativity
Last edited by AdrianJ on Mon Dec 07, 2015 3:57 am; edited 1 time in total |
|
Back to top |
|
|
KenHorse
Joined: 16 Jul 2004 Posts: 523
|
Posted: Mon Dec 07, 2015 3:57 am Post subject: |
|
|
I try to avoid SW ports as well but sometimes, you gotta do what you gotta do
(be nice if there was a library of some sort that reserved a SW #1 definition as a HW port... ahhhh...just fantasizing! |
|
Back to top |
|
|
MWS
Joined: 22 Aug 2009 Posts: 2262
|
Posted: Mon Dec 07, 2015 7:43 am Post subject: |
|
|
AdrianJ wrote: | I try and avoid S/W ports, they chew up too many processor cycles. |
If you don't use buffered print, there's no difference in terms of used up cycles, both versions use wait cycles then, the HW-VERSION to wait till UDR is emptied and the SW-version to control bit timing. |
|
Back to top |
|
|
AdrianJ
Joined: 16 Jan 2006 Posts: 2483 Location: Queensland
|
Posted: Mon Dec 07, 2015 7:56 am Post subject: |
|
|
True in simple cases, where you send just something like a string in one piece. I tend to send single bytes, and do 'other things' after each byte has gone, since particularly at low speeds you can do lots of stuff while the byte is being transmitted out the UART. And yes, I also tend to use buffered print if possible. Maybe this is a hangover from earlier days, when we tried to squeeze as much performance as possible out of very limited processors, but old habits are hard to break. _________________ Adrian Jansen
Computer language is a framework for creativity |
|
Back to top |
|
|
EDC
Joined: 26 Mar 2014 Posts: 971
|
Posted: Mon Dec 07, 2015 10:31 am Post subject: |
|
|
Quote: | strings being sent are quite long (60 bytes) |
If they both are same then you dont need to code them twice |
|
Back to top |
|
|
KenHorse
Joined: 16 Jul 2004 Posts: 523
|
Posted: Mon Dec 07, 2015 4:59 pm Post subject: |
|
|
EDC wrote: | Quote: | strings being sent are quite long (60 bytes) |
If they both are same then you dont need to code them twice |
They aren't and that's the point. I have at least a dozen instances in my code where I need to send different strings. |
|
Back to top |
|
|
AdrianJ
Joined: 16 Jan 2006 Posts: 2483 Location: Queensland
|
Posted: Mon Dec 07, 2015 11:00 pm Post subject: |
|
|
EDC makes a valid point.
If you put all the 'blah,blah,blah' variables into either a string or a byte array at each point where you need to send data, then the overhead of actually doing the print to different ports is pretty small.
Code: |
dim barray() as byte
barray() = 'blah, blah, blah' 'code how you want !
if variable = 1 then 'set the destination
printbin barray() 'prints the entire array, but its a very small piece of code
else
printbin #1, barray()
end if
|
The advantage is that you assemble the array in common code, then only invoke the print on that one array ( or string, whichever is more convenient). _________________ Adrian Jansen
Computer language is a framework for creativity |
|
Back to top |
|
|
KenHorse
Joined: 16 Jul 2004 Posts: 523
|
Posted: Tue Dec 08, 2015 1:09 am Post subject: |
|
|
AdrianJ wrote: | EDC makes a valid point.
If you put all the 'blah,blah,blah' variables into either a string or a byte array at each point where you need to send data, then the overhead of actually doing the print to different ports is pretty small.
Code: |
dim barray() as byte
barray() = 'blah, blah, blah' 'code how you want !
if variable = 1 then 'set the destination
printbin barray() 'prints the entire array, but its a very small piece of code
else
printbin #1, barray()
end if
|
The advantage is that you assemble the array in common code, then only invoke the print on that one array ( or string, whichever is more convenient). |
That doesn't really solve anything as far as I can see as I still need different strings. In my code, I have 12 different PRINTBIN statements, each one with a unique string it sends. So I'd still need 12 different IF/THEN conditionals to select between PRINTBIN and PRINTBIN #1.
I think I need to rethink my methodology here....... |
|
Back to top |
|
|
six1
Joined: 27 Feb 2009 Posts: 553
|
|
Back to top |
|
|
|