This is somewhat offtopic, but I have a few Palm foldable keyboards sitting around that I would like to make use of. First problem: the keyboard uses a proprietary 10-pin connector. Solution: download a cad file from github.com/cy384/ppk_usb and 3D print it. Second problem: I don't own a 3D printer, so how do I print it?
I found that our local library (rodgerslibrary.org) has a 3D printer, and will print things for 10 cents per gram. The cost of printer filament alone often runs 2-3 cents per gram, so that's a really good price. It's a TKI 3D printer, and they have a selection of PLA filament in various colors. To use it, I converted the cad file to .stl, and took it to the library on a USB stick, where Linda processed it and set up the printer. Library personnel do all the actual handling of the printer - no gefingerpoken by the lookenspeepers. This object was about 2 grams, so it cost me all of 20 cents to get it printed. It took about 25 minutes - could have been faster, but she decided to run the printer at low speed for something this small. It's a library, so there's plenty to look at while waiting.
First step was to download the appropriate cad file from cy384's github site. It's designed in openscad, which is in the Debian repository, so I installed that. Importing the *.scad file and exporting an .stl file took only a few seconds. The longest dimension is about 3 cm.
And here's the finished product, with a penny for size reference. The object is flipped in this photo: the front in the openscad screenshot is the back in this photo. The printer software automatically added the panel so it would stick to the base while printing, and it added the supports so the ears could be printed properly.
Here it is sitting on the keyboard connector after a little bit of trimming with a sharp knife.
And here it is fully plugged in. Fits snugly and perfectly, so the design was good, and the printer did its job well. Next step is to wrap wires in the slots to make contact with the pins, and then I can start working on the software.
So if you're within driving distance of the Hudson, NH library and have an occasional need for 3D printing, it's a great resource. They have a shelf full of PLA filament in various colors. Check the library website for days and times the printer is available. The librarian did say they only run the printer when the library is open, so make sure your print jobs take less than 12 hours.
There's only one machine and printing takes a long time, so there might be a queue. I went in on a Monday night and there was no wait - your mileage may vary.
Thursday, July 13, 2017
Thursday, November 17, 2016
STM32F042 USB quirks with libopencm3
Needed a simple microntroller for an RF project, so picked the STM32F042F6P6 from ST. It's cheap, comes in a 20-pin package, and has a built-in full speed USB device interface. It has an internal oscillator that can be synced to the USB signals from the host, so it doesn't even need a crystal.
It has a built-in DFU bootloader (among other programming options), so it requires no additional hardware to load the program.
After getting a simple LED blinker program to run, I decided to run some USB demo programs from the LIBOPENCM3 package. None of the demos are for this exact chip, but some are for the STM32F072, which is similar. Tried the
Turns out, there are a couple of subtle differences between this chip and the ones in bigger packages
Libopencm3 is at github.com/libopencm3/libopencm3
For programming, I use dfu-util: dfu-util.sourceforge.net. It's already included in Debian and probably other distributions.
It has a built-in DFU bootloader (among other programming options), so it requires no additional hardware to load the program.
After getting a simple LED blinker program to run, I decided to run some USB demo programs from the LIBOPENCM3 package. None of the demos are for this exact chip, but some are for the STM32F072, which is similar. Tried the
tests/gadget-zero
sample and ... No Go. The program loads and the LED's blink, but the USB device does not show up.Turns out, there are a couple of subtle differences between this chip and the ones in bigger packages
- The USB interface pins are shared with two other pins, and by default the USB pins are not connected to the outside world. Need to set a configuration bit so they can be used.
- The peripheral clock needs to be turned on for the SYSCFG subsystem. I'm not sure whether that's a difference in the chips, or a quirk in libopencm3, but it's needed.
where the highlighted lines had to be added. With those two lines, gadget-zero shows up as a USB device in Linux. I was also able to the a cdc_acm demo working.rcc_clock_setup_in_hsi48_out_48mhz(); rcc_periph_clock_enable(RCC_SYSCFG_COMP); SYSCFG_CFGR1 |= SYSCFG_CFGR1_PA11_PA12_RMP; crs_autotrim_usb_enable() rcc_set_usbclk_source(RCC_HSI48)
Acknowledgments
Several websites mention the pin-remapping issue, but the IFUSB project (github.com/julbouln/ifusb) was where I found the clock-enable issue and solution. IFUSB looks like a nice little peripheral, by the way.Libopencm3 is at github.com/libopencm3/libopencm3
For programming, I use dfu-util: dfu-util.sourceforge.net. It's already included in Debian and probably other distributions.
Wednesday, September 28, 2016
Offtopic: phone scam
This was interesting. I got a scam phone call this morning. My best attempt at a transcription as follows:
Hi, my name is Keith Jordan, and this message is intended to contact you regarding an enforcement action executed by the United States Treasury,I recorded this to my computer by holding the phone in front of the microphone while playing back the message, and then merging the audio with a photo of the caller id using:
intending your serious attention.
Ignoring this will be an intentional second attempt to avoid initial appearance before a magistrate judge or a grand jury for a federal criminal offense.
My number is 817 533 9843
I repeat it's 817 533 9843
I invite you to cooperate with us and help us to help you.
Thank you.
ffmpeg -i /tmp/x.jpg -i scam.wav -acodec copy /tmp/simple.mov
I can display and play the result using mplayer on Debian Linux, not sure how it works anywhere else.
Us Treasury says to report this sort of thing:
www.treasury.gov/services/report-fwa/Pages/Report-Email-Scams.aspx
We'll see what happens.
Monday, August 22, 2016
Presentation: Codecs for Land Mobile Radio
Marina in front of Wentworth on the Sea. |
The talk is an overview of speech codecs and their application in digital Land Mobile Radio systems. It's intended for an audience of radio system users and specialists rather than voice codec experts.
Slides for the presentation are online at:
joe1505.github.io/talks/index.html
Tuesday, February 23, 2016
Mobile-friendly web page
Decided it's time to make my websites mobile-friendly, since Google seems to consider that important these days. So I ran the tester at
which identified about 30 errors, including "Links too close together" and "Text too small to read" on multiple items. The latter error is particularly interesting because I typically use not-too-fancy html+css, and I don't set the font size anywhere. One of the main features of html is the separation of content and presentation, so decently written html should not require much tweaking for different displays. The html markup tells what things are, and the browser should be able to figure out a reasonable way of displaying those things.
After a little digging, I found the first step in mobilifying a web page is to add the magic incantation:
As it turns out, that's the last step as well: All the other error messages went away when I added that one line. As I understand it, that line basically tells the browser "just use html the way it's intended to be used" and then everything is fine.
which identified about 30 errors, including "Links too close together" and "Text too small to read" on multiple items. The latter error is particularly interesting because I typically use not-too-fancy html+css, and I don't set the font size anywhere. One of the main features of html is the separation of content and presentation, so decently written html should not require much tweaking for different displays. The html markup tells what things are, and the browser should be able to figure out a reasonable way of displaying those things.
After a little digging, I found the first step in mobilifying a web page is to add the magic incantation:
-
<meta name=viewport content="width=device-width, initial-scale=1">
As it turns out, that's the last step as well: All the other error messages went away when I added that one line. As I understand it, that line basically tells the browser "just use html the way it's intended to be used" and then everything is fine.
Reorganizing this blog.
I decided it's time to reorganize the domain name setup for this blog. Previously, it was accessible via two web addresses:
One side effect of this setup is that the blog's cookies are set up under my sensicomm.com domain. I decided that I don't like the idea of scripts that I didn't write and don't control running under the identity of a domain that I do control.
So in the new setup this blog is still accessible and will appear unchanged using the blogspot address. The sensicomm address contains static copies of all previous postings, but not any comments made on those postings.
If you have a web site containing a like to an old blog post, you might want to update the link. For example,
The old address of this post[1] now points to the static copy of that post, while the new address[2] contains both the post and any comments.
One side effect of this setup is that the blog's cookies are set up under my sensicomm.com domain. I decided that I don't like the idea of scripts that I didn't write and don't control running under the identity of a domain that I do control.
So in the new setup this blog is still accessible and will appear unchanged using the blogspot address. The sensicomm address contains static copies of all previous postings, but not any comments made on those postings.
If you have a web site containing a like to an old blog post, you might want to update the link. For example,
The old address of this post[1] now points to the static copy of that post, while the new address[2] contains both the post and any comments.
Thursday, October 29, 2015
Lattic iCEcube2 on Debian
I recently started looking at Lattice chips for a project that needs a fairly small FPGA. They have small devices that are significantly lower in cost than the larger Xilinx Spartan chips I've used in the past. To explore further, I ordered the ICE40HX1K eval board ($22) and downloaded the free iCEcube2 IDE for my Debian stable(Jessie) 64-bit PC.
The first try at installing the IDE hit issues:
error while loading shared libraries: libXext.so.6: cannot open shared object file: No such file or directory
The library is installed, so obviously the IDE wants the 32-bit version. I haven't tried to work with 32-bit stuff since Debian went to the multiarch approach, so that led to a new learning experience. Previously one would install ia32 versions of the needed libraries. After a bit of googling, I found that the current approach is (as root, or using sudo):
dpkg --add-architecture i386 # Include 32-bit stuff
apt-get update # Add in the lists of 32-bit packages.
apt-file search libXext.so.6 # Find out what package I need - libxext6 in this case.
apt-get install libxext6:i386 # Add the 32-bit version of thepackage.
Now, the install fails because it's missing libpng12.so.0, so repeat the apt-file search and apt-get install steps for that. In Total I ended up installing libpng12-0:i386, libsm6:i386, libxi6:i386, libxrender1:i386, libxrandr2:i386, libxfixes3:i386, libxcursor1:i386, libxinerama1:i386, libfreetype6:i386, libfontconfig1:i386, libglib2.0-0:i386.
With that, iCEcube2 installs and runs.
Now I can start playing with the eval board when it shows up.
The first try at installing the IDE hit issues:
error while loading shared libraries: libXext.so.6: cannot open shared object file: No such file or directory
The library is installed, so obviously the IDE wants the 32-bit version. I haven't tried to work with 32-bit stuff since Debian went to the multiarch approach, so that led to a new learning experience. Previously one would install ia32 versions of the needed libraries. After a bit of googling, I found that the current approach is (as root, or using sudo):
dpkg --add-architecture i386 # Include 32-bit stuff
apt-get update # Add in the lists of 32-bit packages.
apt-file search libXext.so.6 # Find out what package I need - libxext6 in this case.
apt-get install libxext6:i386 # Add the 32-bit version of thepackage.
Now, the install fails because it's missing libpng12.so.0, so repeat the apt-file search and apt-get install steps for that. In Total I ended up installing libpng12-0:i386, libsm6:i386, libxi6:i386, libxrender1:i386, libxrandr2:i386, libxfixes3:i386, libxcursor1:i386, libxinerama1:i386, libfreetype6:i386, libfontconfig1:i386, libglib2.0-0:i386.
With that, iCEcube2 installs and runs.
Now I can start playing with the eval board when it shows up.
Notes:
hackaday.io/project/6592-dipsy/log/24272-installing-icecube-2-on-ubuntu-14042-lts Pointed me in the right direction to complete the install. Their Dipsy project uses the Lattice chip, and looks interesting.
Subscribe to:
Posts (Atom)