* Arduino Due vs Mac @ 2015-07-06 16:17 Simon Wright 2015-07-06 16:24 ` Bob Duff ` (3 more replies) 0 siblings, 4 replies; 17+ messages in thread From: Simon Wright @ 2015-07-06 16:17 UTC (permalink / raw) I'm trying to get my ARTS running on a Due, but have come across a huge stumbling block in that I can't use the Bossa tool (or its command-line equivalents) to upload the built binary to the target board from the Mac. There are several different versions of bossa, some of which recognise the Due, most of which try to open the usb-serial connection at too high a baud rate; but none will upload. The Arduino application for the Mac works fine, but I really don't want to write tiny programs in C in a tiny window! I've attempted to write my own uploader, which is very frustrating (the Atmel documentation is quite misleading in parts, and the board's behaviour seems inconsistent, and the only sure answer seems to be to understand the Bossa (C++) and Arduino (Java) code, baffling). Do others have Due vs Mac problems, or is it that I managed to buy a duff board? ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Arduino Due vs Mac 2015-07-06 16:17 Arduino Due vs Mac Simon Wright @ 2015-07-06 16:24 ` Bob Duff 2015-07-06 20:59 ` Simon Wright 2015-07-06 18:03 ` Tero Koskinen ` (2 subsequent siblings) 3 siblings, 1 reply; 17+ messages in thread From: Bob Duff @ 2015-07-06 16:24 UTC (permalink / raw) Simon Wright <simon@pushface.org> writes: > Do others have Due vs Mac problems, or is it that I managed to buy a > duff board? I don't sell boards. I'm a software guy. ;-) - Bob ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Arduino Due vs Mac 2015-07-06 16:24 ` Bob Duff @ 2015-07-06 20:59 ` Simon Wright 0 siblings, 0 replies; 17+ messages in thread From: Simon Wright @ 2015-07-06 20:59 UTC (permalink / raw) Bob Duff <bobduff@theworld.com> writes: > Simon Wright <simon@pushface.org> writes: > >> Do others have Due vs Mac problems, or is it that I managed to buy a >> duff board? > > I don't sell boards. I'm a software guy. ;-) I did wonder as I wrote. I thought the subject wouldn't attract your attention! ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Arduino Due vs Mac 2015-07-06 16:17 Arduino Due vs Mac Simon Wright 2015-07-06 16:24 ` Bob Duff @ 2015-07-06 18:03 ` Tero Koskinen 2015-07-06 21:08 ` Simon Wright 2015-07-06 20:34 ` Maciej Sobczak 2015-07-07 12:59 ` Jedi Tek'Unum 3 siblings, 1 reply; 17+ messages in thread From: Tero Koskinen @ 2015-07-06 18:03 UTC (permalink / raw) 6.7.2015, 19:17, Simon Wright kirjoitti: > I'm trying to get my ARTS running on a Due, but have come across a huge > stumbling block in that I can't use the Bossa tool (or its command-line > equivalents) to upload the built binary to the target board from the > Mac. > > There are several different versions of bossa, some of which recognise > the Due, most of which try to open the usb-serial connection at too high > a baud rate; but none will upload. > > The Arduino application for the Mac works fine, but I really don't want > to write tiny programs in C in a tiny window! > > I've attempted to write my own uploader, which is very frustrating (the > Atmel documentation is quite misleading in parts, and the board's > behaviour seems inconsistent, and the only sure answer seems to be to > understand the Bossa (C++) and Arduino (Java) code, baffling). > > Do others have Due vs Mac problems, or is it that I managed to buy a > duff board? Instead of using bossa, buy yourself a real JTAG adapter (Segger JLink, etc.). If you at some point change to a different ARM Cortex-M MCU, same JTAG adapter continues to work with it also (unless you buy some very cheap vendor-specific JTAG). Yours, Tero ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Arduino Due vs Mac 2015-07-06 18:03 ` Tero Koskinen @ 2015-07-06 21:08 ` Simon Wright 2015-07-08 17:22 ` darek 0 siblings, 1 reply; 17+ messages in thread From: Simon Wright @ 2015-07-06 21:08 UTC (permalink / raw) Tero Koskinen <tero.koskinen@iki.fi> writes: > Instead of using bossa, buy yourself a real JTAG adapter (Segger > JLink, etc.). If you at some point change to a different ARM Cortex-M > MCU, same JTAG adapter continues to work with it also (unless you buy > some very cheap vendor-specific JTAG). That would be the next step. Indeed, without JTAG I don't see how anyone programs the Due, because of total absence of debug facilities; and it does add considerably to the price (not that I can't afford it, just seems a bit much for the hobbyist market). You're talking about something like 3 times the cost of an STM32F4 Disco board, which has the STLINK interface on-board and a straightforward and free software solution for gdb; things stop, ^C, get a traceback from last_chance_handler, on to the next problem. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Arduino Due vs Mac 2015-07-06 21:08 ` Simon Wright @ 2015-07-08 17:22 ` darek 2015-07-09 20:27 ` Simon Wright 0 siblings, 1 reply; 17+ messages in thread From: darek @ 2015-07-08 17:22 UTC (permalink / raw) On Monday, 6 July 2015 23:07:59 UTC+2, Simon Wright wrote: > Tero Koskinen writes: > > > Instead of using bossa, buy yourself a real JTAG adapter (Segger > > JLink, etc.). If you at some point change to a different ARM Cortex-M > > MCU, same JTAG adapter continues to work with it also (unless you buy > > some very cheap vendor-specific JTAG). > > That would be the next step. Indeed, without JTAG I don't see how anyone > programs the Due, because of total absence of debug facilities; and it > does add considerably to the price (not that I can't afford it, just > seems a bit much for the hobbyist market). You're talking about > something like 3 times the cost of an STM32F4 Disco board, which has the > STLINK interface on-board and a straightforward and free software > solution for gdb; things stop, ^C, get a traceback from > last_chance_handler, on to the next problem. For my hobby projects (SDR) at home I got this one (non-commercial use): https://www.segger.com/j-link-edu.html Together with the Olimex board : https://www.olimex.com/Products/ARM/ST/STM32-H407/open-source-hardware and a hobbyist version of the CrossWorks (http://www.rowley.co.uk/arm/) environment works very well. I know, its C but I had to start somewhere :). Again this is not Ada but it is worth checking: http://www.mpeforth.com/xc7.htm#versions and http://www.forth.com/embedded/swiftx-embedded-systems-14.html Cheers, Darek ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Arduino Due vs Mac 2015-07-08 17:22 ` darek @ 2015-07-09 20:27 ` Simon Wright 2015-07-11 13:35 ` Simon Wright 0 siblings, 1 reply; 17+ messages in thread From: Simon Wright @ 2015-07-09 20:27 UTC (permalink / raw) darek <darek.maksimiuk@gmail.com> writes: > On Monday, 6 July 2015 23:07:59 UTC+2, Simon Wright wrote: >> Tero Koskinen writes: >> >> > Instead of using bossa, buy yourself a real JTAG adapter (Segger >> > JLink, etc.). If you at some point change to a different ARM Cortex-M >> > MCU, same JTAG adapter continues to work with it also (unless you buy >> > some very cheap vendor-specific JTAG). >> >> That would be the next step. Indeed, without JTAG I don't see how >> anyone programs the Due, because of total absence of debug >> facilities; and it does add considerably to the price (not that I >> can't afford it, just seems a bit much for the hobbyist >> market). You're talking about something like 3 times the cost of an >> STM32F4 Disco board, which has the STLINK interface on-board and a >> straightforward and free software solution for gdb; things stop, ^C, >> get a traceback from last_chance_handler, on to the next problem. > > For my hobby projects (SDR) at home I got this one (non-commercial use): > https://www.segger.com/j-link-edu.html > Together with the Olimex board : > https://www.olimex.com/Products/ARM/ST/STM32-H407/open-source-hardware and > a hobbyist version of the CrossWorks (http://www.rowley.co.uk/arm/) > environment works very well. I know, its C but I had to start > somewhere :). > Again this is not Ada but it is worth checking: > http://www.mpeforth.com/xc7.htm#versions and > http://www.forth.com/embedded/swiftx-embedded-systems-14.html I'm looking at the Segger EDU version and the Olimex connector (a tenth the cost of the Segger version!) ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Arduino Due vs Mac 2015-07-09 20:27 ` Simon Wright @ 2015-07-11 13:35 ` Simon Wright 2015-07-11 17:55 ` darek 0 siblings, 1 reply; 17+ messages in thread From: Simon Wright @ 2015-07-11 13:35 UTC (permalink / raw) Simon Wright <simon@pushface.org> writes: > darek <darek.maksimiuk@gmail.com> writes: > >> On Monday, 6 July 2015 23:07:59 UTC+2, Simon Wright wrote: >>> Tero Koskinen writes: >>> >>> > Instead of using bossa, buy yourself a real JTAG adapter (Segger >>> > JLink, etc.). If you at some point change to a different ARM Cortex-M >>> > MCU, same JTAG adapter continues to work with it also (unless you buy >>> > some very cheap vendor-specific JTAG). >>> >>> That would be the next step. Indeed, without JTAG I don't see how >>> anyone programs the Due, because of total absence of debug >>> facilities; and it does add considerably to the price (not that I >>> can't afford it, just seems a bit much for the hobbyist >>> market). You're talking about something like 3 times the cost of an >>> STM32F4 Disco board, which has the STLINK interface on-board and a >>> straightforward and free software solution for gdb; things stop, ^C, >>> get a traceback from last_chance_handler, on to the next problem. >> >> For my hobby projects (SDR) at home I got this one (non-commercial use): >> https://www.segger.com/j-link-edu.html >> Together with the Olimex board : >> https://www.olimex.com/Products/ARM/ST/STM32-H407/open-source-hardware and >> a hobbyist version of the CrossWorks (http://www.rowley.co.uk/arm/) >> environment works very well. I know, its C but I had to start >> somewhere :). >> Again this is not Ada but it is worth checking: >> http://www.mpeforth.com/xc7.htm#versions and >> http://www.forth.com/embedded/swiftx-embedded-systems-14.html > > I'm looking at the Segger EDU version and the Olimex connector (a tenth > the cost of the Segger version!) Works just fine. I spent a lot of time looking at the 10-pin end of the Olimex connector; the red side of the cable, which I believe means pin 1 is at that end, goes to the inboard end of the JTAG connector. I run the GDB server with $ jlinkgdbserver \ -device ATSAM3X8E \ -endian little \ -if jtag \ -localhostonly \ -halt (-if swd works too). ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Arduino Due vs Mac 2015-07-11 13:35 ` Simon Wright @ 2015-07-11 17:55 ` darek 0 siblings, 0 replies; 17+ messages in thread From: darek @ 2015-07-11 17:55 UTC (permalink / raw) On Saturday, 11 July 2015 15:35:48 UTC+2, Simon Wright wrote: > Simon Wright writes: > > > darek writes: > > > >> On Monday, 6 July 2015 23:07:59 UTC+2, Simon Wright wrote: > >>> Tero Koskinen writes: > >>> > >>> > Instead of using bossa, buy yourself a real JTAG adapter (Segger > >>> > JLink, etc.). If you at some point change to a different ARM Cortex-M > >>> > MCU, same JTAG adapter continues to work with it also (unless you buy > >>> > some very cheap vendor-specific JTAG). > >>> > >>> That would be the next step. Indeed, without JTAG I don't see how > >>> anyone programs the Due, because of total absence of debug > >>> facilities; and it does add considerably to the price (not that I > >>> can't afford it, just seems a bit much for the hobbyist > >>> market). You're talking about something like 3 times the cost of an > >>> STM32F4 Disco board, which has the STLINK interface on-board and a > >>> straightforward and free software solution for gdb; things stop, ^C, > >>> get a traceback from last_chance_handler, on to the next problem. > >> > >> For my hobby projects (SDR) at home I got this one (non-commercial use): > >> https://www.segger.com/j-link-edu.html > >> Together with the Olimex board : > >> https://www.olimex.com/Products/ARM/ST/STM32-H407/open-source-hardware and > >> a hobbyist version of the CrossWorks (http://www.rowley.co.uk/arm/) > >> environment works very well. I know, its C but I had to start > >> somewhere :). > >> Again this is not Ada but it is worth checking: > >> http://www.mpeforth.com/xc7.htm#versions and > >> http://www.forth.com/embedded/swiftx-embedded-systems-14.html > > > > I'm looking at the Segger EDU version and the Olimex connector (a tenth > > the cost of the Segger version!) > > Works just fine. I spent a lot of time looking at the 10-pin end of the > Olimex connector; the red side of the cable, which I believe means pin 1 > is at that end, goes to the inboard end of the JTAG connector. > > I run the GDB server with > > $ jlinkgdbserver \ > -device ATSAM3X8E \ > -endian little \ > -if jtag \ > -localhostonly \ > -halt > > (-if swd works too). Simon, if it helps the doc for the Olimex board is here:https://www.olimex.com/Products/ARM/ST/STM32-E407/resources/STM32-E407.pdf Cheers, Darek ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Arduino Due vs Mac 2015-07-06 16:17 Arduino Due vs Mac Simon Wright 2015-07-06 16:24 ` Bob Duff 2015-07-06 18:03 ` Tero Koskinen @ 2015-07-06 20:34 ` Maciej Sobczak 2015-07-06 21:29 ` Simon Wright 2015-07-07 12:59 ` Jedi Tek'Unum 3 siblings, 1 reply; 17+ messages in thread From: Maciej Sobczak @ 2015-07-06 20:34 UTC (permalink / raw) > I'm trying to get my ARTS running on a Due, but have come across a huge > stumbling block in that I can't use the Bossa tool (or its command-line > equivalents) to upload the built binary to the target board from the > Mac. Get the Arduino IDE and use the bossac tool that is part of it. You should be able to upload any binary to the Arduino Due like this: $ bossac -e -w -v -U true -p tty.usbmodemfd131 -b program.bin Note: the USB device is a bit unpredictable, it might be tty.usbmodemfd141 or something - I had to check the availability of this special file name under /dev before every upload and use the actual name that was there. > The Arduino application for the Mac works fine, but I really don't want > to write tiny programs in C in a tiny window! You can make that window bigger, too. ;-) > Do others have Due vs Mac problems, or is it that I managed to buy a > duff board? I have used Due with a Mac myself. For a complete picture, I have compiled programs on RaspberryPi, but uploaded to Due from a Mac. No problems apart from unpredictable USB device name, as described above. It *might* be a broken board as well, but if it works fine with the Arduino IDE, then try with the bossac tool from the IDE. -- Maciej Sobczak * http://www.inspirel.com ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Arduino Due vs Mac 2015-07-06 20:34 ` Maciej Sobczak @ 2015-07-06 21:29 ` Simon Wright 2015-07-07 11:08 ` Simon Wright 0 siblings, 1 reply; 17+ messages in thread From: Simon Wright @ 2015-07-06 21:29 UTC (permalink / raw) Maciej Sobczak <see.my.homepage@gmail.com> writes: >> I'm trying to get my ARTS running on a Due, but have come across a huge >> stumbling block in that I can't use the Bossa tool (or its command-line >> equivalents) to upload the built binary to the target board from the >> Mac. > > Get the Arduino IDE and use the bossac tool that is part of it. I don't see that? (that is, I downloaded the Arduino IDE and there's no file called bossa* there at all). What I did do is look again at https://github.com/shumatech/BOSSA.git and **check out the 'arduino' branch** (and compile with clang, not GCC!) > You should be able to upload any binary to the Arduino Due like this: > > $ bossac -e -w -v -U true -p tty.usbmodemfd131 -b program.bin > > Note: the USB device is a bit unpredictable, it might be > tty.usbmodemfd141 or something - I had to check the availability of > this special file name under /dev before every upload and use the > actual name that was there. If I leave out -U and -p this works (after a long pause while it scans through /dev/cu.Bluetooth- devices before finding /dev/cu.usbmodem1411 (this seems stable for the Due programming port on the USB port nearer the front of the Macbook)). Now I have to find out why I'm getting 'Floating point exception: 8", but this is a huge improvement! ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Arduino Due vs Mac 2015-07-06 21:29 ` Simon Wright @ 2015-07-07 11:08 ` Simon Wright 0 siblings, 0 replies; 17+ messages in thread From: Simon Wright @ 2015-07-07 11:08 UTC (permalink / raw) Simon Wright <simon@pushface.org> writes: > Maciej Sobczak <see.my.homepage@gmail.com> writes: > > What I did do is look again at https://github.com/shumatech/BOSSA.git > and **check out the 'arduino' branch** (and compile with clang, not > GCC!) > >> You should be able to upload any binary to the Arduino Due like this: >> >> $ bossac -e -w -v -U true -p tty.usbmodemfd131 -b program.bin >> >> Note: the USB device is a bit unpredictable, it might be >> tty.usbmodemfd141 or something - I had to check the availability of >> this special file name under /dev before every upload and use the >> actual name that was there. > > If I leave out -U and -p this works (after a long pause while it scans > through /dev/cu.Bluetooth- devices before finding /dev/cu.usbmodem1411 > (this seems stable for the Due programming port on the USB port nearer > the front of the Macbook)). > > Now I have to find out why I'm getting 'Floating point exception: 8", > but this is a huge improvement! Turned out to be an integer division by zero if the number of Flash pages to be written or verified was less than 10. Now progressing to the point of having a blinking LED!! As a matter of interest, I was able to write a simple program initialization in Ada which, with minimal cooperation from the linker script, lets me use gprbuild. The linker script starts ENTRY(program_initialization) MEMORY { flash (RX) : ORIGIN = 0x00080000, LENGTH = 512K sram (RWX) : ORIGIN = 0x20070000, LENGTH = 96K } SECTIONS { .isr_vector : { . = ALIGN(4); LONG(_estack) LONG(program_initialization + 1) FILL(0) KEEP(*(.isr_vector)) } > flash .text 0x00080100: startup.ads: pragma Restrictions (No_Elaboration_Code); package Startup is procedure Program_Initialization with Export, Convention => C, External_Name => "program_initialization", No_Return; end Startup; startup.adb: with System.Storage_Elements; package body Startup is -- Generated by gnatbind. procedure Main with Import, Convention => C, External_Name => "main", No_Return; procedure Program_Initialization is -- The following symbols are set up in the linker script: -- -- _sidata: the start of read/write data in Flash, to be copied -- to SRAM -- _sdata: where read/write data is to be copied to -- _edata: the first address after read/write data in SRAM -- _sbss: the start of BSS (to be initialized to zero) -- _ebss: the first address after BSS. use System.Storage_Elements; Sdata : Storage_Element with Import, Convention => C, External_Name => "_sdata"; Edata : Storage_Element with Import, Convention => C, External_Name => "_edata"; Sbss : Storage_Element with Import, Convention => C, External_Name => "_sbss"; Ebss : Storage_Element with Import, Convention => C, External_Name => "_ebss"; Data_Size : constant Storage_Offset := Edata'Address - Sdata'Address; -- Index from 1 so as to avoid subtracting 1 from the size Data_In_Flash : Storage_Array (1 .. Data_Size) with Import, Convention => C, External_Name => "_sidata"; Data_In_Sram : Storage_Array (1 .. Data_Size) with Import, Convention => C, External_Name => "_sdata"; Bss_Size : constant Storage_Offset := Ebss'Address - Sbss'Address; Bss : Storage_Array (1 .. Bss_Size) with Import, Convention => C, External_Name => "_sbss"; begin Data_In_Sram := Data_In_Flash; Bss := (others => 0); Main; end Program_Initialization; end Startup; ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Arduino Due vs Mac 2015-07-06 16:17 Arduino Due vs Mac Simon Wright ` (2 preceding siblings ...) 2015-07-06 20:34 ` Maciej Sobczak @ 2015-07-07 12:59 ` Jedi Tek'Unum 2015-07-07 15:32 ` Simon Wright 3 siblings, 1 reply; 17+ messages in thread From: Jedi Tek'Unum @ 2015-07-07 12:59 UTC (permalink / raw) A few observations: On Mac, device names ending in something like usbmodemfd131 are from the Apple driver and the hex ending is related to the physical port number. My experience has been that the Apple drivers, for FTDI at least, are buggy. I always replace it with the driver from FTDI which has always cleared up flaky problems for me. The driver from FTDI names the device with the serial number of the adapter. I haven't used it with ARM yet, but the ATMEL ICE (BASIC) is fairly inexpensive. With AVR I only use it to burn boot loaders. I never took the time to figure out how to configure tools on OS X to work with it - I just use the ATMEL tool on Windows within VirtualBox. Have you looked at OpenOCD (http://openocd.net/)? ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Arduino Due vs Mac 2015-07-07 12:59 ` Jedi Tek'Unum @ 2015-07-07 15:32 ` Simon Wright 2015-07-07 21:12 ` Jedi Tek'Unum 0 siblings, 1 reply; 17+ messages in thread From: Simon Wright @ 2015-07-07 15:32 UTC (permalink / raw) "Jedi Tek'Unum" <jeditekunum@gmail.com> writes: > On Mac, device names ending in something like usbmodemfd131 are from > the Apple driver and the hex ending is related to the physical port > number. My experience has been that the Apple drivers, for FTDI at > least, are buggy. I always replace it with the driver from FTDI which > has always cleared up flaky problems for me. The driver from FTDI > names the device with the serial number of the adapter. Giving it a try - I expect I need to reboot, cos the same old /dev/cu.usbmodem1411 shows up. > I haven't used it with ARM yet, but the ATMEL ICE (BASIC) is fairly > inexpensive. With AVR I only use it to burn boot loaders. I never took > the time to figure out how to configure tools on OS X to work with it > - I just use the ATMEL tool on Windows within VirtualBox. > > Have you looked at OpenOCD (http://openocd.net/)? Segger have software that provides a gdb server (much like st-util for STMicro). You can get the EDU version of the Segger for UKP41 (& I think VAT). You can get the Segger connector (which needs surgery to fit the Due, because one of the pins is blanked) for UKP70!!! but there's an Olimex one for UKP6 or so. The EDU version is licensed to be used only for non-commercial purposes, which suits me of course. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Arduino Due vs Mac 2015-07-07 15:32 ` Simon Wright @ 2015-07-07 21:12 ` Jedi Tek'Unum 2015-07-07 21:53 ` Simon Wright 0 siblings, 1 reply; 17+ messages in thread From: Jedi Tek'Unum @ 2015-07-07 21:12 UTC (permalink / raw) On Tuesday, July 7, 2015 at 10:31:52 AM UTC-5, Simon Wright wrote: > "Jedi Tek'Unum" writes: > > > On Mac, device names ending in something like usbmodemfd131 are from > > the Apple driver and the hex ending is related to the physical port > > number. My experience has been that the Apple drivers, for FTDI at > > least, are buggy. I always replace it with the driver from FTDI which > > has always cleared up flaky problems for me. The driver from FTDI > > names the device with the serial number of the adapter. > > Giving it a try - I expect I need to reboot, cos the same old > /dev/cu.usbmodem1411 shows up. Reboot is easiest (can unload/load). I think it is also necessary to disable the Apple driver. On Yosemite I go into /System/Library/Extensions/IOUSBFamily.kext/Contents/PlugIns and rename AppleUSBFTDI.kext directory to something else (I called mine AppleUSBFTDI.kext.disabled). ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Arduino Due vs Mac 2015-07-07 21:12 ` Jedi Tek'Unum @ 2015-07-07 21:53 ` Simon Wright 2015-07-08 15:33 ` Jedi Tek'Unum 0 siblings, 1 reply; 17+ messages in thread From: Simon Wright @ 2015-07-07 21:53 UTC (permalink / raw) "Jedi Tek'Unum" <jeditekunum@gmail.com> writes: > On Tuesday, July 7, 2015 at 10:31:52 AM UTC-5, Simon Wright wrote: >> "Jedi Tek'Unum" writes: >> >> > On Mac, device names ending in something like usbmodemfd131 are from >> > the Apple driver and the hex ending is related to the physical port >> > number. My experience has been that the Apple drivers, for FTDI at >> > least, are buggy. I always replace it with the driver from FTDI which >> > has always cleared up flaky problems for me. The driver from FTDI >> > names the device with the serial number of the adapter. >> >> Giving it a try - I expect I need to reboot, cos the same old >> /dev/cu.usbmodem1411 shows up. > > Reboot is easiest (can unload/load). > > I think it is also necessary to disable the Apple driver. On Yosemite > I go into /System/Library/Extensions/IOUSBFamily.kext/Contents/PlugIns > and rename AppleUSBFTDI.kext directory to something else (I called > mine AppleUSBFTDI.kext.disabled). You may well be right. Doesn't seem like a very well-thought-out installation tool that requires me to go into a system directory to rename/remove a system component instead of just doing it itself. I'm now getting on OK using bossa with the Apple drivers, so no need for the FTDI ones. But thanks for the thought. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Arduino Due vs Mac 2015-07-07 21:53 ` Simon Wright @ 2015-07-08 15:33 ` Jedi Tek'Unum 0 siblings, 0 replies; 17+ messages in thread From: Jedi Tek'Unum @ 2015-07-08 15:33 UTC (permalink / raw) On Tuesday, July 7, 2015 at 4:53:54 PM UTC-5, Simon Wright wrote: > "Jedi Tek'Unum" writes: > > On Tuesday, July 7, 2015 at 10:31:52 AM UTC-5, Simon Wright wrote: > >> "Jedi Tek'Unum" writes: > >> > On Mac, device names ending in something like usbmodemfd131 are from > >> > the Apple driver and the hex ending is related to the physical port > >> > number. My experience has been that the Apple drivers, for FTDI at > >> > least, are buggy. I always replace it with the driver from FTDI which > >> > has always cleared up flaky problems for me. The driver from FTDI > >> > names the device with the serial number of the adapter. > >> > >> Giving it a try - I expect I need to reboot, cos the same old > >> /dev/cu.usbmodem1411 shows up. > > > > Reboot is easiest (can unload/load). > > > > I think it is also necessary to disable the Apple driver. On Yosemite > > I go into /System/Library/Extensions/IOUSBFamily.kext/Contents/PlugIns > > and rename AppleUSBFTDI.kext directory to something else (I called > > mine AppleUSBFTDI.kext.disabled). > > You may well be right. Doesn't seem like a very well-thought-out > installation tool that requires me to go into a system directory to > rename/remove a system component instead of just doing it itself. The Apple driver didn't exist prior to Mavericks. One would have expected the Apple driver to be fully functional and reliable such that the FTDI driver would never be needed. Alas this is the state of Apple (or more accurately, the industry) these days - incomplete and unreliable. Renaming the Apple driver creates an ongoing problem with lifecycle as future Apple updates and releases will no doubt put it back in place. Good that Apple driver is working ok for you. I suspect it won't last :) ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2015-07-11 17:55 UTC | newest] Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-07-06 16:17 Arduino Due vs Mac Simon Wright 2015-07-06 16:24 ` Bob Duff 2015-07-06 20:59 ` Simon Wright 2015-07-06 18:03 ` Tero Koskinen 2015-07-06 21:08 ` Simon Wright 2015-07-08 17:22 ` darek 2015-07-09 20:27 ` Simon Wright 2015-07-11 13:35 ` Simon Wright 2015-07-11 17:55 ` darek 2015-07-06 20:34 ` Maciej Sobczak 2015-07-06 21:29 ` Simon Wright 2015-07-07 11:08 ` Simon Wright 2015-07-07 12:59 ` Jedi Tek'Unum 2015-07-07 15:32 ` Simon Wright 2015-07-07 21:12 ` Jedi Tek'Unum 2015-07-07 21:53 ` Simon Wright 2015-07-08 15:33 ` Jedi Tek'Unum
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox