Project Logs

Collapse

• If You Can't Beat 'Em, Beat 'Em Into Submission

  ziggurat29 • 07/21/2017 at 02:34 • 0 comments

  Summary:

  A quirk of one of the printers, the APS EPM203-MRS, could not be disabled, but was worked-around.

  This project is now functionally complete.

  Deets:

  Yesterday I had mentioned that one of my printers, the APS EPM203-MRS has a quirk whereby it gratuitously advances the paper before printing bitmaps.  Moreover, it only does this sometimes, when there has not been prior output for 'a while'.  This made my output look weird on that printer, and I don't like weird things.  (OK, that's a general lie, but in this limited case, it's true.)

  I scoured the manual looking for some way to turn off the paper advance feature/wart/whatever.  Look as I may, and look as I might, there was no such feature found that night.  I spoke 'the uncommon words of anguish', and retired for the night.

  This morning I awoke to discover that I had turned into a giant cockroach.  This situation only lasted a few minutes, but when it had ended I was left with a kooky idea:  maybe I can just compensate for the paper advancing by doing a reverse paper feed before emitting the graphic.  The sand in that vaseline is that the paper advance only happens /sometimes/, after there has been a period of output quiescence.  If the data stream keeps coming to the printer with some reasonable pacing, no gratuitous paper feed is done.  (Thank the maker for that little blessing -- really every horizontal line of pixels is it's own distinct graphic.  It would be quite a mess if there was a paper feed between each horizontal line!)

  So, sometimes, if you are faced with an inability to make things reliably the way you want them to be, you can as an alternative approach make them reliably the way you /don't/ want them to be.  If I can make /every/ graphic output reliably have the unwanted paper feed, then I can reliably always do the workaround of the reverse paaper feed beforehand.

  The approach I took wound up being a fairly surgical change:

  • at then end of transmission of data to the printer, note the time, call it g_nLastTx.  Initialize that to 0 at boot, btw.  I'm just using the HAL_GetTick() which returns milliseconds since boot.
  • before doing ouput, compute 'now' - 'then'.  (I.e. HAL_GetTick() - g_nLastTx)  2s complement will make all your rollover worries better (mostly; more later).  Call this difference 'duration'.
  • if the 'duration' is longer than the safe amount of time to guarantee that the paper advance will happen, then sleep (via osDelay() in the CMSIS API) for the difference.
  • now you should be guaranteed that doing a 'reverse paper feed' of a few pixels will counteract the gratuitous paper feed that you know the printer is going to insert.

  OK, subtle detail on the timer rollover:  we covered the usual case of 'I started just before the counter rolled over, and checked after it did, how do I handle that' with the unsigned 2s complement subtraction, but there is another issue when you rollover twice or more.  Then the 2s complement doesn't help you.  OK, the timer rollover will happen after 49 days, so you'd have to wait twice that time, so over 3 months of powered on but disuse before you'd be at risk of it.  But I'm taking this thing to Jupiter and I can't have Hal telling me 'I'm sorry Dave, I can't open the pod bay doors until I get the output from your thermal printer.' and have to wait for 49/2=25 days while oxygen runs out.  (Hal does love its petty torments.)

  So I covered that scenario with a little hack.  A 'haque', really -- it's not that dirty.  The printer rasterizer process blocks waiting for a signal that a birmap is ready to be rasterized.  That blocking has a timeout, which I arbitrarily set at 5 seconds.  The intention of that is to let the thread awaken to realize that there hasn't been anything to do for a while, but that is nonetheless still alive, and it can just carry on blocking again.  This opportunity can be used...

  Read more »

• Success! I'm the Operator on My Pocket Calculator

  ziggurat29 • 07/19/2017 at 18:04 • 0 comments

  Summary:

  Printing to physical printer is now working with both the GoojPrt and APS EPM203-MRS units.

  I am now moving onto optimizations and enhancements.

  Deets:

  I implemented two physical printer rasterizers for two of the sample printer cores: the GoojPrt unit that I was originally going to use, and the APS EPM203-MRS unit that I got later. They both print correctly (with some caveats):

  APS EPM203-MRS output is top two, GoojPrt output is lower two. So, printing is a-happinin'! Yay!

  There are two caveats, though:

  1. as mentioned earlier, the electrical design of the GoojPrt leaves some things to be desired. As you can see in those two printouts, the output is rather faint. This is easily addressed with a command that specifies heating/resting times for the thermal head, but using that so far has only resulted in power supply droops that reset the printer, so I am holding off on addressing that now until I get a better power supply. I find this annoying, but the code must go on!
  2. also as mentioned earlier, the APS unit's firmware has the annoying tendency of advancing the paper when printing bitmaps (and everything in this printer project is treated as bitmaps so as to realize the 82240 character sets). You can see the effect in the top right printout, where there is noticeable space between the lower printed 'lines'. Those are on separate strips of output bitmap. It doesn't look incredibly horrible here, but that is just good luck. If I were to print, say, a graph, then you would see the intervening paper advances.
     
     That printer happens to have a 'reverse linefeed' command, which in principle I could use to compensate, but the maddening thing is that the gratuitous paper advance only happens if there is a pause in the print data stream greater than some unknown amount (around a second or less). If the pause is below that threshold, there is no advance. You can see this in the top lines of that printout, where the successive rendered bitmaps (three in that case) are output in rapid succession.
     
     This is maddening to me. I am scouring the datasheet to see if this is some feature that can be turned off. I may disassemble the printer's firmware to see if I can find a way to stop it (I disassembled the firmware of the Kashino last week for an unrelated activity).

  So, now I am trying to fix the power supply issue for the Gooj, and the gratuitous paper advance issue for the APS. After resolving those, the project will technically be 'done', but is anything really ever 'done'?

  As mentioned before, as an enhancement, I want to implement a command-line interface 'monitor' program that runs on the USB side. It would do things like manage settings and whatnot.

  As an additional feature, I want to be able to realize some secondary functionality such as:

  • send decoded IR to USB port; this would realize an HP82240 to PC adapter for receiving raw data from the calculator for... whatever!
  • forward data from USB to printer port; this would realize an PC to thermal receipt printer adapter
  • etc.

  After that, I should be able to mark the project 'completed'. My favorite task to cross off!

  Next:

  I want to resolve the annoying paper advance issue in the APS printer, and the annoying power suck issue in the GoojPtr.

  I need to capture a video of the printer in operation for the blog.

• Thoroughly Removing The Uncommon Words of Anguish

  ziggurat29 • 07/18/2017 at 14:09 • 0 comments

  Summary:

  Reading datasheets can be fun!

  Deets:

  While coding up the rasterizer, I was rummaging through the datasheet for the Kashino printer. I came upon this statement in the "Features" section of the User Manual:
  

  "Printer control panel built-in GB18030 Chinese character, thoroughly remove the uncommon words of anguish."

  I can't make this up; q.v.:

  (I don't know why the highlight is there -- it's that way in the PDF itself (with other things).)

  I do very much appreciate having access to the the document, but I think they might have fallen short of their stated goal because I did utter some words of anguish upon reading this. But maybe my words were too common to have been thoroughly removed.

  Next:

  Back to work coding printer rasterizers....

• My Three Sons; Mike, Robbie, and Chip

  ziggurat29 • 07/17/2017 at 23:27 • 1 comment

  Summary:

  I was tired of waiting for my printer to come in from China, so I bought a similar one that ships statewide. Then I realized I actually had a printer on-hand all along from a project some 4 years back. No sooner than I dug up the old printer, the other two arrived the same day. Sheesh. So now I have an embarrassment of riches.

  Now, I mount the printers and do intial tests with the integrated system -- finally!

  Deets:

  In impatience to receive my printer module, I went back to eBay and looked to see if a similar module is available from domestic shipping, which should take less time. There was, and not for not much more cost. Further, as best as I can tell, this is the more premium module on which the other module claims compatibility. This is the APS EPM203-MRS. Moreover, I could find a real datasheet on this model. Still, it would take a week or two to get it in.

  Well, this morning (Friday; sorry, late post. It takes me more time to compose these posts than it does to do the work on which I'm reporting!) I awoke with the realization that I actually already have a thermal printer from a project I was doing for a client some 4+ years back. That was a 'Kashino CSN-A2-T'. I did dig that up.

  Then when the mailman came, a miracle: both my domestically ordered APS module /and/ my Chinese 'GoojPrt' module arrived! Yikes! Too many printers! Here they are:

  Mike, Robbie, and Chip -- err... 'Kashino', 'GoojPrt', and 'APS EPM203-MRS'.

  They all three have 'TTL' serial, which I measured to be 3.3 V logic (happily; so I don't have to add level shifters). Howver, the Kashino out-of-box only does 'hail, Mary' style serial, and by that I mean there is no flow control. I can open it up and hack it it onthe controller board (it's there), but the Kashino is now less relevant since my other modules came it.

  To my dismay, the APS printer module is just the module -- no connecting cables! Yikes! But there was unexpected hope, because the GoojPrt did come with cables. Here is the 'unboxing':

  Fortunately the important connectors are the same on the GoojPrn and the APS, so the Gooj wires will work in both instance. And... since I need to solder the other end of the cable to the controller board, and since the wires are pretty long as it is, that means cutting each in two. So, another set of cables! Yay for wasting money on too many printer modules! I cut the cable assemblies and soldered some pin header terminations on one pair, which will be convenient for me to stick it in a breadboard and/or connecting to the FTDI adapter for testing before getting into the real code for the controller board.

  Now, time for a sanity check.

  I never could find documentation on the GoojPrn, but it looks suspiciously like the APS unit. I found documentation on the APS unit, and have some for the Kashino, too. The Kashino claims that you hold down the Paper Feed button while powering on, and a test print will spew out. The APS claims that you hold down the Online/Offline button while powering on, then click Paper Feed twice, and then releasing the Online/Offline. OK. None of this worked at all on any of the three printers.

  The Kashino and the APS printer just could not be made to do anything interesting with those buttons sequences, and the GoojPrt would only print CP437 once and stop. WTF? Incidentally, the GoojPrt and the APS both come with a strip of paper that is the test page printout, so I know what it should look like. If one came with the Kashino, it's been lost to time. On the Kashino, it just did a paperfeed like the paperfeed button should do, and the APS simply gave me a blank stare. Ah, the joys of documentation on these things.

  In desperation to see something interesting happen (I mean, surely all three can't be broken?) I went ahead and wired them up to my FTDI. I guessed on COM port speed -- apparently the Kashino is 19,200 and both the GoojPrn and APS are 9600 -- and sent a simple "Hello!" message. Yay! It printed! So wtf could be the problem?

  Moving on again, I...

  Read more »

• ♫ I've Got (too much) Power! (gonna make you sweat) ♫

  ziggurat29 • 07/13/2017 at 18:07 • 0 comments

  Summary:

  The BluePill board is powered directly from the 5V USB line. The printer requires more power than USB can supply, necessitating an external supply (e.g. 5V wall adapter). Wiring the 5V from an external supply then precludes the use of USB, because the circuitry would directly connect that to the computer's power bus.

  Some minor surgery was done to avoid damaging the PC when the USB is connected. This was done two ways: good, and better.

  Deets:

  The printer requires more power that the USB can supply, so an external supply of some sort is needed. It could be batteries, but in my case I am going to use a 5V regulated 'wall wart'. This presents some challenges, though. The design of the BluePill has the +5V USB line connected directly to the input of the 3.3V LDO regulator. Some things that can be done:

  1. if only the ground of the BluePill is connected to the ground of the printer, this would be OK, except then the BluePill will always have to be connected to some USB source of power. Silly.
  2. if the power supply for the printer is connected to the BluePill, this would be OK, but then it would be dangerous to connect the BluePill to the USB port of a host, because that would couple the printer power supply into the host's USB. And you know someone will do that because the jack is there, and anyway I do want to do it because I want the USB CDC functionality. Undesireable.

  So, much as I am loathe to do it, I need to do some PCB surgery. The first surgery is to disconnect the +5V USB line from the input of the regulator. Here is where it is located on the back of the board:

  So, that trace must be cut. Here it is cut:

  Now I can power the board from the external 5V supply, along with the printer module. But, it also means that I will always need the external supply to do the USB. I can fix that by adding a Schottky diode where the trace used to be. That way, USB can power the CPU board if there is no external supply, and the external supply will be blocked from powering into the host if it is there.

  Coincidentally, I have some MBR0540T1 Schottkys, which are just about the correct size. I scraped off some of the solder mask near the via (you can see the scraped area in the picture, above), and soldered the diode from that spot to the other side of the cut trace (borrowing the pad from C7 for the diode's cathode).

  As you know, we typically use Schottkys because they have a low forward voltage drop of about 0.2 V, but really, since the 5V is going into a 3.3 V regulator, you could use a typical silicon diode (0.7 V) just as well.

  Now I can use the USB with safety and confidence! Well, almost. If I want it to be really robust, I also need to add another Schottky on the external supply side, so that the USB doesn't try to power the printer if the external supply is not present. This is because the printer takes too much power for the USB to supply, so mI ight as well prevent that accident from happening, too. This won't require board surgery, but rather a through-hold Schottky can be mounted on the 5V pin of the board. (I haven't done this yet, so no picture, but this one is trivial since the 5V pin is clearly marked on the board. Just be sure the diode is pointed the correct way -- with the banded side towards the board, away from the power supply.)

  In retrospect, I'm a little surprised that the manufacturer didn't splurge on adding the diodes. They did splurge on adding two crystals, and frankly I'd rather if they simply put the one 32.768 KHz crystal, leaving the 8 MHz unpopulated, and redirected that cost into these protection diodes. The chip has a PLL that can synthesize the high frequency clock and phase lock it onto the low frequency crystal, so you wouldn't lose any capability by dropping the high frequency crystal. But, hey, I didn't design the board, and I'll definitely still take it considering the absurdly low cost.

  OK, back to printer interfacing....

  Next:

  More printer interface code.

• ♫ Flash! (aa-aahh!) Saver of the Usersettings! ♫

  ziggurat29 • 07/12/2017 at 19:02 • 0 comments

  Summary:

  It occurred to me that it would be useful to save some configuration in a non-volatile manner. This board and this chip does not have any conventional non-volatile storage (e.g. EE or external serial EE), but there's plenty of pages of unused program memory, so I use the last one to be used for infrequently changed NVRAM settings.

  Also, I validated my HP82240B rendering engine.

  Deets:

  Over the past couple weeks it occurred to me that this interface board has some utility beyond the primary intent of being an adapter to a receipt printer to emulate a HP82240B -- for instance, it could be also useful as an IR-to-serial adapter, forwarding IR data to the USB port (or UART if you need to, and don't have a printer there). This is easy enough to do and it's easy enough to set the system up in that manner, but this state will not persist boot-to-boot. So, time for some persistent settings.

  Most non-volatile memory is known for the exhaustion phenomenon, so you generally try to avoid burning/erasing except when needed. Frankly, for this application: storing user settings, the burning/erasing will naturally happen very infrequently since it is a user-initiated activity that is only occaisionally performed. I'm sure all readers of this log post will have long since passed on to the hackerspace in the sky before they have exhausted the million flash erase-write cycles for settings changes. That being said, like my friend Ming the Merciless says: "I like to play with things awhile, before annihilation." So I'm going to go a little further with this featurette.

  The flash is organized in 'pages' which is the smallest unit of erasure. On this part, the page size is 1 KiB. That should be more than enough for my setting storage -- at least until I have a need for large object like strings -- but for now it's just a few integers.

  What I'm doing in this implementation is to store a struct of my settings in the last page of flash on the device (leaving all the previous pages for the program). That last page will have zero or more copies of the settings. The last copy of the settings is considered the current values.

  So, upon boot up, the code searches for the last copy of settings, and initializes the RAM-based copy with that data. If it doesn't find any settings, then it will intialize the RAM-based copy with the baked-in default values. The rest of the system then proceeds to use whatever is in the RAM-based copy.

  I want to have the RAM-based copy because I want to be able to change settings on the fly via the monitor interface (yet-to-be-implemented; it will be on the USB CDC). When you have the device dialed in the way you like, then you can persist the settings.

  Persisting works like this:

  1. find the last valid settings image
  2. see if there is space after it for one more settings
     a) if there is, that is where we will be programming
     b) if there is not, erase the page, and let the start be the place we will be programming
  3. program the flash at the place we located

  A simple scheme, but I wanted to document it here. This way, the flash exhaustion is reduced by a factor of how ever many settings structures can be fit on a page, which presently for me is 64 (but this will go down as I add more settings, but still).

  Other News

  I did validate my HP82240 printer rasterizer functionality. It was a bit painful, but I managed to dump the image over the serial port, then meticulously hand-craft a bitmap of the data. For example:

  0E 00 00 02 00 00 02 00 04 0E 00 00 00 00 00 00 00 00 00 00 00 
  C2 07 00 02 00 38 02 00 04 08 00 00 00 00 00 00 00 00 00 00 00 
  42 B0 3C 47 04 04 87 E3 25 08 00 00 00 00 00 00 00 00 00 00 00 
  C2 53 45 42 04 38 02 14 14 08 00 00 00 00 00 00 00 00 00 00 00 
  42 50 45 42 04 40 82 17 0C 08 00 00 00 00 00 00 00 00 00 00 00 
  42 50 3D 8A 07 44 4A 14 14 08 00 00 00 00 00 00 00 00 00 00 00 
  CE 17 05 04 04 38 84 E7 25 0E 00 00 00 00 00 00 00 00 00 00 00 
  00 00 04 80 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 

  renders into:

  v       v       v       v       v       v       v       v       v       v       v
  .###.....................#.......................#................#......###...

  Read more »

• Fontastic!

  ziggurat29 • 07/11/2017 at 17:32 • 0 comments

  Summary:

  My hunting for an existing HP82240B font paid off, and a couple days drugery was avoided. I have converted the found glyph images into my personal format and have implemented the rendering engine for the HP82240B data stream.

  Now I am off to work on the physical printer driver. Or not.

  Deets:

  As mentioned in a previous post, I wanted to look for some existing TTF fonts that might already exist for the HP82240B printer. Sometimes folks create these for simulators to give an authentic look to the output. Having such would save me many hours of manually digitizing the 448 code points (well, OK, about 1/3 less than that of /distinct/ code points) from printouts since I already have a tool for rasterizing TTF to my personal font format.

  At first I found 'HP Printer' somewhere, but it was not for this printer, so no good. In the end, I never found a TTF font, but I did stumble across a printer simulator produced by Christoph Gießelink

  http://hp.giesselink.com/hp82240b.htm
  

  and somewhere in my travels (I can't recall where, now, alas; so much searching) I found source code bearing this imprint:

  /*
  These are the HP82240B font tables for the Roman8 and ECMA94 character set.
  
  The code is part of my HP82240B Printer Simulator available at
  http://hp.giesselink.com/hp82240b.htm.
  
  This code is distributed in the hope that it will be useful, but WITHOUT ANY
  WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR
  A PARTICULAR PURPOSE.
  
  There's no licence behind, so use it in any way you like it.
  
  May 2012, Christoph Giesselink
  */

  which I interpret as being functionally public domain.

  The data was not useable as-is because it is in column-major form, and I need row-major. So, 'big whoop', I wrote a little one-off program (significantly derived from my existing TTF rasterizer -- it wasn't that much new work) to do the relevant rotations and emit font data.

  I have no way of verifying it at this time, but the rasterizer program emits comments showing the image form of the bit pattern, so it seems to be good. Here's a couple examples:

  a couple from the ASCII section

  	//glyph for 0x37 (7), 8x6, at offset 184
  	0x00, 	//........
  	0x1f, 	//#####...
  	0x10, 	//....#...
  	0x08, 	//...#....
  	0x04, 	//..#.....
  	0x02, 	//.#......
  	0x02, 	//.#......
  	0x00, 	//........
  
  	//glyph for 0x33 (3), 8x6, at offset 152
  	0x00, 	//........
  	0x0e, 	//.###....
  	0x11, 	//#...#...
  	0x0c, 	//..##....
  	0x10, 	//....#...
  	0x11, 	//#...#...
  	0x0e, 	//.###....
  	0x00, 	//........

  and one from the high set:

  	//glyph for 0x9f, 8x6, at offset 1016
  	0x00, 	//........
  	0x0e, 	//.###....
  	0x12, 	//.#..#...
  	0x12, 	//.#..#...
  	0x12, 	//.#..#...
  	0x00, 	//........
  	0x00, 	//........
  	0x00, 	//........

  and so on, for the 'Roman 8' and 'ECMA94' sets. Yay! Time saved. (I did send a 'thank you' note to Christoph Gießelink for his work.) With that leg-up, I proceeded to implement the printer state machine, and rasterizer.

  As mentioned, for the rasterizer I am reusing some character blitting code I had already produced for another project, so that part was pretty easy. I did hack it to support wide characters and underline mode, and exploit some peculiarities of this printer.

  The state machine wound up being pretty easy, too. There's just a few states for TEXT, GRAPHICS, and ESCAPE states. The TEXT state checks for a couple special characters, and otherwise does a character blit of the incoming character. The GRAPHICS state instead sends the data to a 'bar blt' routine, which sets the pixels in a vertical bar according to the bit pattern of the received data. The ESCAPE state checks for the few known escapes and otherwise interprets the data as the 'length' parameter before transitioning to the GRAPHICS state.

  The machine invokes some callbacks that the user is expected to implement. Notably, the 'image complete' callback is invoked when a carriage return is encountered. The expected implementation would be to do something useful with the completed bitmap before returning...

  Read more »

• Raster Blaster

  ziggurat29 • 07/10/2017 at 15:16 • 0 comments

  Summary:

  Having gotten the peripheral devices supported and abstracted, I'm on to implementing the higher-level objects. The first one I'm tackling is the interpreter/processor of the HP Printer IR data stream. This will maintain the logical state of the printer (current options like font, wide char, bold/underline, X position).

  I am working on implementing the rasterizer of the HP printer data, which will create a bitmap image representing one line of output.

  Deets:

  Since the printer language the HP printer uses is quite different than that of the receipt printer (also the implied character sets), I've decided to treat everything graphically. This means first rasterizing the HP printer's output to an image, and then outputting that image to the receipt printer in it's native tongue.

  The HP 82240B printer has two character sets (the -A had only one, so it's emulation is therefor supported as well), so I'm going to have to go through the tedious process of creating the font for the 256-32=224 X 2 fonts = 448 characters. *sigh* On the positive side, I had completed some character blitting code for a different project a couple months back, so I will reuse that, along with the font format I came up with. It's richer than I need for this, but 'done' is 'done', and there's so much other stuff to do. Also, I'll need to modify it to handle 'wide' mode and 'underline' as well. So there's still some new work to do in that area.

  While I was somewhat dreading this activity as tedium -- and it will be -- there are several simplifications that I can avail myself to in this case. In particular, the HP printer is a line-by-line device, so I only need to rasterize one line's image before emitting it to the physical printer. Additionally, since the HP printer is principally a 5x7 text mode printer (i.e. 6x8 with the inter-character -line spacing), and graphics commands simply set a vertical column of pixels, this means that all my clipping logic will be trivial. Yay, it's the small things in life.

  So really, I think that generating the font data is going to be the bulk of the work for this step.

  I'm reusing a font format I concocted for a previous project. The gist of it is:

  • a header with meta info
  • an array of character descriptors; so variable character width is supported, along with partial character sets (and UCS-2LE if you really need it)
  • an array of glyph bitmaps for those characters

  This is certainly overkill for what I need here, but again, I've already written the code for blitting the characters and I'd really rather reuse that than write yet another blit routine.

  FWIW, the font header is defined as:

  ypedef struct FONT_HDR FONT_HDR;
  struct FONT_HDR
  {
      uint32_t    _nSignature;    //indicates this is a font object
      uint32_t    _nVersion;      //format version
      uint32_t    _nFlags;        //various flags
      uint16_t    _arraylen;      //how many glyphs in this font
      uint16_t    _height;        //common glyph height (pel)
  };

  The signature looks like 'FONT' in a hex editor. The version is 1. The flags indicate the packing of the glyphs (byte, word, dword), whether it is MSB/LSB first, and whether the glyph is mirrored in X and/or Y (not needed here).

  The character descriptor is defined as:

  typedef struct FONT_CHARENT FONT_CHARENT;
  struct FONT_CHARENT
  {
      uint16_t    _charval;    //UCS-2LE of this character
      uint16_t    _width;      //this glyph width (pel)
      uint32_t    _offset;     //relative offset from start of font image
  };

  So, to blit a character, you do a lookup of the character descriptor via binary search, and then you can determine the address of the glyph bitmap, the width, and the height for the blit operation.

  For bitmaps, I generally prefer LSB first. The reason is that this gives me the freedom to choose 8-bit, 16-bit, or 32-bit IO operations directly from the buffer without having to bit shuffle. (Well, on a little-endian machine, but come on, little-endian is the one true way.) This will be a minor annoyance later when I transform the HP printer bitmap into physical printer output data, since that data is MSB...

  Read more »

• USB, what you want to (and all you need is to get your boogie down)

  ziggurat29 • 07/09/2017 at 17:37 • 0 comments

  Summary:

  Despite having peripheral libraries, implementing the USB CDC interface was even more painful than the UART serial. But now the deed is done.

  I'm now moving on to processing the incoming printer data stream, and rasterizing output to be printed.

  Deets:

  The USB CDC implementation is provided by what ST calls 'middleware'. USB is a byzantine protocol, and the on-chip peripheral IP has a myriad of registers to understand if you were attempt to hand-roll it. So, yeah, I had a good reason for taking the easy way out. But, alas, the implementation of this component was worse than the UART from before (well, worse to my tastes, at least). Amongst the problems I had with it were:

  1. the USBD_CDC_ItfTypeDef is a C style 'interface': a struct of function pointers. These functions are implemented by you (with skeleton generated from ST32CubeMX) and include things like 'initialize', 'deinitialize', 'control packet', and 'received data'. But notably absent is 'transmit complete'. So, you cannot know when a transmission you have started is completed so that you can continue with subsequent transactions. The sample projects use a timer to poll for completion periodically. Polling? Yuck! Fer real?
  2. there is a TX buffer declared in the generated code, but it's usage seems odd because the generated code seems to not use it at all. It is referenced only once, with a length of 0, and all subsequent transfers bind the caller supplied buffer. Hmm.
  3. the RX callback function seems odd in that it seems to assume that you can take all the data in the buffer you bind. There is a length param that is a pointer, so presumably you can alter it, but doing so would run counter to the caveat communicated in the @note (which implies you must take it all before returning from the method or there will be lost data). Hmm.

  The first item is especially problematic because there is no way to add the TxComplete notification without editing the generated code. This means if I need to re-run STM32CubeMX (and I do all the time), my changes will be overwritten. Yuck.

  OK, I simply have to have these changes -- I'm not doing this polling thing. That means I will have to re-apply the changes when I re-run the tool, so obviously I have backed up copies so I can re-apply them, though this is tedious. Additionally, the nature of the changes I have made are such that if they were to be overwritten, that the result will still build successfully, but it will not run correctly (the callbacks will never be called). Since this is a debugging time waster (you will one day forget to manually apply the changes), I have added a do-nothing API in the area with those changes that gets called early in main. It is a waste of code space, but at least it will cause linkage to fail if I do not re-apply the required changes. And obviously I have also left a comment at the call site to the effect of 'if this fails to build, you need to apply the xxx changes at yyy'.

  The second item is problematic for several reasons; one, if the buffer is not going to be used, then why does it need to be defined at all (wasted RAM), and two, by binding the caller supplied buffer in the public API CDC_Transmit_FS(), there is now an assumption that the pointer will remain valid long after the call returns, to be used later during subsequent transmission activities (ostensibly at ISR time). This precludes common use cases like this:

  void ShowMeTheMoney ( float fSmackers )
  {
      char achBuffer[128];
      int nLen;
      //need linker flag "-u _printf_float" and it will incur ~12k code penalty
      nLen = sprintf ( achBuffer, "You have $%0.2f smackers\r\n", fSmackers );
      CDC_Transmit_FS ( achBuffer, nLen );
  }

  because the buffer must be of long (and indeterminate!) duration outside this function's scope. So you'll either have to define your own long-lived buffer and copy into it (and arbitrated it as a shared resource, etc.) or some other scheme to work around the nature of the API.

  The third item is worrisome; I'll have to study the implementation...

  Read more »

• ​Home on the Range (of the IR)

  ziggurat29 • 07/07/2017 at 17:58 • 0 comments

  Summary:
  

  Unscientific tests show that range is good; 5 meters has been actually tested, but it is probably a bit more.

  Deets:

  It's a bit annoying when testing to point the calculator at the sensor and get then aim right and then press the button (I know -- so lazy). The calculator that I'm using for testing has a book-like folding design, so if I open it about π/3 radians, it will stand up on its end, with the IR emitter pointing upwards towards the ceiling. Situated this way, my detector board is next to it with the detector pointed up as well. So, the signal path is out of the calculator, up to the ceiling, reflecting, and back down to the detector.

  I was happy to find that the signal along this path gets reliably decoded. I measured the distance from the desktop to the ceiling at about 2.5 meters, so the total path is about 5 meters -- and who knows how much loss there is from the imperfect reflector of the matte white ceiling.

  Nice! I think the IR part can now be considered good enough for production use, though I still may try some of the optimizations I mentioned in earlier posts.

  The resulting API is

  //valid data received
  void IR_RedeyeCbk_data ( uint8_t by );
  
  //parity bits included
  void IR_RedeyeCbk_parityFail ( uint16_t val );
  
  //bad signal was detected
  void IR_RedeyeCbk_badSignal ( void );

  Next:
  

  I'm back on implementing USB CDC device mode.

View all 21 project logs