-
SC8 over, short break
11/04/2024 at 21:34 • 0 commentsGoing to rest up a bit and take a break now that Supercon is over.
No promises but before the end of the year I should finish assembly of all the extra nametags I have.
I also want to get the infrared code working. With updated firmware, you’ll be able to sync a contact card with someone else’s nametag, so maybe you can remember each other later. Most of the hard code is done - it’s about finishing and testing it.
RGB programs didn’t get touched like I wanted so expect several more with all program variables documented by the end of the year as well.
-
Progress 20241031
10/31/2024 at 16:56 • 0 commentshave 33 units ready for supercon. ready meaning the hardware is built; they're not tested and firmware isn't flashed. won't be flashing firmware until I can fix up a few more things for release.
lots of features I wanted to get done won't get done in time because hardware assembly went so long. will see what I can accomplish at con.
parts for another 30 or so addons are at the final assembly stage so those will be soldered on the first day. should have >60 nametags good to go by noon or so on the first day. not my initial target of over 100 but it's what I was able to deliver with a one week assembly and coding window.
hopeful to have 70-80 total roaming around the con. I don't plan on working on nametag hardware beyond the first day, instead focusing on software. hopefully I'll have time to walk around and see what people are doing or help people learn i2c but I feel like I am going to be drowned in making the features of the nametag work.
-
Progress 20241030
10/30/2024 at 08:13 • 0 comments0100:
all top and bottom boards designated for Supercon are soldered. now I need to fix acrylic parts, tape and stick acrylic, solder OLED top to board, then solder assemblies to bottom boards. Most of these steps are fast.
almost out of acrylic tape parts. need to cut more on the laser. will do that tomorrow evening, but…
out of time for assembly. hoping I can get all my errands done early enough to fit a few more hours in tomorrow. was hoping for a day and a half more for code but … not sure about that now.
-
Updates 20241029
10/29/2024 at 09:59 • 2 comments0300:
I am still utterly drained. Tried to sleep to reset sleep schedule but only kinda napped for an hour and a half.
Back to soldering. This is my last day of soldering. I need a day to prep the vehicle for the trip and take care of other things, and the code still needs a LOT of work to be where I want it to be.
0730:
Nowhere close to done. Numerous roadblocks. There were 4 discrete steps but that’s now at about 6. I am at 90%, 55%, 35%, 6% and 6%. sleep is screwed up and having nerve / spasm issues. will keep pushing to get this all done.
1745:
Still super far behind. Slept a little bit. Finding more issues with my assembly. Only 10% are finished but at least I am at the last assembly steps. Counts are 100%, 55%, 35%, 19% and 10%.
1900:
100%, 70%, 35%, 19%, 19%, 19%.
2230:
100%, 70%, 65%, 37%, 37%, 25%.
2355:
100%, 70%, 65%, 37%, 37%, 37%.
Only 30 units done…
-
thoughts on CH592
10/28/2024 at 14:46 • 0 commentsthe nametag uses CH592 as main MCU for the nametag. why? there's a few reasons for this choice:
- peripheral support needed for this project is minimal
- it's a small and inexpensive mcu
- ...which has lots of flash storage space, which I need
- it has BLE, which I might use in the future... who knows. it's also very low power in BLE receive mode, just 3.5mA
- crystal needs no caps as bias is configured internally
- may not need a matching network for some RF designs but I haven't read into how this works yet
- adc has native "TouchKey" support, which works pretty well and is ridiculously easy to use
- supports USB device OR host, has RTC
but still ... why CH592? after all this MCU has some cons as well:
- not many peripherals
- hardware I2C shares pins with debug, and has no remap
- CH59x comes with debug locked, so first thing I have to do is connect USB just to be able to use the debugger...
- timers are only sourced from system clock, which sucks
- execution from flash memory sucks. datasheet specifies "zero-wait at the system frequency of 20MHz" though any registers relating to setting wait states are undocumented. it sure feels slower even at 16MHz but I haven't tested it yet. flash and RAM both go through the main bus in this design so there's no special benefit to executing from flash instead of RAM as there is in other designs. rather there's a negative: significantly higher power consumption and significantly slower execution speed.
- on that note... the datasheet is very terse and is missing information. sometimes it blatantly says to check example code, or it even says it will not document certain functions...
so why did I settle on CH592?
ultimately, the main factors were as listed above, but the big one was flash storage. I knew I was going to reuse the nametag code, and I haven't had time to rewrite the code to use external storage for fonts. I'll get to this eventually but I don't have time to do it now, so large flash it is. CH592 is extremely cheap for having 448K standard flash. How far we've come...
actually, I wanted to use this part until I read through the datasheet. knowing this nametag would be I2C heavy - particularly with OLED updates - I wanted a working hardware I2C peripheral, ideally with DMA so the CPU could save power. CH592 has a hardware I2C peripheral but it's on the same pins as debug, which disqualified it. debug is important. power consumption during execution was really low however: executing from RAM at 48MHz consumes about 2.5mA. pretty nice. so if I had to do soft I2C, vs doing interrupt I2C, I guess there isn't much power difference, just code architecture differences (can't interrupt I2C comms in the middle of sending bits, some devices don't like that...)
so I looked at using a different MCU. CH582 has the same slow flash, but has more RAM for code. importantly the I2C pins are not shared with debug or anything else I'd use in the design. there's also more use publicly of CH582 as it's been around longer. it costs more than CH592 but not by much: ~$0.75 vs $0.45 in badge qty. still cheap. oh, and the radio can support long range modes if I want. this has been stripped out of CH592.
by the time I got around to working on the nametag hardware I completely forgot that I researched this and went with CH592 in the final design...
so this is where we're at now. I run the soft I2C master routines at 32MHz and for this MCU at least the power consumption isn't much different between 32MHZ and WFI. of course this MCU isn't doing much in it's low speed time so I could use ultra low power mode but ... I'd only be saving a little over a milliamp. I'd like to not consume this but it's an addon. most people hardly consider power consumption anyway, lol. do I really want to be like that too? I guess not really...
final thoughts on ch592?for general purpose work, it's ok.
peripheral library is weak. sample code kinda sucks.
hardware peripherals are limited in type and generally very simple, though some have some interesting features (such as modem signals on UART, or built-in buffer / opamp with gain on ADC input path).
missing atomic GPIO set register like on CH32V series. but it does have atomic clear register...
timers are tied to HCLK only. can't run from the crystal. this is a big limitation.
i2c is on the debug pins. this is a big limitation.
it's less than 50 cents each in badge quantities. not like that matters much but if you've gotta cost optimize...
-
Updates 20241028
10/28/2024 at 07:37 • 0 comments0100:
Assembly is going really slow. I'm ... drained.
The acrylic has been designed and I uploaded a photo of a prototype. Progress was made after the prototype and the final acrylic looks much better, diffuses more light forward, fits tight with just enough tolerance.
Did a quick test of current in the nametag mode with the brightest RGB program (rainbow) running.
20mA with no screen. Add the screen, is 27mA.
I didn't test with no RGB program but I would guess between the quiescent of the RGBLED controller and MCUs, the current would be something like 10-12mA. Not awful I guess. This is with only basic consideration for power optimization, and soft SPI master on the main MCU.
I'll stop procrastinating and get back to assembly in a little bit.
2030: Still soldering. Still adding headers and standoff pins.
How is it done?
I have jigs for the top and bottom boards. The top board gets two pin TH header.
Bottom PCB gets modified addon connectors. These are modified as I screwed up the board and have the connector mirrored, lol. Don’t want to pass power back over the GPIO and cause problems. The header gets soldered and bodge wires added.
Following these steps, the OLED gets attached to the top board next with acrylic and tape sandwiched in between. After that, the OLED+acrylic+top assembly gets soldered to the bottom assembly, finishing the process.
Note that if this was to somehow win a spot in the contest, parts of this assembly would be simplified or replaced with SMT alternatives in order to speed assembly and reduce hands on work needed.
I hope to be at the OLED assembly phase in a few hours. If things go well I may have them all assembled before I go to sleep.
-
Progress 20241027
10/27/2024 at 08:46 • 0 commentsBeen hacking away at code. Struggled yesterday with button / multi-mcu comms code code but got it squared away after 10 hours. Since then things have mostly worked out OK. All core features work and added a couple new things. There's still a lot to do.
Designed assembly jigs a few hours ago. Once my brain isn't so hazy I'll finally design and cut the diffuser acrylic to post real photos. I'll be working on assembly for the next couple of days to have as many ready as possible for con. Still need to fit in vehicle prep time for the trip.
No idea what comms will work by the start of SC8. Hoping I can get the IrDA code done at least as that's the key feature.
I really need another week...
-
Progress 20241025
10/25/2024 at 10:25 • 0 commentsHad a bunch of bugs in main MCU code. Been pretty brain fried so was slow going, but it's mostly working now. Renders the OLED and gets accelerometer data.
Now I need to finish the button handling part. Will write the initialization code for button interrupts after I wake up and see if all the rest of the code falls into place. If so then I can focus on hardware for a day or so, clear my mind, then come back to code in a couple days and add the new fonts, Supercon banner, and text render modes. Oh and maybe get some basic IrDA comms working. Not sure I'll have the USB card thing by con but I can have a name and message log at least!
Can do more if time permits.
-
Progress 20241024
10/25/2024 at 00:30 • 0 comments1630:
PCBs arrived.
Testing the main board so far, have a major problem. Knew stress and rush would bite me and I’d screw this up on some project eventually. Addon header is backwards, lol. I can work around it with bodge wires and cutting traces but this already cuts into time I don’t have. I guess the GPIO pins won’t be used. They were wired but I wasn’t planning on using them anyway.
After some initial troubles I do have debug and program working. I2C soft master code doesn’t seem to be working correctly (or at least the OLED isn’t initializing) so the next task is to troubleshoot that. Hopefully it’s as simple as my delay constants being wrong. Once I know I2C master works and something shows on the OLED, I’ll work on getting the slave MCU code debugged.
1900:
soft i2c master bugs fixed, timings also fixed.
Need to start work with the sub MCU now.
-
Updates 20241023
10/23/2024 at 11:25 • 0 commentsPCBs are finally with the carrier, and will likely be here tomorrow. Friday at the latest. There's a lot to do once they arrive...
Nearly every other project is wrapped up and ready for Supercon. For a week, this will be my focus.
Expect real photos of an assembled unit this weekend.
Uploaded schematics for anyone who wants to get an idea of what this thing is made of.