Reminds me of this:
Reminds me of this:
are we naming the hats after hats now?
fez, fedora, deerstalker
Oh. I misunderstood thing you’ve done in message 60 @adekto. It can be easily done with just 3D printed plastic and springs.
@Hanski I have exams this week and next week I will be in Istanbul for Sonar festival. If I found time for next revision in two weeks probably it will be final revision before testing PCB. I can produce few boards for test and send them to SW gurus
Also I can draw a fritzing scheme for connecting arduino pro micro’s to Pokitto for testing Arduboy HAT idea before PCBs produced ASAP
Ok, that sounds great. Excellent that you can send proto boards for testing! Of course, whoever will get them will pay you for the board, parts and postage costs. Maybe we should have some kind of poll about who are interested in testing boards and what kind of test or development they can do for it?
It’s good idea. I can produce more than 2-3 board if I get payment (I don’t mind to earn money). I really want to do more without getting anything (because you’re awesome peoples) but I’m still student
But… PayPal not working in Turkey. I don’t know is there any alternative available.
Might want to give some thought to the value of the RGB LED resistors too - a lot of Arduboy users don’t like how bright the LED is!
I give them dummy values for now. Probably they will not same value but I didn’t calculated yet. Do you have any suggestion about resistor values?
It’s best to experiment because it will depend on the forward voltage, efficiency and sensitivity of the eye for each colour, plus the supply voltage and maximum desired brightness. Green will probably end up to be a higher resistor value than red and blue, and all three may end up different for the best balance.
Paypal would have been a good option. But I think we can trust each other enough to use an international bank transfer. We are anyway talking about a quite small amount of money.
idk maybe the pokitto store could help out so everything is tracked properly
apart from arduboy hardware emulation what else can it do? and anyone looked at how to use the pokitto as a programmer?
It would probably have to be at production level before the store could be involved.
I could be wrong though.
The store would be a suitable middle-man if it was possible.
The screen would be emulated but the chip itself would be the same.
So essentially it’s another programmable coprocessor, a bit like the ESP hat idea but less powerful.
Essentially it’s a hardware solution to make a software problem simpler (emulating one screen component instead of an entire hardware setup).
I know it’s possible to use an Arduino board as a programmer using an Arduino ISP program, and Arduino ISP is released under BSD Licence so it could probably be modified to work with the Pokitto.
From what I can tell it just uses regular digital signals.
There is actually an mbed ISP but I don’t know how well it works.
The way the hat is currently designed, you have a choice of programming via SPI or serial. Serial would require a custom bootloader in the ATmega32u4 on the hat (which could be burned using the Pokitto via SPI).
Programming via SPI is documented in the 32u4 datasheet.
The protocol for serial programming is fairly straight forward and could probably be implemented from scratch without too much effort.
It would also be possible to devise and implement a simpler serial programming protocol in the bootloader and the Pokitto.
I am happy to support on this if needed. But, @NullMember can correct me, the problem in this case is that transfer of money from/to Turkey has gotten very complicated due to the fact that PayPal no longer works. How to can manage without PayPal (ebay for example) must be very complicated indeed.
As far as I am concerned, I am ready to order and distribute the boards if it makes things easier.
There is already the Pokitto’s ‘Arduboy-mode’, so you would just take the pixel data coming in over SPI on the PEX header and feed it into that Arduboy-mode screen buffer… the ‘official’ Arduboy library code for driving the OLED has been optimised down to the point where the DC pin is not asserted at the beginning of every frame of pixel data though (as other standard SSD1306 libraries do) so you do not have the luxury of using that to keep track of which pixel data corresponds to coordinates X=0 & Y=0 to stay in sync.
The other consideration would be emulating the OLED commands supported by the Arduboy2 library:
OLED_PIXELS_INVERTED 0xA7 // All pixels inverted OLED_PIXELS_NORMAL 0xA6 // All pixels normal OLED_ALL_PIXELS_ON 0xA5 // all pixels on OLED_PIXELS_FROM_RAM 0xA4 // pixels mapped to display RAM contents OLED_VERTICAL_FLIPPED 0xC0 // reversed COM scan direction OLED_VERTICAL_NORMAL 0xC8 // normal COM scan direction OLED_HORIZ_FLIPPED 0xA0 // reversed segment re-map OLED_HORIZ_NORMAL 0xA1 // normal segment re-map
and properly accepting and discarding those that aren’t supported.
I imagine once the basics of sniffing the spi for the correct data, the rest will easily fall into place. You wouldn’t have to have v0.01b working 100% perfectly.
That sounds doable.
@NullMember Have you had a chance to work on this further? This is such a great project!
I was a little curious about this myself. I found this - http://legacy.gamebuino.com/forum/viewtopic.php?f=16&t=2272&p=13413&hilit=tvout#p13413 which might be a good starting point for the Arduboy code side of things.