Search results

Aaannddd I reversed the USB connector on the board! 🎉🥳 sigh

At my company we wanted to switch from Atmegas to STM32s (there is an almost pin-compatibile one with the 328p), we did a round of prototyping, I ported the firmware, we made the production boards, then the pandemic arrived, the STMs started to have a lead time of 90 weeks, then 100, then 110...

I guess it depends on the application? The atmega328 datasheet gives the usart settings for up to 1M when running @ 16mhz.

ATmega328's UART can run faster with very low error rate, I use it at 500k. TashTalk on the PIC does 1M. I can't say anything on the EtherWave unfortunately, I never even saw one...

This is interesting, I never heard about the EtherWave Printer Adapter, I guess going faster on the PC side would be mostly a question of serial adapter capabilities?

Small update on this too: I made a new schematic and finished the layout, I promised the Linux developers there was a device to use the TashTalk driver so now I need to make it ;)

pcbs are finally here! Let's see if it actually works...

Very nice job! I'm myself a PowerBook 100 lover and magnet for broken ones to fix

Firstly the good news: they vert kindly changed the patch so I have time to submit the tashtalk driver! I think the userspace solution is interesting to explore, but I'm not sure it is 100% doable. Basically as you said we need to transform LLAP into ELAP, which is something the kernel already...

I think a first stage I can remove that, it is relatively minor (I hope, it is mostly to make Netatalk happy!) I think then further redesign of the localtalk stuff is due, which is old and quite messy. They proposed to switch to userspace and make a tun/tap driver, I'm not 100% sure how it would...

They already replied, and were very kind! Sincerely I was a bit nervous to to post on the Linux mailing list for the first time :) All the stuff they ask is very reasonable, including ndo_do_ioctl, and are things I was thinking of proposing patches later on. The reason I kept stuff like...

ok message sent! I'm not sure if it was ok, will see what happens...

If you think it is doable, I can write an email explaining my work in this driver and my reasoning behind it. I can add the people on the CC list directly when I write to the mailing list?

I too think IPDDP should go, it interferes with MacIPGW (which works great with modtashtalk btw). Unfortunately I have no voice to object to the removal ok LocalTalk or i would do so.

Well I guess I arrived too late then. A bummer, but such is life.

Cool I'm in to try this. For now I use 29 which is the "test" discipline, then we will see. At this stage I think these are the next steps: I need to polis up the code still and add documentation I would like somebody to review it :) Run lint and make it more compatible with the kernel coding...

How did you make it work? I wrestled with it for an afternoon, the localtalk side worked perfectly but ethernet kept dying and then I just gave up.

For what is worth, I would be very happy to contribute this module to the kernel and possibly some other patches to the AppleTalk stack. I have no idea where to start tho.

You described how the digital systems in model railways work! It is basically a serial bus that gets rectified. Doing this on a serial port would be quite some crazy serial port abuse ;) One could look on the current sourced by the transceivers...