In SX Microcontrollers, SX/B Compiler and SX-Key Tool, Zoot wrote:

I'm hoping perhaps Bean or pjv or Peter Verkaik (or anyone) has comments, suggestions on a rework I'm doing to my own rework of the firmware for the Serial Inkjet Board.

The original firmware is pretty much straight up SX/B, with SERIN and SEROUT used for RX/TX -- very "Stamp" style. I reworked that firmware to change the command set, baud, and to hold the serial (open true) line low while printing, so the host could use it as a "busy" signal. All fine.

However, I have printer-bot, and when it finds a piece of paper on the table, it prints on it. Also wonderful. However, what the firmware does not allow for is canceling a print once in progress -- thus if the paper runs out before the 'bot is done printing it prints on the table.

So, I am planning on porting the firmware to a more traditional mainline/isr approach with a state machine for the mainline. This will allow the host to comm. with the module even during printing (so the host can get updates, cancel print in progress, etc). Again, no problem with porting it (it's pretty simple, actually).

The ONLY rub is that there is a portion in the firmware where the two sets of nozzles are fired very close in time to each other -- about 5us apart. In the current firmware (SX28 @ 20MHZ) it's done with a PAUSEUS. Now that won't work here, because of the ISR. Secondly, I can't use a flag in the ISR to mark time that short, because under most circumstances the ISR (if it kicks in during the pause) will take 1-2us.

So, the only possible (kinda simple) approach I've come with is to have the mainline use a dedicated register for the equivalent of a "pauseus" counter. Then, the ISR can decrement this counter AS IT NEEDS TO if a pause is in progress. My idea is if it takes 100 instruction cycles at 20mhz to pause 5us, then if a portion of the ISR consumes 30 cycles, that portion would decrement the dedicated pauseus counter appropriately.

I.E. in pseudo code

[code]
Interrupt_Handler:
' bunch of rx code

' if rx code ran and:
' if mainline nozzle pause in progress:
SUB nozPauseCntr, #10 ' or whatever it would need to be depending on cycle count
' and prevent underflow

' bunch of tx code

' if mainline nozzle pause in progress and:
' if tx start code ran:
SUB nozPauseCntr, #30 ' or whatever it would need to be depending on cycle count
' and prevent underflow

' if tx bit code ran:
SUB nozPauseCntr, #20 ' or whatever it would need to be depending on cycle count
' and prevent underflow

'etc

RETURNINT


Main:

  MOV nozPauseCntr, #50
:wait
  DECSZ nozPauseCntr
  JMP :wait
[/code]


Does that make sense? It's the only way I can think of to get reasonably accurate nozzle timing at those speeds without having to go to an ISR running over 300khz.

I guess I could also insert NOPs and the like to keep the ISR at a consistent time, and adjust the effective frequency of the mainline instructions (in SX/B) but that actually seems more "hacky" to me, esp. given that *most* of the time the nozzle pause will not actually be in use.

The rest of the timing in the app. is all in ms (or longer).

---------- End of Message ----------


You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=323625

Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com

The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2009 (http://www.dotNetBB.com)