Skip to main content

Topics

This section allows you to view all Topics made by this member. Note that you can only see Topics made in areas you currently have access to.

Topics - honken

1
Project logs / Holonomic platform
In an off forum discussion with matseng I told him I had some pcbs made at seeed with internal milling.
They have arrived and turned out great.

[attachment=0]

The milling was drawn in layer 46 milling placed in the .GML gerber file. A single notification when I sent the files to seeed and the result is shown above.

I also make this as an excuse to present a project I'm working on.
A holonomic robotic platform. Not much electronic work yet apart from the sensor board, but if you are interested you can read about it http://http://www.electrohome.se/.

In the future I will explain more technical stuff instead of just recapitulating past events.
2
Sick of Beige / PCB template suggestions
A minor suggestion for the PCB Template

Add an attribute to the device named BATCHNO and a text to the package on the bDocu layer saying ">BATCHNO" (mirrored)
Then when ordering the board from seeedstudio fusion service, just edit the attribute value and the text on the board gets updated.

The first argument against it being that not everybody uses seeed and don't need this feature, it could uglify the board.

EDIT! Just remembered there's a bug tracker, I'll head over there...
4
General discussion / QR in eagle
Hi all,

As i was preparing some boards for manufacturing (perhaps a 7400 entry) I thought it would be fun to partake in Itead's OpenPCB program. But that requires me to have some identifying mark on my board and I thought a QR code would be perfect.

The bmp import in eagle as some room for improvement so I skipped that and wrote my own.
As I was writing I found out that the latest eagle (5.11.0) can do http get/post statements in ulp.
So here it is, dynamic pcb qr code generation with the help of Web 2.0...

Hope somebody will find it useful. No rights reserved. It's just a little midnight hack, so expect bugs.

unzip and rename to .ulp

[EDIT]Look futher down this thread[/EDIT]
5
Open source USB stack / Looking for bootloader wizzards
I have written most of a DFU implementation of a bootloader.
It is probably bug ridden but it compiles.
My problem right now is writing a stable init for the pic24f. Especially one that plays nice with c30 compiler init code. It also should be able to steal the execution environment (reset stack and inhibit interrupts).

On a side note. When Ian have been laboring cleaning up the svn, where should i post the codes? They are not in a million miles ready for production yet. Perhaps I could start a github project.
6
Bus Pirate Development / BPv4 Case suggestion
Hi all,

A little off topic...

As I have always dreamed of having a CNC-mill, it thought I had to try to model something in OpenSCAD.
What better than a case for the next generation buspirate?

This is my first attempt at designing hardware (as in hard metal objects) so do NOT assume it is possible to mill or print this directly.

The reason for posting is to get some learning points from someone more experienced as well as planting the idea to make a really finished product out of the dangerous prototype that is the bus pirate. (At version 4 most child deceases should be fixed)

In my head I see this milled out of aluminum and anodized black, perhaps with some silk-screened white ink...

Any way, enjoy, dismiss, improve or ignore.
7
Open source USB stack / Type of blob for DFU
I have implemented most of the dfu class.
There are mechanisms for reenumeration and a state machine for the protocol.

The theory is pretty simple.
1. Enumerate as a DFU device.
2. Host compares descriptor details with a dfu suffix of the new firmware file.
3. If everything checks out (or the host feels lucky) ie Correct VID/PID/bcdDEV/ the host send the blob of the new firmware file. (in multiple chunks)

As I have it right now is that the blob of the firmware is a binary image for program rom.
This is the simplest variant, but I can think of some other variants as well.

  • Binary image (as today)
    • +Simple
    • -Large
    • -Flashes "empty" pages
    • -Require linker script for usb_stack reuse
    [/li]
    • IHEX
      • +Smaller
      • +No unnecessary flashes
      • +Direct from linker usage
      • -Not necessarily in sequential order?
      • -Require linker script for usb_stack reuse
      [/li]
      • COFF/ELF
        • +Binary=even smaller
        • +Relocatable, final linking on device - No linker script
        • - No bintools for COFF
        • - No ELF for all intended targets ie. p18fxxxx
        [/li]
        • Our own protocol
          • + Just the functionality we need
          • - Probably going to be in constant flux, not future compatible
          [/li]
          [/list]

          What are your thoughts?
          8
          Open source USB stack / honkens' open source usb stack
          Here's a little code drop.
          I have only looked at other open source code while developing it. Especially http://pe.ece.olin.edu/ece/projects.html.

          This project implements USB CDC ACM aka. USB-serial on a 18F4550.
          As such it should run pretty much unaltered an the USB IR Toy. I haven't got one of them so I can't know for sure.
          Include search paths are probably not correct in the .mcp/.mcw, and processor setting and linker script are certainly not correct.
          All #pragma's in main.c should also be considered suspect if compiling it for any other board than mine. (Mine is a home built CREATE USB Interface http://www.create.ucsb.edu/~dano/CUI/).

          The main program is running an echo server. All char's received are transmitted.
          Except for the very first one, for some reason I can't figure out at this time of night.
          If compiled with DEBUG setting (__DEBUG macro defined) it will output some extensive info on the USART.

          The cdc.[c|h] files implement an API that mimics the USART library that comes with MCC18.
          But, as the usb stack isn't implemented with interrupts yet and getcCDC is a blocking call, you can expect to halt your firmware using it unwisely.

          You should also supply your own VID/PID pair. Remember to also change in the .inf-file.
          And on that subject, the .inf-file (and the .cat) is the result of blindly trial and error, so don't expect it to be correct in any way.

          This is my first working attempt at a usb stack.
          My intentions are to develop a DFU class based bootloader and reuse the bootloader usb code as a library to the application.
          The API as it is now doesn't support that as I am very found of c macros and tries to do too much at compile time.
          So don't expect any future code from me to be backwards compatible. Rather expect to see something totally different.

          Also, the code isn't very optimized, that will come after I have settled on an API.
          But if anyone takes a look at it, how would you prefer interacting with descriptors and messages; indexed byte arrays or structs?
          Is there perhaps some compiler optimization possibilities or portability issues here? With the current implementation, I wouldn't think the code is portable to a 16 bit platform without some work.

          As for optimization, should I strive for code size or speed? How costly is a call/ret, goto/goto vs in-lining 2-3 loc c. How does it differ in interrupt context?

          There are some many questions, so little time...
          9
          Web platform / Secondary Oscillator not running
          Hello all.

          I'm having trouble starting the secondary oscillator.
          According to the schematics and visual inspection there is an 32.768kHz x-tal on the SOSCI/SOSCO pin pair.
          I modified the code so that the OSCIOFNC bit (#2) is set in the FOSC register and that the LPOSCEN bit (#1) is set in the OSCCON register.
          I'm currently trying to confirm that they are really set, the OSCCON register is written by the __builtin_write_OSCCONL() function so it schould work.

          But the result is that the RTCC isn't running and there is no activity on the SOSCI/SOSCO pins per oscilloscope inspection. Both pins are 0V.

          Have anybody else tried to start the secondary oscillator, with success?
          What extra setting have I missed?
          Can it be that I have a faulty x-tal, caps or perhaps a short somewhere, if so any suggestions to help me find it would be appreciated.

          Otherwise I got it running smoothly with a Microchip 3202 SPI ADC connected to a LM35 and HIH4000 as well as a pair of DIL relays.
          Web Orchid Greenhouse well on its way.
          Next thing is to attach a JPEG Camera as well.

          Thank you
          Tomas