Mercurial > whatever / changeset

--- a/content/hp34970a_3.rst	Thu Jul 21 10:41:14 2016 +0200
+++ b/content/hp34970a_3.rst	Sat Sep 17 02:08:03 2016 +0200
@@ -81,21 +81,25 @@
 Let's say the frame is: ``<0x0A> <0x04> <F1> <F2> <F3> <F4>``, then:
 
 
-- F1.7 = 
-- F1.6 = 
-- F1.5 = 
-- F1.4 = 
-- F1.3 = 
+- F1.8 = 
+- F1.7 = HI
+- F1.6 = Alarm
+- F1.5 = LO
+- F1.4 = Channels
+- F1.3 = Channels box
 - F1.2 = Mx+B enabled
 - F1.1 = Alarm enabled (or the alarm frame)
   
 - F2.5 = 4W
-- F2.4 = 
-- F2.1 = 
+- F2.4 = Alarm 1 ?
+- F2.3 = Alarm 3
+- F2.2 = Alarm 4  
+- F2.1 = Alarm 2
 
 - F3.6 =
 - F3.5 =
   
+- F4.8 = 
 - F4.7 = CONFIG (not sure)
 - F4.6 =
 - F4.5 = MON

--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/content/hp34970a_4.rst	Sat Sep 17 02:08:03 2016 +0200
@@ -0,0 +1,161 @@
+==========================================
+ HP 34970A Data Acquisition Unit - part 4
+==========================================
+
+:Author: David Douard
+:Category: Electronics
+:Tags: HP, 34970A, DMM, repair, test equipment
+:series: HP 34970A repair
+:series_index: 4
+
+
+After a summer pause, I'm back on my HP34970A replair project.  In
+`the previous post in this series <{filename}/hp34970a_3.rst>`_, I've
+started to reverse ingineer the serial protocol between the CPU board
+and the fonrt panel, and implement a prototype of replacement display.
+
+
+OLED display
+============
+
+I bought the bigest OLED display I could find (at a reasonable price)
+that would fit in the front panel assembly. It's a `blue 256x64 OLED
+display`_ drived by a SSD1322 controler.
+
+.. _`blue 256x64 OLED display`: http://www.buydisplay.com/default/oled-3-2-inch-displays-module-companies-with-driver-circuit-blue-on-black
+
+.. image:: {filename}/images/hp34970a/oled_module.jpg
+   :alt: 3"2 blue OLED module used as a replacement display for the HP34970A.
+
+My first problem was to drive the display from my Nucleo board. I
+couldn't find graphic library that worked directly. I was already
+using the UniGraphic_ library with the small TFT display, so I decided
+to implement support for this OLED module in the library.
+
+.. _UniGraphic: https://developer.mbed.org/teams/GraphicsDisplay/code/UniGraphic
+
+I spent quite some time to make this work for several reasons, among
+others:
+
+- I was first using my Nucleo F031K6 board; it's nice, it's small, but
+  it only have 4k of RAM, so the malloc I as doing in my test code to
+  allocate the "framebuffer" in which drawings are done before being
+  tranferred to the display module... well let's say if I took time to
+  check the return value of the malloc call (which one should always
+  do, even on small embedded devices), I would have not lost a couple
+  of hours, so to speak (tip: allocating 8k in a 4k RAM will not fit),
+
+- The SSD1322 controller is *reasonnably* well documented, but what's
+  not documented is how it is used on the OLED display... In fact,
+  once I could at least see some pixels on my display, I spent quite
+  some time trying to control where my pixels are located on the
+  module. There is not that much demo material available for this
+  module besides a `poorly written sample C code`_ (in a .txt file!)
+  for the 80C51 processor. What's hidden in this file (which I could
+  not fing any where else) is the magic 0x1C value which must be given
+  as first argument to the SET_COLUMN_ADDR "function" of the SSD1322.
+
+- I also lost some time trying to implement the support for this module
+  as a class derived from UniGraphic's `LCD class`_ (like several
+  other supported modules like the SSD1306_), but that was a mistake,
+  since this kind of OLED module is too different from both a TFT
+  display or a monochrome LCD display. So I've reimplemented the class
+  as a derived class of the GraphicDisplay_. This work is far for being
+  finished yet (and ready for a *Pull Request* to submit to the
+  UniGrahic project), but at least, I can continue my work on the
+  HP34970's display.
+
+
+.. _`LCD class`: https://developer.mbed.org/teams/GraphicsDisplay/code/UniGraphic/file/tip/Display/LCD.h
+.. _SSD1306: https://developer.mbed.org/teams/GraphicsDisplay/code/UniGraphic/file/tip/Inits/SSD1306.h
+.. _GraphicDisplay: https://developer.mbed.org/teams/GraphicsDisplay/code/UniGraphic/file/tip/Graphics/GraphicsDisplay.h 
+.. _`poorly written sample C code`: http://www.buydisplay.com/download/democode/ER-OLEDM032-1_DemoCode.txt
+
+
+Improving the serial sniffer
+============================
+
+Once I could draw pixels on my OLED module, I put this code in my
+existing prototype replacing the simple display code I used with the
+TFT module.
+
+And one problem I already had with the previous "working" prototype
+became bigger: I was missing many characters on the serial bus between
+the CPU and the front panel.
+
+My first implementation of the protocol sniffing was very tedious and
+poorly written. It was not reading at all the traffic on the Tx line
+(ie the key strokes), so I was never sure if a 0x66 was the beginning
+of a transmission or some payload for which I missed the beginning.
+
+Using the interrupt-based (asynchronous) BufferedSerial_
+implementation did not help that much.
+
+So I rewrote this part of the using 2 serial ports, using only the Rx
+line on both of them, one plugged on the Rx line of the serial
+communication, and the other on the Tx line of this comm. Doing so I
+can sniff the whole communication between the CPU and the display
+panel and make a way better protocol interpreter.
+
+The result was way better than before, and now I was able to detect
+the protocol interpretation errors, but still, I was missing many
+parts of the transmission.
+
+I ended up to figure that the culprit was my
+``SSD1322::copy_to_lcd()`` method: it takes almost 20ms to transmit
+the whole display content the module. And with the way my code was
+written, even with interrupt driven serial handlers, these interrupt
+were not captured during the execution of this copy routine.
+
+At this point, I've started to read a bit more the asynchronous and
+event driven APIs of the mbed platform, but could not clearly see a
+pattern to prevent this long "frozen" periods during which I was
+unable to capture serial communications.
+
+.. _BufferedSerial: https://developer.mbed.org/users/sam_grove/code/BufferedSerial/
+
+I was almost ready to use 2 microcontrollers for the job: one to sniff
+and interpret the serial communication and one to drive the display.
+
+.. image:: {filename}/images/hp34970a/poc_oled.jpg
+   :alt: Improvment of the POC based on the Nucleo F446RE and using a blue OLED module.
+
+Improving the tasks
+===================
+
+But I've discovered a few days ago that the RTOS project is now part
+of the mbed platform, allowing to use threads instead of pure event
+driven code. So I tried to put the copy_to_lcd routine executions in a
+dedicated thread, and bingo, I've got now something that begins to
+work enough to make it usable:
+
+.. dailymotion:: x4tib5s
+   :width: 270
+   :height: 480
+
+
+What's next
+===========
+
+There is still a lot of work to do:
+
+- improve the display reactivity: I'll probably try to implement
+  partial copy of the display instead of sending the whole
+  "framebuffer" each time something is changed on the display (the
+  SSD1322 allows to specify a "window" in which to send data),
+
+- improve overall display organisation and find the missing flags (I
+  still have not found the flag values for OC, MIN, MAX, AVG, ONCE,
+  AUTO and MEM),
+
+- try to install the display module and the Nucleo board in the front
+  panel assembly (I don't want to go for a specifically designed PCB,
+  at least for now),
+
+- publish the code.
+
+
+
+
+
+

Binary file content/images/hp34970a/oled_module.jpg has changed

Binary file content/images/hp34970a/poc_oled.jpg has changed

--- a/pelicanconf.py	Thu Jul 21 10:41:14 2016 +0200
+++ b/pelicanconf.py	Sat Sep 17 02:08:03 2016 +0200
@@ -55,11 +55,10 @@
 LINKS = (('Pelican', 'http://getpelican.com/'),
          ('Logilab.org', 'https://www.logilab.org/'),
          ('EEVBlog', 'https://www.eevblog.com/'),
-)
+         )
 
 # Social widget
-SOCIAL = (('twitter', 'https://twitter.com/douardda'),
-)
+SOCIAL = (('twitter', 'https://twitter.com/douardda'))
 
 DEFAULT_PAGINATION = 10
 
@@ -68,7 +67,7 @@
 
 STATIC_PATHS = ['images', 'pdfs']
 
-PLUGIN_PATHS = ['pelican-plugins',]
+PLUGIN_PATHS = ['pelican-plugins', 'pelican-plugins/pelican_dailymotion', ]
 PLUGINS = ['better_figures_and_images',
            'sitemap',
            'feed_summary',
@@ -76,9 +75,10 @@
            'series',
            'related_posts',
            'filetime_from_hg',
-]
+           'pelican_dailymotion',
+           ]
 RESPONSIVE_IMAGES = True
 TYPOGRIPFY = True
 SINGLE_AUTHOR = True
-MINT=True
+MINT = True
 SITEMAP = {'format': 'xml'}